Code Archive Skip to content Google About Google Privacy Terms
_ Google App Engine のデータストアは Bigtable をどのように使っているのか [gae][bigtable] Google App Engine (GAE) が発表されてから2週間ほど経ちます．GFS や Bigtable という名前だけはよく耳にするようになりましたが，Bigtable と GAE のギャップについては話題になっていないように思います． Bigtable は multi dimensional sorted table と言われるように， primary key (row key) でソートされたテーブルでしかありません．つま り，GAE のデータストアが提供するような多様な検索機能は持たないわけ です．というわけで，GAE のデータストアを実現するために，Bigtable がどのように使われているのかを考えてみました． # この件について，もし
Google App EngineにはTransactionは1つのEntity Group内でしかできないという制限があります。詳しくは、App EngineのEntityGroupを理解しよう - yvsu pron. yasを参照してください。 そうするとある口座から別の口座にお金を振込むような送金のパターンで、Transactionを利用することができません(すべての口座を1Entity Groupに押し込むと更新がぶつかって現実的ではないから)。送金パターンで整合性を保つためには、理論的には次のようになります。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 実装するとこんな感じ。 http://blog.notdot.net/2009/9/Distributed-Transactions-on-App-Engi
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
