だらだら備忘録: 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 がどのように使われているのかを考えてみました． # この件について，もし
BigTableの最大利用のための原則と指針
Google App Engineに関して活発になっている会話に基づき、Todd Hoff氏はBig Tableのような分散ストレージシステムの使用を最適化する手段である、一連の原則(source)を概説した。 Todd氏は、BigTableを 使用することの定義から始めている。さまざまなトレードオフを引き起こすことを仮定すると、Big Tableは以下のようなアプリケーションをビルドする必要のあるときに、値を付加する。a)「膨大な数のユーザに拡張」する必要があるアプリケーション、b)読み取りに対する更新の割合が制限されているアプリケーション。またTodd氏は、「読み取り速度および拡張可能性の最適化」をするためには、 概念的アプローチがリレーショナルデータベースで使用されたものとは根本的に違っているべきであり、また最初にややカウンターを認識して、さらにリスキーであるとよい。 リレーショナル
「クエリしたら負け」―RISCのようなBigtableとの付き合い方 - スティルハウスの書庫の書庫
昔のCISC vs RISCを思い出した。BigtableはかなりプリミティブなRISCのようなデータストア。高級な処理はできないが、それがひとつのブレークスルーを生み出している。 RDB的発想だと、できるだけSQLの数を少なくしつつ、SQLでできることはコードでは書かない（ソートとかフィルタとか）という書き方になる。なぜならDBサーバーが1台しかないので、コード処理の重さがサービス全体のスループット（＝リクエスト処理時間に反比例）を決めるからだ。 しかしBigtableが根本的に異なるのは、サーバーがいくらでも分散化されること。コード側である程度重い処理（ループを回してソートしたりフィルタしたり）を実装してリクエスト処理時間が少々長くなっても、サービス全体のスループットはリクエスト数に比例してどこまでも伸びる。（といっても長くて2〜3秒くらいにしておきたいし、CPU課金は気にする必要があ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
