DBの制約を回避する6つのテクニック
Google App EngineのDBサービスはジョインができないなどの制約があるので，パフォーマンスを高めるには工夫が必要だ。キーワードは「キャッシュ」「非正規化」「分散」「事前計算」など。そのほか，処理性能の予測やフレームワークの利用などに注意したい。 米Googleの「Google App Engine」（以下，GAE）は，Webアプリケーションの開発・実行環境を提供するサービスです。前回はGAEの概要編として，サービスの全体像や開発の流れ，データベース・サービスの概要などを説明しました。Java言語とPython言語で開発でき，各種ライブラリやアプリケーション・フレームワークがそろっている一方で，「データベースのジョインができない」といった制約があることを解説しました。 今回はGAEの設計編として，GAE上で動作するアプリケーションを設計する際のコツを，主にデータベース設計を中心
ここが大変だよBigtableとGoogle App Engine
2つのインデックス「シングルプロパティ」「コンポジット」 「シングルプロパティインデックス」がカギ Datastoreサービスでは、あるテーブルに含まれるすべてのエンティティについて、すべてのプロパティ（テーブルのカラムに相当）の値をキーとして並べた「シングルプロパティインデックス」と呼ばれるインデックステーブルが自動的に作成されます。 例えば、テーブルEmpが備える「name」「age」「dept_key」という3つのプロパティについて、「テーブル名＋プロパティ名＋プロパティ値」をキーとし、「Empテーブルの各行のキー」を値とする以下のようなインデックステーブルが作成されます。 Datastoreサービスでは、このシングルプロパティインデックスを用いることにより、アプリケーションが実行するクエリを「インデックスとスキャンの組み合わせ」に背後で変換しています。 例えば、上述の「age >=
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
