Task QueueはMapReduceの夢を見るか - スティルハウスの書庫の書庫
いまコーディング中の案件で、Task Queueにぴったりハマる要件があったので、飛びついてみました。 課題：Datasource上の大量のデータをクライアントにダウンロードしたい。30秒内では終わらないので複数のリクエスト／レスポンスに分割してダウンロードする実装にした。しかしデータ量によっては何10分もかかってしまう。 原因：データ量の多さもあるが、それを取得するためのDatastoreのクエリ、および関連エンティティの取得にもっとも時間がかかっている 書こうとしているソリューション：クエリと関連エンティティ取得をTask Queueのタスクに分割して並列処理（map）し、取得したデータを集約（reduce）してクライアントに渡す …んん、これってMapReduceではないですか。1つのリクエストでは重い処理は、たくさんのタスクに細切れにして、キューにどんどん入れる。App Engin
Task Queue戦記 - スティルハウスの書庫の書庫
とても遅かった以前の実装をTask Queueを使って書き換えることができました。感想をまとめると、 Task Queueはすばらしい。30分かかってた処理が3分で終わるようになった（前の実装がヘボいのではという疑惑はさておき） 処理を複数のタスクに分割して並列処理する（map）は簡単だけど、memcacheを使ってその結果をまとめる（reduce）のは面倒 reduce不要な用途（一括削除とか）や、reduceが簡単な場合（数の集計とか）、あとmemcache使わずにDatastoreに集約する使い方なら、そんなに苦労しないだろう memcacheを介してデータの配布や収集をするとき、とくに収集時の排他を書く必要あり（こういうバグりそうな／バグを再現できなさそうなコードは書きたくない） MemcacheService#incrementを使ってスピンロックを実装した memcacheはい
Datastoreのtips - スティルハウスの書庫の書庫
Datastoreのパフォーマンス Datastoreのパフォーマンスは、エンティティの数とは無関係 保存されているエンティティが1件でも、1000件でも、1000万件でも、パフォーマンスに変化はない Datastore performance doesn't depend on how many entities you have 個々のエンティティに対する更新処理のスピードは、1〜10回／秒程度 個々のエンティティの更新処理は遅い アプリケーションのパフォーマンスを決めるのは、更新処理の実装方法。参照処理は桁違いに速い low-level APIを使えば少し速くなるが、ドキュメントがあまりない http://groups.google.com/group/google-appengine-java/browse_thread/thread/e717f7ba37749ea4/0b37a3
Google App Engineのtips集 - スティルハウスの書庫の書庫
（随時更新中です。間違いなどありましたらコメントをお願いします！） このページのtinyurl: http://tinyurl.com/gaetips Datastoreのtips Bigtableの内部構造 BigtableによるDatastoreの実装 Datastoreによるクエリの実装 トランザクションとエンティティグループ Datastoreのtips List Proprtyとmerge joinの使い方 GAE一般のtips GAEのサーバー構成とリクエストの流れ Task Queue APIの使い方 開発環境とプロダクション環境の違い Flex/AIR＋GAEのtips GAE/JにBlazeDSを組み込む BlazeDSの本番環境へのデプロイでハマる Datastore APIの取り扱いでハマる App Engine開発の便利な参考ページ TOPGATEさんのGoogle
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
