昨日様々なトランザクション分離レベルに付いて書いた。 AnomalyとはSerializableでない実行を引き起こす異常状態パターンのことを言う。 弱い分離レベルほどAnomalyが起きやすい。 これから図を交えながらAnomalyについて説明する。 図中の「W(x)」は「xに何らかの値を書き込む」、「R(x)」は「xの値を読む」をそれぞれ意味する。 分かりやすいようにReadは青、Writeは赤色で統一する。 また、Anomalyの被害に遭うのは常にT1に統一する。 Cはコミットを意味する。 Dirty Read Anomaly 未コミットな値を読んでしまうAnomalyの事。Readがロック関係なしに値を読んでしまう場合などに起きる。 T1が書き換えられる最中のxの値を読んでしまっている。もしT2が途中でアボートしたらT1はどこにも存在しない値を読んだ事になってしまう。 READ U
元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。（尚、当然ですが、内容が正確かどうかは
Learn Datalog Today is an interactive tutorial designed to teach you the Datomic dialect of Datalog. Datalog is a declarative database query language with roots in logic programming. Datalog has similar expressive power as SQL. Datomic is a database with an interesting and novel architecture, giving its users a unique set of features. You can read more about Datomic at https://datomic.com and the
3. 講義内容 序論 - 並列データベースの前に 並列処理の基礎 並列処理のTerminology 並列計算機アーキテクチャ 並列データベースのアーキテクチャ データベース処理の並列化 結合処理の高速化 並列ハッシュ結合 並列ソート パーティショニング手法 多重結合や計算機間のデータ交換で発生する問題 MapReduceによる関係演算の並列処理 3 4. データベース開発の流れ Coddの論文: 1970年 System RやIngres: 70年代中盤 Oracle, IBM DB2, Ingres: 80年代序盤 並列データベースの隆盛: 80年代後半 A Relational Model of Data for Large Shared Data Banks, Communications of ACM 商用
2. 自己紹介 {"ID" ："fetaro" "名前" ："渡部 徹太郎" "所属" ：株式会社リクルートテクノロジーズ "研究" ："東京工業大学でデータベースと情報検索の研究 (@日本データベース学会)" "仕事" ：["証券会社のオンライントレードシステムのWeb基盤", "オープンソースなら何でも。主にMongoDB", "リクルート各種サービスを横断的分析する基盤。主にHadoop"] "エディタ"："emacs派" "趣味"："自宅サーバ" "属性" : ["ギーク","スーツ"]} fetaro RDB技術者のためのNoSQLガイド 2 3. 書籍について • ギーク向けではなく、一般のRDB技術者向け • NoSQLの位置づけを明確化 (Hadoop, DWHとの違い) • エンタープライズの課題を解決する視点 • NoSQL界のスペシャリスト達による最新情報 • 評価良
AWSにおける形式手法の記事（https://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf）を読んだ。特に重要だと思われる示唆を3つあげると以下の通り。 産業界では長年形式手法は多大な工数をかけて比較的容易なコードの断片を検証するというイメージがあったが、これはまったくの誤り。現実の問題に適用可能である アマゾンでは10の現実のシステムに適用して、すべてで効果が得られた。難解なバグの発見したり、正当性を犠牲にすることなく確信を持って最適化を施せた 7つのチームでTLA+を使用。エンジニアは2−3週間で学習することができる 以下は、読んでいる途中で書きだした要点。 AWSでは2011年以降形式仕様とモデル検査を使用している 複雑な分散システムを検証するにあたって、従来の手法 ― 設計レビュー、コードレビュー、静的解析、ストレス
2017-02-12 はじめに Beringei: A high-performance time series storage engine | Engineering Blog | Facebook Code という記事を読んで、Facebookが2015年に “Gorilla: A Fast, Scalable, In-Memory Time Series Database” という論文でGorillaという時系列データベースについて発表したものをBeringeiとしてオープンソースで公開したのを知りました。 この論文は読んだことがなかったので読んでみたのですが、時系列データベースのデータの特徴をうまく活かした独自の圧縮方法が興味深かったので、自分でも試してみたのでメモです。 Gorillaでは高い圧縮率によってデータをオンメモリで扱うことができるようになり、書き込みと問い合わせの速
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Use of Formal Methods at Amazon Web Services