問題タブ [entity-group-transactions]

私は現在、トランザクション コストを削減するために、エンティティを 100 のバッチで Azure テーブル サービスに挿入する方法を書いています。

挿入されたエンティティは不変です。つまり、PartitionKey と RowKey が 2 つのエンティティ オブジェクト間で同一である場合、他のすべてのプロパティも同一であることを意味します。したがって、挿入後、エンティティは同じままであるため、このテーブルを更新する必要はありません。

私が直面している問題は、このバッチ内で、以前に挿入されたエンティティがないことを 100% 確信できないことです。したがって、(AddObject と SaveChanges を使用して) 通常どおりエンティティを挿入するだけでは、エンティティが既に存在するため、エンティティを追加できないというエラーでトランザクションが失敗する可能性があります。トランザクションはアトミックであるため、これはエンティティが追加されないことを意味します。

コストがかかりすぎるため、トランザクション内の各エンティティの存在を確認することはできません (エンティティごとに 1 つのクエリのコストがかかりすぎ、OR を使用した 1 つのクエリではテーブル全体のテーブル スキャンが発生します)。したがって、オブジェクトが存在しない場合はオブジェクトを追加し、存在する場合は無視するか更新する方法が必要です（エンティティは不変であるため、無視または更新は同じです）。

Azure Table Services でこれを実現するにはどうすればよいですか?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

オンライン選挙アプリの一意のキー名を作成する方法がわかりません。関連エンティティの典型的なセットを次に示します。

• 1 選挙
• 5人の候補者
• 100,000 人の有権者
• 最大100,000票

ここに記載されている理由により、Voter エンティティごとに一意のキー名が必要です。電子メール アドレスは、特定の選挙の有権者に対して一意ですが、必ずしも複数の選挙にまたがるとは限りません (同じ有権者が複数の選挙に参加する可能性があるため)。

選挙が有権者エンティティの親エンティティである場合、投票者の電子メールを選挙の親と組み合わせて使用​​することで、一意のキーとして十分です。Voter エンティティを更新する際にトランザクションを使用する必要があるため (有権者が複数回投票できないようにするため)、 docsに従って一度に更新できる Voter は 1 つだけなので、エンティティ グループは使用したくないと思います。

別の解決策として、フォームの投票者ごとに一意のキーを作成することもできます。

例えば、

これは、Voter エンティティごとに一意のキー名を作成する合理的な方法ですか?

I'm need to use XG (Cross group) transactions across some of my entity groups in Google App Engine. Unfortunately when I run any of these operations on my local Jetty (Eclipse) server, the App Engine development wrapper throws a "java.lang.IllegalArgumentException: transactions on multiple entity groups only allowed in High Replication applications".

This is extremely frustrating, as the exact same XG transactions run absolutely fine once my application is deployed on the live GAE servers. Does this mean I'll have to deploy my application any time I want to test my application now that I have XG transactions incorporated? Any help is greatly appreciated.

P.S. I'm using the low-level data store API because the original JDO layer I employed did not give me the loading detail granularity I needed, in case that makes a difference.

MSDN (http://msdn.microsoft.com/en-us/library/windowsazure/dd894038.aspx) によると、

• トランザクションには最大 100 個のエンティティを含めることができ、その合計ペイロードのサイズは 4 MB を超えない場合があります。

質問) グループ トランザクション リクエストを送信する前に、サイズが 4MB を超えないことを保証するためにペイロード サイズを測定するにはどうすればよいですか?

前もって感謝します！

ドキュメントから、どの先祖がトランザクションの境界であるかは明確ではありません。最も近いもの、またはルートのもの？

ルート エンティティ (A) があり、いくつかの子孫 (B1、B2 ... Bn) があり、それらは多くの祖先 (C1、C2 ...) を持つことができます。B エンティティに基づく祖先クエリで取得する C エンティティ (Cs) でトランザクションを作成します。質問は、ConcurrentModificationException別のトランザクションが B2 の下のいくつかの C を同時に変更した場合、B1 の下の C の変更は をスローしますか?

すべての C は、祖父母 A の下の同じエンティティ グループに属していますか、それともエンティティ グループも、より小さな「サブエンティティ グループ」に分割されていますか。つまり、B の下の C のすべてのグループは、独自のエンティティ グループを持っていますか?

質問と回答のコメント アプリケーションがあります (stackoverflow に似ています)。質問とそれに関連する回答およびコメントは、App Engine Docsで定義されているエンティティ グループの一部を論理的に形成します。

エンティティ グループ/祖先パスを使用してエンティティをグループ化したい理由は 2 つあります。

1. 質問と回答のエンティティを物理的にまとめて格納することで、クエリの効率を向上させます
2. 祖先クエリを実行できるようにするため、質問エンティティ (関係) に回答キーを保存する必要がなくなります

最終的に競合が発生するため、強い一貫性は必要ありません。

App Engine はエンティティ グループを更新時に常にロックしますか?それともトランザクションで更新が行われている場合にのみロックしますか? 言い換えれば、エンティティ グループは、トランザクションで強制的に更新を行うのか、それとも単にトランザクションを使用するオプションを提供するのか?