4

テーブル内のすべてのエンティティをバルクロードする必要があります。 (高速オンデマンドグラフトラバーサルアルゴリズムでは、必要に応じてロードするのではなく、メモリに格納する必要があります)。Google Datastore MultiQueryBuilderを使用して種類のすべてのエンティティを読み込むにはどうすればよいですか?

読み込み速度を上げるためには、これを並列化する必要があります。ですから、並列スレッドで複数のクエリを実行したいと思います。データベースから800個のエンティティ。

QuerySplitterがこの目的で使用されていますが、私たちはフレキシブル環境で動作しており、クライアントライブラリではなくAppengine SDKを使用しています。

MapReduceについて説明しましたが、これはメモリへの簡単なデータ読み込みを目的としたものではありません。 Memcacheは多少の意味がありますが、高速アクセスのために私は自分のアプリケーションのJVMのRAM内に密集したネットワークでこれらのオブジェクトをすべて必要としています。

MultiQueryBuilderこれを行う可能性があります。これは、クエリの実行中の部分で並列処理を提供します。

これらの3つのアプローチのいずれか、または他のアプローチを使用する場合、最も難しいのは、テーブル(種類)を大まかに800またはそれ以上のエンティティに分割するフィルタや他の形式のスプライトを定義することです。私は "オブジェクト1〜800"、 "801〜1600、..."というフィルターを作成しますが、それは実用的ではないことが分かります。だから、どうやってやるの?

答えて

1

エンティティをランダムなグループに分割することで同様の問題を解決しました。

各データストアエンティティにfloatプロパティを追加し、エンティティを保存するたびに0〜1の乱数を割り当てました。次に、さまざまなデータストアエンティティで作業を行うためにNスレッドを起動すると、各スレッドは1/Nのエンティティを処理していました。たとえば、スレッド0は、01/Nの間で設定されたランダムプロパティを持つすべてのエンティティを処理します。スレッド2は、ランダムプロパティが1/N2/Nの間にあるすべてのエンティティを処理します。

これは、完全に決定的ではなく、データストアエンティティに新しいプロパティを追加する必要があるという欠点があります。メリットは、何百万ものエンティティとスレッドに容易に拡張でき、スレッド間での作業の均等な分配が一般的です。

+0

ありがとうございます。それはうまくいくかもしれない。多くのデータベースに標準である機能性のために、無駄なフィールドを追加する必要があることは奇妙に思えます。これを行うための組み込み方法があるのだろうか? –

+0

はい、私が最初にそれを考えたとき(他の誰かが私にそれを提案した)、それはまた奇妙に感じました。しかし、Googleのデータベースは、分散され、ほぼ無限の量のデータを扱うように設計されていると考えてください。 Googleデータベースでは、テーブル内の要素の総数を簡単に判断できません( 'len'関数はありません)。 Googleがパーティション化アルゴリズムを実装した場合、テーブル内の要素の数を追跡する必要があります。この制約と他のものが与えられれば、ランダムフィールドは実際には意味があります。 – speedplane

+0

もう1つ:それが決定論的であるようにするには、エンティティに対してハッシュ関数を使用することもできます(つまり、各エンティティを半乱数にする)。ただし、ハッシュ関数を0から1(または使用している範囲)に均等に分散するように設計する必要があります。 – speedplane

関連する問題