ここが大変だよBigtableとGoogle App Engine (1/2) - ＠IT（情報元のブックマーク数）
ってことでGAEな話。Mixiアプリモバイルでも、レスポンス低下無しに対応できているとのこと。
Google App Engine（以下、App Engine）が普及するにつれて、そんな驚愕の国内事例も登場しつつあります。GClueがApp Engine上で実装したmixiアプリモバイルには、1日100万PV以上のアクセスが集中している状態でもサービスのレスポンス低下やダウンは皆無だそうです。1日の運用コスト（グーグルへの支払い料金）は$12程度で、プログラマ以外に専任のサーバ管理者などはまったく不要とのことです。
ここが大変だよBigtableとGoogle App Engine (1/2)：分散Key-Valueストアの本命「Bigtable」（3） - ＠IT
まだ使い切れてない、bigtable、キーとデータによる検索なあれですな。
前回の「素朴なBigtable、できること できないこと」でも説明したとおり、App Engineの中核をなすデータストア「Bigtable」は、「キーを指定して値を読み書きする」という単純な機能しかサポートしていない分散Key-Valueストア（分散KVS）です。この素朴なデータストアの大きな制約を受け入れ、そのうえで複雑なWebアプリケーションのロジックをいかにして実装できるか工夫していくことが、この発想の転換へのはじめの一歩となります。
ここが大変だよBigtableとGoogle App Engine (1/2)：分散Key-Valueストアの本命「Bigtable」（3） - ＠IT
ふむふむ、キー、エンティティ、複数エンティティ
Datastoreサービスとは、App Engine上で動作するPythonもしくはJavaアプリケーションがBigtableにアクセスするためのサービスであり、主に以下の3つの機能を提供します。
ここが大変だよBigtableとGoogle App Engine (1/2)：分散Key-Valueストアの本命「Bigtable」（3） - ＠IT
1. キーに基づくエンティティのCRUD
2. エンティティに対するクエリ
3. 複数エンティティを対象としたトランザクションのACID保証
ここで「エンティティ」とは、PythonやJavaの個々のオブジェクトを保存したBigtableの行を表します。Datastoreサービスでは、このエンティティに対してキーに基づくCRUDが可能です。加えて、RDBライクな「クエリ」によるエンティティの検索を実行できるのが重要なポイントです。App EngineのJava版の場合、これらのDatastoreサービスの機能は、以下の3つのAPIを通じて利用できます。
1. JDO（Java Data Objects）
2. JPA（Java Persistence API）
3. 低レベルAPI（Low-level API）
これらのうち、「JDO」および「JPA」は、JCP（Java Community Process）を通じて策定された標準のデータ永続化APIです。とはいえ、JDOやJPAの機能をフル実装しているわけではなく、あくまで「Bigtableで実装できる機能のみ標準APIに合わせて提供している」といった位置付けです。
発想の転換で切り抜けろ！GAEではテーブル結合ではなくインデックス的に新規テーブルを作成して回避しているみたい。
実際に筆者の開発案件でも、RDB上に構築された既存のスキーマをそのままDatastore APIに載せただけでは、クエリ構文の制約が障害となって要件を満たせない状況が発生しました。そこで、「テーブル結合の代用としてインデックス的に使用するテーブルを新たに追加する」というワークアラウンドで対処しています。
ここが大変だよBigtableとGoogle App Engine (2/2)：分散Key-Valueストアの本命「Bigtable」（3） - ＠IT
しかし、これらの制約を前向き受け止め、「逆に考えるんだ、複雑なクエリやジョインなんていらないさ」という発想で、「分散KVS時代の新たなデザインパターン」を構築していけるかが、冒頭で紹介した事例のような2けたレベルの劇的なコストダウンを可能にする発想の転換への近道ではないかと筆者は考えます。
