<セッション1> 発表者:id:bluerabbitさん 参考URL: http://d.hatena.ne.jp/bluerabbit/ テーマ:「実際に作ってわかったappengineの困ったところ」 内容:実際にappengineで開発してみてどんな事が問題になったのか。その問題をどのようにして回避したのか。appengineの様々な制約に対する回避策をご紹介します。天気予報を取ろうとすると,30秒ルールではじかれた. タスクキューで地域ごと142のタスクで実行.なぜか全部で3分かかった. キューの同時実行が想定通りでない. バッチ処理が問題になる.バッチが終了したことをどうやって検出するか. 機能を分割.チェイン.終了判定はカウンタ.memcache counter. memcache のlow level APIでatomic なcountが可能らしい. contains はやらないほうがいい by ひがさん 一発目の排他が難しい. s.put で 戻り値が返ってきたら制御 引数つきのs.putで失敗するように設定すればよい. タスクキューは冪等を保証しなければいけないらしい.まあそうだろうな. Mailの制限. 1日7000、1分32件. JDOだと関連をもとに勝手にentity groupを作ってしまっていて混乱のもと.byひがさん transaction 開始後最初のget/putで そのときのタイムスタンプをどこかに取っておく. commit のときに取っておいたタイムスタンプと同じかどうかを比較する. ancestor query 以外のqueryではtransactionがかからない.keyに対するgetだと だいtransactionになる.queryは本来複数の行を相手にしているので,そもそも どのentityグループにぞくしたqueryなのか定義できないから.ancestor queryは entity groupに対するqueryなので,定義できるから. low level APIにはtransaction ありとなしのメソッドがある. なしのメソッドはデフォルトのトランザクションということになる. トランザクションは入れ子にすることができ,一番内側のトランザクションがデフォルト のトランザクションになる. トランザクションにnullを指定すると トランザクション外で実行することができる. 開発環境でもちゃんとトランザクションの挙動が忠実に反映されている. kindlessAncestorQueryのみ挙動が違う. serializable - トランザクション内の分離レベルはserializable 非常に強固な分離.oracleはread-committed. timestamp付きで bigtable から読んでいる.だから,横の commit前のデータがちゃんと読める. ユニークキーは使えない.自分でユニークになるように制御しなければいけない.
KeyRange keys = service.allocateIds(KIND, 1); <- これ,結構重い.まとめてやったほうがいい.1件20msぐらい. String key = KeyFactory.keyToString(keys.getStart());チェイニングの機能を提供したらおもしろいかもね.
<セッション2> 発表者:ぶいてく竹嵜さん 参考URL: http://blog.virtual-tech.net/ テーマ:「ぶいてく流 スケーラブルアプリの作り方」 内容:「GAEはスケーラブルである、とはいうものの、30秒ルールなど実際には様々な制約があって、大量のデータを処理したり、また、大量のアクセスに耐えうる業務アプリを作るのは大変難しいと思います。スケールしなければクラウドの意味はない!?ということで、ぶいてくでは、いろいろと制約を回避する工夫を行ってきました。これらは独自の方法で、一般的ではない部分も含まれますが、いろいろと応用は可能かと思います。課題に対応した一つの例としてご紹介しますので、これをきっかけに皆さんもいろいろ考えてみてください。 1.GAE使ってめいっぱいPDFを生成する。どのくらい生成可能でどのくらい時間がかかるか、など 2.1000件を超える大規模データを処理する方法。Pagingにおける、CounterやKeyなどの実装例task queue スケールしないじゃんか!という話し. 請求書生成アプリ.PDFを差し込み生成. 受注受付処理と引き当て処理を分離. ブラウザ上のデータも含めてデータの整合性を管理する必要がある.重要. 最大値,最小値は一瞬で取れる.最小値の場合は,nullが最少になることがあるので注意が必要 memcache getput 15ms
datastore put 100-250ms get 20ms query 620ms
全文検索を力でやろうとしている.すごいね. 全文検索にはcompass というのがあるがtoyで使えない.
0 件のコメント:
コメントを投稿