大量のエンティティを処理するデザインパターン - GeekFactory
データストアにある大量のエンティティを処理したい場合、クエリ結果を複数のタスクに分散して処理する必要があります。クエリ結果のカーソルを次のタスクに引き継ぐパターンをテンプレート化してみました。 基本的な流れはこんな感じ。 タスクが実行される。 件数制限付きのクエリを実行する。 abstract query() 結果リストを処理する。 abstract run(List) タスク実行経過時間が6秒以内*1の場合は2に戻る。 すべてのエンティティを処理済みの場合は終了する。 結果リストのカーソルをパラメータに保存し、次のタスクをenqueueする。 使い方はこんな感じ。 QueryTask をextendsする。 query() にクエリを書く。 protected S3QueryResultList<Hoge> query() throws Exception { return Datast
非同期でクエリを実行してORを実現する #appengine
SDK1.2.8-prereleaseの頃にmakeAsyncCall()の導入に気づいて思いついた、クエリを複数に分けて非同期実行して結果をマージすることで、条件をOR結合するのと同じ事ができる！非同期ならそこそこ速いんじゃね？というアイデアの検証がようやく完了しました。 テストデータと仕様1-1000までのIDを持つキーを作成し、そのキーのIDの数値が2で割り切れるならmod2という属性の値がtrue、割り切れないならfalseというカンジでmod3,mod5とか用意した。で、クエリは「2または3または5で割り切れる」というものを抽出するという簡単なもの。条件的にはmod2 EQUAL true OR mod3 EQUAL true OR mod5 EQUAL trueとなり、分けるとmod2 EQUAL true、mod3 EQUAL true、mod5 EQUAL trueの3本を
GAE(google app engine) インデックスのトラブルの顛末 - Object Design
GoogleAppEngineの開発していたところ、ローカルの開発環境でも問題ないのですが、 GAEにアップロードして作動させるとうまく動かないことがありました。 調べてみると、GQLクエリ部分で問題が発生しているようです。 いろいろ調べたり、グーグルグループで質問したりしてなんとか解消できたので、 解消方法をメモしておきます。 基本的認識 ローカルの開発環境でうまく作動していても、サーバ上でうまく作動するとは限らない。→GQLクエリ関係 index.yaml が意図通り作成されていない場合は、手動で作成する必要がある → # AUTOGENERATE 行は削除する GQLで条件問い合わせを行う場合は、インデックスが正しく作成されている必要があります。 自動で生成される index.yaml がこちらの意図通りになっていない場合があるので、 手動で index.yaml を書き直す必要があ
GAE/J使いの為のインデックス削除ツール - y-kawazの日記
pythonで開発している場合は appcfg.py vacuum_indexes があるからデータストア上のインデックスの削除が行えるんですが、Java版のSDKにはまだその手のツールが無いので困ります。 そこで普段はJavaしか使わない人でも、ツールだけはPython版を使ってEclipseから簡単にインデックス削除を行えるようにしてみました。*1 まずGoogle App Engine SDK for Pythonを入れて置く必要があります。もちろんPythonも。 Eclipseのプロジェクト内に以下のようなダミーのアプリケーションディレクトリを作成しapp.yamlとvacuum_indexes.batを作成します。 消したいインデックスが出来てしまったら vacuum_indexes.bat を実行すれば不要なインデックスの削除が出来ます。 ファイルセット ダミーのアプリケーシ
インデックステーブルについてMLで聞いてみた - スティルハウスの書庫の書庫
App Engineのインデックステーブルについて、いまいち理解できてない部分や細かな疑問がいくつかあったのでMLで聞いてみました。 インデックステーブルの各行はどう構成されてる？ How Entities and Indexes are Storedで説明されているEntitiesByProperty ASC/DESCテーブルは、実際には キー："アプリID／カインド名／プロパティ名／プロパティ値" 値：エンティティのキー という構成か？それとも、 キー："アプリID／カインド名／プロパティ名／プロパティ値／エンティティキー" という構成で、値はとくに無いのか？ という質問に対し、Nickさんは 「後者で正しい」（インデックス行のキーにエンティティキーが含まれる構成） と返答してくれました。 また、インデックスについて詳しくはGoogle I/O 2008のUnder the Cover
GAE/Jをデプロイする時はインデクスを定義しとかないと - ありの日記
ローカルでは動いてるんだけど、appspotにデプロイしたら動かない。下のようなエラーがでてる。どうやら、インデックスが見つかんないよって言ってるらしい。 org.datanucleus.ObjectManagerImpl preCommit: com.google.appengine.api.datastore.DatastoreNeedIndexException: no matching index found. Uncaught exception from servlet javax.jdo.JDOException: Unexpected error during precommit at org.datanucleus.jdo.NucleusJDOHelper.getJDOExceptionForNucleusException(NucleusJDOHelper.java:4
ここが大変だよBigtableとGoogle App Engine
2つのインデックス「シングルプロパティ」「コンポジット」 「シングルプロパティインデックス」がカギ Datastoreサービスでは、あるテーブルに含まれるすべてのエンティティについて、すべてのプロパティ（テーブルのカラムに相当）の値をキーとして並べた「シングルプロパティインデックス」と呼ばれるインデックステーブルが自動的に作成されます。 例えば、テーブルEmpが備える「name」「age」「dept_key」という3つのプロパティについて、「テーブル名＋プロパティ名＋プロパティ値」をキーとし、「Empテーブルの各行のキー」を値とする以下のようなインデックステーブルが作成されます。 Datastoreサービスでは、このシングルプロパティインデックスを用いることにより、アプリケーションが実行するクエリを「インデックスとスキャンの組み合わせ」に背後で変換しています。 例えば、上述の「age >=
Song of Cloud: Slim3 Datastoreに乗り換える(1)
Slim3 DatastoreはGoogle App Engine for Javaのデータストアを操作するライブラリです。 最近JDOからSlim3 Datastoreに乗り換えつつあるので、背景や使い方などをつらつらと書いていきます。 Slim3 Datastoreの特徴 Slim3 Datastoreはデータストア低レベルAPIの薄いラッパーとして作成されています。他のラッパープロダクト(JDO/JPA)と違いApp Engineのデータストア専用に作られているため、提供される機能が非常に直感的で、さらにかなり高速に動きます。 ざっくり説明すると、以下のような機能を提供しています。 データストア上のデータと自作のモデルオブジェクトを相互に変換する 他にも色々とあった気がしますが、Slim3 Datastoreを利用する最大のメリットは上記の点でしょう。 しかもこの変換層をコンパイル時
GAE/Jでのインデックスの削除方法が分からない
検索するクエリを多く書いていくと、インデックスが増えていく。 GAE/Jでエンティティを抽出するときは、直接BigTable上のエンティティにフィルタリングしにいくのではなく、別途作成されたインデックスに対してフィルタリングを行う、という仕様になっているらしい。 参考：Java データストアのインデックスの設定 - Google App Engine - Google Code インデックスが増加していくことは仕方ないことなのか、パフォーマンスなどのことを考えて、なるべくインデックスは増やさない方がいいのか、調査する。 すると、やはりGAE/Jでは==などの条件指定に限り、そのほかの条件による絞込みやソートはJavaのロジック側で実装した方が無難らしい。 参考：ローカルでは動作するが、GAE/J環境でエラーになってしまう - Slim3 User Japan | Google グループ エ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Sign in - Google Accounts