Ndb強い一貫性と頻繁な書き込み

Question

私はPythonを使用してndbと強い整合性を達成しようとしています。 強く一貫していないように、読書が動くように私は何かが欠けているように見えます。

クエリは次のとおりです。

links = Link.query(ancestor=lead_key).filter(Link.last_status == 
None).fetch(keys_only=True) 

if links: 
    do_action() 

キー構造は、次のとおりです。

Lead root (generic key) -> Lead -> Website (one per lead) -> Link 

私はタスクキューを使用して同時に実行され、このクエリは、すべてのタスクの終了時に行われる多くのタスクを持っています。 last_statusフィールドを更新すると例外が多すぎることがありますが、再試行でそれを処理します。それは強い一貫性を破ることができますか？

last_statusがNoneに等しいリンクが残っていない場合、予期される動作はdo_action()です。実際の動作は矛盾しています。時にはdo_action()が2回呼び出され、まったく呼び出されないことがあります。

Answer 1

強力な一貫性を得るために祖先キーを使用することには限界があります。エンティティグループごとに1秒あたり1回の更新に制限されています。これを回避する1つの方法は、エンティティグループを分割することです。 Sharding Countersはこの技術を記載している。それは古い記事ですが、私が知る限り、アドバイスはまだ健全です。

Answer 2

チェックするべき第1のものであるDaveの回答に追加してください。

文書化されておらず、ちょっと驚くかもしれないことの1つは、競合が書き込み操作だけでなく読み取り操作によっても発生する可能性があることです。

トランザクションが開始されるたびに、アクセスされているエンティティグループ（読み取りまたは書き込み操作では関係ありません）は、そのようにマークされます。 too much contentionエラーは、並列トランザクションが多すぎると同時に同じエンティティグループにアクセスしようとしていることを示します。実際に書き込むトランザクションが1つもない場合でも発生することがあります。

注：この競合が開発サーバーによってエミュレートませあるGAE上で展開したとき、それが唯一の真のデータストアで、見ることができます！

混乱の原因になるのは、トランザクションの自動再試行であり、実際の書き込み競合または単純なアクセス競合の両方後に発生する可能性があります。これらの再試行は、コードパスの疑いのある繰り返し実行としてエンドユーザに表示されることがあります。do_action()のレポートが2回呼び出されたと説明できると思われます。

通常、このような問題が発生すると、データ構造やアクセスする方法（トランザクション）を再訪する必要があります。強い一貫性を維持するソリューション（非常に高価かもしれません）に加えて、一貫性が実際に必要であるかどうかを再確認したい場合があります。いくつかのケースでは、単に物事を単純化するように見えているので、毛布の要件として追加されています。私の経験からはそうではありません:)

Answer 3

あなたのコードが一度しか呼び出されないようにするサンプルはありません。

当面は、do_action関数がLinkエンティティに対して何かを行うと仮定します。具体的には、「last_status」プロパティを設定します。

トランザクション内のリンクエンティティへのクエリと書き込みを実行しないと、2つの異なる要求（タスクキュータスク）がクエリから結果を戻すことができます。リンクエンティティ（前の値を上書きする最後の書き込み）。

トランザクションを使用しても、トランザクションが正常に完了して誰も書き込みを実行しようとしなかったことがわかりません。これは、データストアの外部（たとえば、外部システムへのhttp要求の作成）に何かをしようとしている場合に重要です。同時に、並行変更例外で失敗するトランザクションからのHTTP要求が表示される可能性があります。