ブロガーの実験室スポンサー広告
> Google App Engine上のベスト・プラクティス、その1: Datastore> ブロガーの実験室パソコンな日々
> Google App Engine上のベスト・プラクティス、その1: Datastore
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


--.--.--|スポンサー広告||TOP↑

http://satoshi.blogs.com/life/2010/02/app_engine.html

Google App Engine上のベスト・プラクティス、その1: Datastore

 Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastore の話から。

なによりも大切なのはデータベースの設計

 あたりまえと言えばあたりまえの話 だが、App Engine上でアプリを作る上でもっとも大切なこと(=頭を使うべきところ)は、データベースの設計である。特にリレーショナル・データベース (RDB)上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。

 特に絶対にやっては行けないのは、

  • 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る
  • RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する
  • RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る

など。App Engineの利点を活用するためには、その特徴を最大に活かすように(データ・モデルだけでなく)アプリケーションそのもののアーキテクチャを最適化す べき。逆の言い方をすれば、それができない状況であればApp Engine上に載せる意味はあまりない。レイヤーをもうけてポータビリティを高めようとか、RDB上に作られたアプリをアーキテクチャの大幅な変更なし に移植しようとしている人がいるのであれば、そもそも「何でApp Engine上にアプリを載せたいのか」という発想が本当に正しいのかどうかから見直すべき。

Datastoreの特性を 理解する

 Datastoreの特性についてはGoogleから提供されているドキュメントに必要なことは書いてあるの で、ここではいちいち説明しないが、それを頭に入れた上での私なりのベスト・プラクティスを箇条書きにするとこんな感じになる。

  • ReadとWriteのスピードの違いが桁違いに大きい → 1つのHTTPアクセス中にするputの数はできるだけ少なくして おく。通常は0から1。よほど複雑な場合でも2、3回。5つ以上のputが必要な状況に陥ったとしたらデータ・モデルの設計から見直す べき。何らかの理由でたくさんの数のEntityを更新しなければならない場合(たとえばスキーマ変更のために1000個のEntityを一気に書き換え る)などは、TaskQueueを使って順繰りに実行させる。
  • Entity Groupはトランザクションのためにある → Entity Groupはできるだけ小さくしておき、トランザ クションが不要なところに親子関係は持たせないようにする。エンド・ユーザーから見て親子関係にあるからと言って、必ずしも同じ Entity Groupに入れる必要はないのでそこを間違えないように。たとえば、ブログのエントリーと、それに対するコメントが良い例。まずは、親子関係を一切持た せずにモデルを設計して行き、どうしてもアトミックに複数のEntityを同時に変更する必要が出て来た段階で、親子関係を持たせてEntity Groupを作る、という作り方をおすすめする。
  • データの正規化は基本的にはしない → エンド・ユーザーから見て一つの「もの」(たとえば商品、ブログエントリー)があった場合、それに付随する情報(たとえば、タイトル、値段、更新日時、作 者)をEntityそのもののプロパティとしてもたせておき、Queryなしに一回のgetですべて取得できるようにしておく。これは、RDB における「ベスト・プラクティス」とは正反対の方向を向いたものなので、RDB/SQLに慣れた人こそ気をつけて設計すべきである。
  • JOINがない → SQLにおけるJOINをApp Engine上で実現しようとすると、queryの結果をもとに複数のqueryをするというnested queryをせざるを得ないが、そもそもJOIN が必要となるような状況になったことが、データ・モデルの設計がすでにApp Engine向けのものになっていない証拠なので、「あ あ、JOINが使えたら楽なのに」と嘆く前に、今一度データ・モデルの設計から見直すべき。
  • Queryはキーの取得だけだととても高速 →  ReadはWriteと比べて早いとは言え、数百のEntityをQueryで取得するとそれなりの時間(千cpu_ms以上)がかかる。ただし、 Queryもキーの取得だけだと圧倒的に早いので、「いかにキーの取得だけで済むように設計するか」という部分で頭を絞るべき。 場合によっては、keyそのものに情報を埋め込んでおくことで、Entityを取得せずにEntityの情報を得るということも可能なので、ノウハウの一 つとして覚えておくと良い。
  • キーを使ったEntityの取得はQueryよりはるかに早い → なんらかの方法でキーを取得しておけば、そこから一つのEntityを取得するのは非常に早いので、それを利用して一つのHTTP GETを非常に高速に(100cpu_ms以下で)処理をすることが可能なので、これは頭に入れておくと良い。
  • Datastoreへのアクセスは無視できない確率で必ず失敗する(実測値で600回に1回程度)→ それに対応したコードを書いておく。HTMLを直接ブラウザーに返す場合は、サーバー側でretryをするしかないが、AJAXでデータを取得する場合は 必ずクライアント側にretryの仕組みを入れておく(3回で十分)。
  • App Engineは高レベルなAPIやGQLを提供して既存のアプリケーションの移植を簡単にしている → GoogleがApp Engineに関して言っていることはおおむね正しいが、ここだけは「うそも方便」だと思った方が良い。App Engineの上でスケーラブルなアプリを作りたいのであれば、低レベルのAPIを直接たたくべき。ちなみに、私はGQLは一切使わ ず、Pythonでdb.Modelを直接操作しているが、APIそのものはとてもストレートで簡単なので、すぐに慣れる。


2010.06.22|パソコンな日々コメント(0)TOP↑
名前:
コメントタイトル:
メールアドレス:
URL:
コメント:

パスワード:
管理人だけに表示:
管理者にだけ表示を許可
カテゴリー
最近の記事
最近のコメント
最近のトラックバック
ブログ検索
管理人のブログ一覧
管理人へメール

名前:
メール:
件名:
本文:

月別アーカイブ
プロフィール

やまもも実験室

Author:やまもも実験室
FC2ブログへようこそ!

RSSフィード
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。