問題タブ [entity-groups]

エンティティグループがGAEのストレージでどのように機能するかについてはすべて詳しく知っていますが、昨日（パロアルトで開催されたApp Engineのミートアップで）、プレゼンターがエンティティグループの使用について説明していたので、実際にそれらを使用したことがないことに気付きました。私自身のGAEアプリで、私が使用したオープンソースのGAEアプリでそれらが使用されているのを見たのを覚えていません。

ですから、私はそのような例を見落としている（気づいていない、覚えていない）のではないかと思います。なぜなら、「エンティティグループの使用」を「解決されているアプリケーションの問題の種類」にすぐに結び付けるのに十分に慣れていないからです。この目標を念頭に置いてこのようなソースを調査し、EGの使用が解決している問題（つまり、アプリがアプリで機能するのに、アプリが機能しない、または機能しない理由）に焦点を当てることで、改善する必要があると思います。

誰かがそのようなコードに良いURLを提案できますか？（エッセイは、アプリケーションレベルの問題解決に焦点を当てている場合も歓迎されますが、私が見たほとんどのように、EGがどのように機能するかの詳細に焦点を当てている場合はそうではありません！-）。

GoogleAppEngineのエンティティグループに頭を悩ませようとしています。一般的には理解していますが、オブジェクトが作成されると関係を変更できないようで、ビッグデータの移行が必要なため、最初から正しく設定するようにしたいと思います。

私は、メンバーが通常のメンバーとして、または少数の非多形エンティティの「タイプ」（Artist、Venue、Organization、ArtistRepresentativeなど）の1つとしてサインアップできるArtサイトを作成しています。たとえば、アーティストはアートワークを持つことができ、アートワークは他の関係（ギャラリー、メディアなど）を持つことができます。これらはすべて参照を介して接続されており、単に参照を行うためにエンティティグループは必要ないことを理解しています。ただし、いくつかの参照が存在する必要があるため、エンティティグループを調べています。

ドキュメントから：「エンティティグループの経験則として、1人のユーザーに相当するデータのサイズ以下にする必要があります。」

そうは言っても、はい/いいえの質問がいくつかあります。

質問0：トランザクションを実行するためだけにエンティティグループは必要ないようです。ただし、エンティティグループはBig Tableの同じ領域に保存されるため、一貫性の問題と競合状態を減らすのに役立ちます。これは、エンティティグループとトランザクションを一緒に公正に見ていますか？

質問1：子エンティティが保存されると、親オブジェクトは暗黙的にアクセス/保存されますか？つまり、パスMember / Artist / Artworkを使用してエンティティグループを設定した場合、Artworkオブジェクトを保存すると、MemberオブジェクトとArtistオブジェクトが更新/アクセスされますか？私はそうは思わないでしょうが、私はただ確認しているだけです。

質問2：質問1の答えが「はい」の場合、アクセス/更新はパスをたどるだけで、他の子供には影響しませんか。つまり、アートワークを更新しても、メンバーの他のアートワークの子は更新されません。

質問3：ユーザーがサインアップするときにメンバーとそれに関連するアカウントタイプのエンティティが存在し、ユーザーのみがそのメンバーと関連するアカウントタイプのエンティティを更新することが非常に重要であると仮定すると、これらをエンティティグループにまとめることは理にかなっていますか？ ？

すなわち、メンバー/アーティスト、メンバー/組織、メンバー/会場。

同様に、ユーザーだけがアートワークエンティティを更新できると仮定すると、それらも含めるのは理にかなっていますか？注：アートワークへの参照であるメディア/ギャラリーなどは、ユーザーが所有するものだけでなく、多くのアートワークに関連している可能性があります（つまり、多対多の関係）。

すべてのユーザーのビットがBigTableの同じ領域にあるため、私が思うように機能する場合（つまり、Q1 / Q2は「いいえ」）、エンティティグループにすべてのユーザーのビットを含めることは理にかなっています。ただし、アートワークをエンティティグループに追加すると、「小さく保つ」という原則に違反する可能性があり、正直なところ、ユーザーがアートワーク画像をアップロードするときに帯域幅/再試行を節約する以外に、トランザクションに含める必要がない場合があります。

何かご意見は？エンティティグループへのアプローチが間違っていますか？

更新: さらにテストした結果、この問題はエンティティ グループ内のすべての子エンティティに影響するようです。これらすべての異なるインスタンスのルートの親は、組み込みのユーザーの種類ではなく、私自身が作成したユーザーの種類です。子 Kind のコンストラクターから parent=user を削除すると、get_by_key_name が期待どおりに機能します。ただし、可能であれば、定義済みのキーと共にエンティティ グループ機能を使用できるようにしたいと考えています。

-- こんにちは、GAE プロジェクトでクエリを高速化するために、定義済みのキー名を使用しようとしています。

ただし、キーを取得できないという奇妙な問題に遭遇しました。このコードは機能していないようです:

いくつかのメモ:

• SDKでのみテストしました

• l.key().name() データ ストアを参照すると、エンティティと共にリストされたキー名の文字列を返します。データ ストーリーから文字列をコピー アンド ペーストし、それを get_by_key_name() の引数として使用できますが、それも機能しません。

• ログインの種類のキー名はすべて "l" (つまり小文字の "L") で始まり、それ以外はすべて小文字で、アンダースコアまたはダッシュを含むことができますが、500 バイト未満です。

• この作品のような他の種類のサーチェ。

• 重要なのは、Login の種類の 2 つのプロパティの補間であり、通常の .filter() メソッドを使用してオブジェクトをうまく取得できます。
• インスタンスの「親」は User クラスです。（これが私が取得しなければならない方法に何らかの関係がある場合に言及する）

だから私は尋ねなければなりません、これがうまくいかない明らかな理由はありますか? SDK を使用したキー名検索に関する既知の問題はありますか?

永続性のためにJDOを使用してGoogleAppEngine（Java）に基づくアプリを構築しています。

誰かが私に例を教えたり、トランザクション内でjavax.jdo.PersistenceManager.makePersistentAll（）を使用して（同じタイプの）複数のエンティティの永続化を示すコードを教えてもらえますか？

基本的に、トランザクション内でmakePersistentAll（）を使用して保存できるように、1つのエンティティグループに複数のエンティティを配置する方法を理解する必要があります。

短い質問：

エンティティグループの親はそのエンティティグループに含まれていますか（つまり、トランザクションはエンティティの親とエンティティ自体に影響を与える可能性があります）？

ありがとう。

GAE Datastore のエンティティ階層に関する以前の質問に続き、いつエンティティ グループを使用するかについてまだ混乱しています。

次の簡単な例を見てください。

• すべてCompanyに 1 つ以上のEmployeeエンティティがあります
• を別の に移動するEmployeeことはできずCompany、ある を処理するユーザーは別の の をCompany見ることはできませんEmployeeCompany

Employeeこれはの子エンティティを作成できるケースのように見えますCompanyが、実際にはどのような結果になるのでしょうか? これにより、スケーラビリティが向上しますか、スケーラビリティが損なわれますか、それとも影響はありませんか? エンティティ階層を使用する場合と使用しない場合のその他の利点/欠点は何ですか?

(エンティティ グループはトランザクションを有効にしますが、この例ではトランザクションは必要ないと仮定します)。

私はこの質問への答えを探し回っていましたが、お金にまったく何も見つかりませんでした。人々の考えを聞いて本当に興味があります。ここに行きます：

Google AppEngineで、いくつかのUserオブジェクトがあり、それぞれに複数のPhotoオブジェクトを含めることができるとします。Userオブジェクトは、それぞれのPhotoオブジェクトの親である必要があります。

ただし、写真ごとに短いURLを設定できるようにもしたいと思います。各写真の自動生成されたIDプロパティをBase64エンコードすることでこれらを生成するつもりでしたが、AppEngineが生成するIDはエンティティグループ間で一意であることが保証されていないため（つまり、親が異なるエンティティの場合）、これを実行できないことに気付きました。したがって、あるユーザーの子である写真は、別のユーザーの子である写真と同じIDを持っている可能性があります。

これは私を漬物に残します。私は次のいずれかを行うことができます：

1. 私自身の一意のIDジェネレーターを考え出し、それを使用してみてください

2. 親->子階層を失い、IDが一意になるようにします（これにはまったく熱心ではありません）

3. この質問への答えとして提案されたいくつかの超賢いオプション

私は本当にオプション3を望んでいます。

これに対処するための最良の方法についての考えやアイデアは素晴らしいでしょう。

前もって感謝します。

編集

投稿した直後、アプリにミニURL短縮サービスを組み込むことを思いつきました。親がなく、リンクしたい写真を指す単一の「Key」プロパティを持つモデルが必要です。次に、このエンティティのIDをBase64でエンコードできます。これで完了です。どう思いますか？

エンティティ A とエンティティ B があるとします。A は B の親です。つまり、多くの B が 1 つの A のエンティティ グループの一部になることができます。

ここで、HRD に一連の B を配置したとします (多くのエンティティ グループにわたって、つまり、多くの A の親にわたって)。単一のエンティティ グループ (つまり、同じ A の親) 内のすべての B に対してクエリを実行すると、強い一貫性が保証されますか? ここでの微妙な点は、単一のエンティティ グループに対してクエリを実行しているにもかかわらず、元の PUT が複数のエンティティ グループに対して行われたことです。

Movie というエンティティがあります。

Movie エンティティの get_or_create メソッドが必要です。現在、各ムービー エンティティは独自のエンティティ グループに属しています。

それらを同じエンティティグループに入れ、トランザクションを使用してエンティティの重複を避ける必要があることを読みました。

また、独自の一意のキーを選択することもできます。これにより、いくつかのエントリが上書きされ (べき等)、何の影響もありません。

ムービー数は 1 ～ 50000 です。ある時点で、それらすべてを取得したいと思います。単一のエンティティ グループまたは複数のエンティティ グループに対してクエリを実行する方が高速ですか? エンティティ グループ全体が特定のノードに格納されているため、高速ですか?

私の要件は、すべての映画をすばやく読むことです。

ありがとう！

私の Python High Replication Datastore アプリケーションには、100,000 ～ 1,000,000 エントリの大きなルックアップ テーブルが必要です。そのコードに関連付けられた値 (関連付けがない場合は None) を返すコードをメソッドに提供できるようにする必要があります。たとえば、テーブルに受け入れ可能な英語の単語が含まれている場合、その単語が見つかった場合は関数が True を返し、それ以外の場合は False (または None) を返します。

私の現在の実装は、テーブル エントリごとに 1 つの親のないエンティティを作成し、そのエンティティに関連データを含めることです。そのエンティティのデータストア キーをルックアップ コードと同じに設定しました。(キーの競合を防ぐために、すべてのエンティティを独自の名前空間に配置しますが、この質問には必須ではありません。) 次に、コードで get_by_key_name() を呼び出すだけで、関連付けられたデータを取得します。

問題は、複数のエンティティ グループにまたがろうとするため、トランザクション中にこれらのエンティティにアクセスできないことです。例に戻って、チャット セッションで使用されるすべての単語のスペル チェックを行いたいとしましょう。チャット内のすべてのメッセージに共通の祖先を与えることでアクセスできましたが、エントリに親がないため、単語テーブルにアクセスできませんでした。トランザクション中にテーブルを参照できることが不可欠です。

私のルックアップテーブルは固定されているか、めったに変更されないことに注意してください。これもスペルチェックの例と一致します。

解決策の 1 つは、1 つのトランザクション中にチャット セッション内のすべての単語を読み込み、それらの単語をスペル チェック (結果を保存) してから、保存された結果に対してスペル チェックを行う 2 番目のトランザクションを開始することです。しかし、これは非効率であるだけでなく、トランザクションの間にチャット セッションが追加された可能性があります。これは不器用な解決策のようです。

理想的には、ルックアップ テーブルが不変であることを GAE に伝えたいと考えています。これにより、トランザクション内の複数のエンティティ グループについて不平を言うことなくクエリを実行できるはずです。ただし、これを行う方法はありません。

テーブル エントリを memcache に格納するのは魅力的ですが、これにも問題があります。これは大量のデータですが、さらに厄介なのは、GAE が memcache エントリを起動すると、トランザクション中に再読み込みできなくなることです。

大規模なグローバル ルックアップ テーブルの適切な実装を知っている人はいますか?

私がスペル チェック Web サービスなどを探しているわけではないことを理解してください。この質問を明確にするためだけに単語ルックアップを例として使用していますが、あらゆる種類の大きなルックアップ テーブルの一般的な解決策を望んでいます。