だらだら備忘録: GAE/JのDatastoreのはなしとか
2009/05/23 GAE/JのDatastoreのはなしとか なんとなくまとめ。使い込んでないので突っ込みお待ちしてます。 キー まず、保存したいオブジェクト（Javaオブジェクト：POJO）はオブジェクトとかインスタンスとかいいます。Datastore内に保存されているものはエンティティといいます。（リレーショナルDBならタプルとかレコードとか）。 で、エンティティはDatastore内で一意なキーをもつ必要があって、オブジェクトの対象のフィールドに@PrimaryKeyアノテーションをつけて識別します。 Datastoreで使えるキーは4種類あって、単純なLong、String、そしてKeyとそれをStringにエンコードしたEncoded Key Stringって書いてあるヤツ。 LongだとDatastoreに保存したときに自動的に採番されます。設定もできるみたい。String
たけまる / Google App Engine のデータストアは Bigtable をどのように使っているのか
_ 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 がどのように使われているのかを考えてみました． # この件について，もし
「クエリしたら負け」―RISCのようなBigtableとの付き合い方 - スティルハウスの書庫の書庫
昔のCISC vs RISCを思い出した。BigtableはかなりプリミティブなRISCのようなデータストア。高級な処理はできないが、それがひとつのブレークスルーを生み出している。 RDB的発想だと、できるだけSQLの数を少なくしつつ、SQLでできることはコードでは書かない（ソートとかフィルタとか）という書き方になる。なぜならDBサーバーが1台しかないので、コード処理の重さがサービス全体のスループット（＝リクエスト処理時間に反比例）を決めるからだ。 しかしBigtableが根本的に異なるのは、サーバーがいくらでも分散化されること。コード側である程度重い処理（ループを回してソートしたりフィルタしたり）を実装してリクエスト処理時間が少々長くなっても、サービス全体のスループットはリクエスト数に比例してどこまでも伸びる。（といっても長くて2〜3秒くらいにしておきたいし、CPU課金は気にする必要があ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BigTableの最大利用のための原則と指針
