読者です 読者をやめる 読者になる 読者になる

BigtableとJDOの勝ちパターン

すごく難しかったです。google論文をちゃんと読もうかと思いました。

自宅で、http://d.hatena.ne.jp/higayasuo/20090611/1244729307googleの人の話を聞いて、やっと半分くらいは理解できたと思います。

内容は、jdoでのデータアクセス方法と言うよりはbigtableアーキテクチャとデータ構造の話で、話題としては三つ。

bigtableのデータ構造

bigtableでは、エンティティの名前とシリアライズ(?)されたマップを持っていて、そこにテーブル名をkeyとしてアクセスしにいきます。テーブル名はソート済みなので、getするときのアクセス効率がいいです。

データアクセス時の内部処理

このへん、正直よくわかりませんでした。下記類推とgoogleを支える技術、の斜め読み知識が多分に含まれています。


こんな感じ?

chubby:分散ロックサービス。実データのファイルにロックをかけることができる。googleを支える技術、によると、イベント通知もできるらしい。
root tablet:mem tabletの場所を知ってるtablet。mem tabletが格納されているサーバーに障害が発生した際に、別のmem tabletを作る?あるいは、chubbyからのデータ更新イベントをもらい、検索対象とするmem tabletのリスト書き換える?
mem tablet:メモリ上にキーと実データのマップを保持する。primary cache(session cache)的存在?
user tablet:実データを保持するtablet。ディスクアクセスすると思われるので、比較的おそいはず。

chubbyがロックをかけるなら、後述のデータアクセス時の楽観ロックもchubbyがかましてるのでしょうか?root tabletの存在意義もやっぱりよくわかりません。

where句などのquery実行時の処理の話もありましたが、この辺は上記のkeyからのvalueの取り方の話と関連し、keyがソート済みであれば高速だし、直感的な話題でした。

トランザクション・アトミック性

トランザクションそのものの話はすんなり理解でき、永続化の呼び出しメソッド自体がトランザクション境界になるということでした。entity groupがトランザクションの境界になるという話も、jpa的にaggregate rootを永続化すれば子も永続化され、rootに対して楽観ロックが常にかかると思えばよいのだと思います。

楽観ロックも、oracleでいうところのredoログ相当のものをタイムスタンプで保持しており、ロールバック?される可能性を考慮してジャーナルを消したりしてるかも、という話でした。

この辺の話題は、上記のひがさんのブログで紹介されていたhttp://snarfed.org/space/datastore_talk.htmlのスライドに説明があります。


ということで、今日は歯医者さんに行って、カンファレンスに行って、その後プールに行って買い物もしました。さすがにそろそろ寝ます。