15:20 - 16:10 A-3
Google App Engine 上でスケールする Web アプリを書くには
松尾 貴志
（サイオステクノロジー株式会社）
だけを聞いた。
4/7にgoogleappのJava版
1年前にPython版
どこの部署？
経営企画部が問い合わせ先。
GoogleIOで使った資料。
アジェンダ、ランタイムを有効に使う。
無駄な繰り返しを辞める。
Pythonは遅延ロードが出来る。Javaは出来ない？
メモリでソートやフィルタは遅くなる。
main_results
nullならデータストアに問い合わせ。
書き込みはコストが高い。ディスクアクセスがいる。
1秒に500シークかかる。
数字。読み込みは早い。シリアライズされない。
バックエンドではメモリにキャッシュしている。
最初のアクセスは時間かかるけど早い。
データを保存するデータストアの解説。
アップエンジンでデータを保存するにはデータストアを使う。
1つのインスタンスはビックテーブルの1行。
プロパティの値。ノーペア。
valueの中、プロパティの中。
殆どのプロパティに関して値を。
RDB徒は違うもの
エンティティ同士リレーションが張れる。
one2many
many2many
キーによるアクセスは速い。
kindの名前とIDか、文字列型のキー。
Itentyfire、String型のkeyname
どっちかしかもてない。
500Byte制限。
分散sortedarray
トランザクションに制限がある。
クエリーは出来ない。
トランザクション内のエンティティを用意するのが一般的な方法。
トランザクションやデータのエンタリティは意識した方がよい。
親子関係を持ったエンティティ同士は一つのエンティティグループになる。
並列に同じ書き込みがある場合ロック。後の書き込みが行えない。自動的にリトライ。(ユーザは何もしなくて良い)
リトライが多すぎると書き込みの速度が遅くなる。
Childの書き込み。
楽観的な排他制度。
階層構造。
書き込みを分散できる。
書き込みのリトライが発生する。
上手いこと構成したり構成しなかったり。
クエリーは直列化されないので遅くない。
・カウンターの実装
あるモデルのエンティティをつくっておいて保存。
分散されたデータを。千件しか取ってこられない。
kindを作って保存。
分散カウンター。
・カウンターモデル
get_count(name)
def関数の定義
pythonは
字下げでブロックになる、
かけらの数だけ
putで保存する。
メモキャッシュでコードを稼ぐ。
ページネーション
通番 インデックスでソートする。
グローバルなカウンタ。
ブロガーの様な大規模サイトは別。
ID自動採番は飛んでしまう。
全部グローバルインデックスのChildになっている。
キーネームを指定して投稿する。
キーネーム・・Blog上の一要素を構成する。
コメントについて、炎上すると破綻するだろうと、共有インデックスは使えない。
ページネーションに使えないのでは？
大なりコード。
惜しいけど使えない。構成プロパティ。
一個文字列をつくってページネーション
・覚えておくこと。
無駄な繰り返しを。
同じクエリーを使うときはメモキャッシュ。
負荷に合わせてエンティティグループの 組み直し。
GAE/Pythonと GAE/Javaと
Python版の方が進んでいる。Java版も新しい仕組みがある。
・Python
Macのみランチャーがある。
RemoteAPIで一括アップロード
・Java
ant要のマクロが入っている。
親を指定してエンティティを作る。
ローレベルAPI
