0

Google App Engine (高レプリケーション データストア) を試しています。1 つのエンティティ グループに頻繁に書き込むと競合が発生する可能性があることを理解しています。そのようなことが起こらないようにするために、私のエンティティはすべてルート エンティティです。つまり、各エンティティは個別のエンティティ グループです。

取引を開始します

エンティティを取得する

すでに存在する場合は、トランザクションをロールバックします

そうでなければエンティティを置き、トランザクションをコミットします

だから私は、関連のないエンティティ (つまり、同じエンティティ グループに属していないエンティティ) に対して、アプリ エンジンが主張する高スループットの強みを活用していると考えました。

ただし、時々、「これらのエンティティに対する競合が多すぎます」という恐ろしい例外が発生します。同じグループに属さないエンティティで競合が発生するのはなぜですか?

1 つのエンティティ グループに対して、1 秒あたり 1 ～ 10 回の書き込みしか期待できないと言われています。

しかし、アプリエンジンが個別のエンティティグループへの書き込みを処理することを期待できる数値は見ていません。競合は、私が非常に低い要求であると考えるものに対して発生しているようです (1 秒あたり約 100 書き込み)。

何か不足していますか？個別のエンティティ グループを持つだけでなく、高いスループットを得るために準拠する他のルールはありますか?

それとも、1 秒あたり少なくとも数百回の書き込みという私の期待は、単純に高すぎるのでしょうか?

4

3 に答える 3

0

回答を削除する方法がわからないので、これを編集しています。

例外の getMessage は、「競合が多すぎます」というメッセージを返します。ただし、例外のクラスは ConcurrentModification です。

1 回のリクエストで複数のルート エンティティを更新しているため、別のリクエストが自分のリクエストと同じデータを同時に変更する可能性はありません

ですから、この「競合」がどこから来ているのかわかりません。

単一の要求がそれ自体と「競合」しているようです!

1 つの考えとしては、put の非同期性のために、最初の操作が完全に完了してから次の操作が行われるということですか?

これらは別個のエンティティ グループであるため、問題は「タブレットの分割」などによって引き起こされているに違いないと思います。その場合、これらすべての失敗が呼び出し元に ConcurrentModification 例外として提示されるのは残念だと思います。データストアの内部プロセスが原因で失敗した操作と、別のユーザーがデータを変更する前にデータを変更したなどのより通常の問題を区別できると便利だと思います

于 2013-10-05T20:07:37.437 に答える
0

最初の間違いは、エンティティ グループの使用です。競合を避けるためのものではありません。その正反対です。エンティティ グループの項目を頻繁に更新することはできません。ドキュメントを参照してください。エンティティ グループは、競合や速度ではなく、一貫した読み取りに役立ちます。

于 2013-10-05T14:23:26.973 に答える