OPTIMISTIC_WITH_ENTITY_GROUPS并发模式的目的是什么？

Question

Cloud Firestore in Datastore 模式记录了三个并发模式选项：OPTIMISTIC、OPTIMISTIC_WITH_ENTITY_GROUPS 和 PESSIMISTIC。 https://cloud.google.com/datastore/docs/concepts/transactions#concurrency_modes

OPTIMISTIC好像是推荐的模式，但是当我的Legacy Datastore在Datastore自动升级到Cloud Firestore时，自动设置为OPTIMISTIC_WITH_ENTITY_GROUPS。我有时会收到以下错误：

google.api_core.exceptions.Aborted: 409 too much contention on these datastore entities. please try again.

我正在考虑切换到 OPTIMISTIC，但我不知道它是否会破坏任何东西。为什么需要使用 OPTIMISTIC_WITH_ENTITY_GROUPS？似乎 Datastore 在任何模式下都支持祖先和实体组（我不认为我正在使用该功能）。它是否仅适用于第一代 App Engine（例如 Python 2 运行时）？我已经切换到第二代 Python 3.

谢谢。

Answer 1

你想留下来的原因真的只有三个

OPTIMISTIC_WITH_ENTITY_GROUPS

：

1. 您需要写入在整个实体组中是原子的。考虑这个例子：

   • 一个事务访问实体

     Foo/1/Bar/1

     ，第二个并发事务访问

     Foo/1/Bar/2

     。这两项交易都涉及同一实体组中的不同实体

     Foo/1

     .
   • 你希望两笔交易都成功吗？在这种情况下，您必须使用

     OPTIMISTIC

     并发。
   • 或者您是否希望其中一项交易因“太多争用”而失败？在那种情况下，你需要

     OPTIMISTIC_WITH_ENTITY_GROUPS

     .
   • 你被迁移到

     OPTIMISTIC_WITH_ENTITY_GROUPS

     的最可能原因是，你的一些交易在这种情况下失败了，迁移自动化无法判断你是否依赖于这种失败。换句话说，在不了解您的代码的情况下，无法判断“争用失败”对您来说是错误还是功能。所以安全的选择是不改变行为。
   • 为了回答这个问题，您必须检查您的应用程序逻辑并查看您所依赖的事务保证。这不能自动化，但对于熟悉应用程序不同模块的人来说，对此进行推理可能并不难。

2. 如果您使用实体组时间戳，您还需要

   OPTIMISTIC_WITH_ENTITY_GROUPS

   - https://cloud.google.com/appengine/docs/legacy/standard/python/datastore/metadataqueries#entity_group_metadata
   • 如果是这种情况，很可能有解决方法。例如，您可以在每次对实体组进行更改时自己事务性地编写一个时间戳。这可能会被分片，因此您不一定要创建热实体密钥。
   • 这也会被迁移自动化检测到，这可能是您最终得到

     OPTIMISTIC_WITH_ENTITY_GROUPS

     的另一个原因。

3. 您需要

   OPTIMISTIC_WITH_ENTITY_GROUPS

   的最后一个原因是您正在通过远程API使用数据存储-https://cloud.google.com/appengine/docs/legacy/standard/python/tools/remoteapi
   • Remote API 依赖于

     OPTIMISTIC_WITH_ENTITY_GROUPS

     ，目前没有解决这个问题的计划。
   • 如果您使用的是没有交易和查询的 Remote API，您仍然可以切换到

     OPTIMISTIC

     但这会非常危险，建议您找到 Remote API 的替代方案。

除了这三个原因，你总是对

OPTIMISTIC

更好。以下是有关如何进行切换的更多信息：https://cloud.google.com/datastore/docs/upgrade-to-firestore#transactions