NDB HRD 事务，哪个祖先确定实体组？

Question

是被写入实体的最近还是最远的父亲属，它决定了实体组？ （问题 1）如果有的话，

两个同时请求写入两个不同的实体，在本例中，都具有 Data 实体的直接父级（键为“2”），并且具有以下的祖先：

Person:9 > Collection:3 > Script:4 > Data:2 > Record of Tom Cruise
Person:9 > Collection:3 > Script:4 > Data:2 > Record of Shia La Boef

在任何一种情况下，它们都属于同一个实体组，要么锚定在实体 Person:9，要么锚定在实体 Data:2。哪个是实体组的正确确定者，Person:9 或 Data:2？此外，如果有 两种实体源自 Data:2，例如 Record 和 Scheme，那么所有 Record 和 Scheme 实体是否属于同一个实体组，由 Data:2 锚定，或者，凭借属于不同的种类，属于不同的实体组？ （问题 2）

顺带一提，如果是Person:9决定了实体组，并且一个parent下的不同种类不会在那个parent下形成不同的实体组，那么everything都是Person:9的后代是同一个实体组，要连载，恐怖

由于在此示例中，我同时对同一个实体组执行这些相同类型的实体的写入，它们将被连续应用，因此与可以同时应用它们相比，需要“双倍的时间”。

对于这种“加倍”时间，有什么好的解决方案？ （问题 3 -- 可选！）

我想到了以下几点：

由于我知道两个单独的写入必须由两个单独的客户端实例启动，我可以向链中添加另一个祖先，它表示执行写入的客户端实例，如下所示：

Person:9 > Collection:3 > Script:4 > Data:2 > **Client:92** > Record of Tom Cruise
Person:9 > Collection:3 > Script:4 > Data:2 > **Client:37** > Record of Shia La Boef

这样写入将属于不同的实体组（只要 Person:9 锚定该组的假设是错误的），因此始终可以同时执行。 AppEngineer/专家可以对此进行权衡吗？ （问题 4）

此外，由于我实施了单独的客户端只能向数据存储发出串行请求的限制，并且我可以保证单个客户端进行的任何写入永远不会超过每秒 1 次，而不会对性能造成任何影响，以上方法，如果可行，将意味着对性能的影响为零，只要我有足够多的独立客户端（以及，他，足够的配额），我就可以进行尽可能多的写入以 HTTP 可以承载的速度尽可能快地传输到数据存储区。 AppEngineer/专家可以对此进行权衡吗？ （问题 5）

我看到的这种 组拆分 方法的唯一问题是，查询 Data:2 父级下的 Record 实体现在变得复杂了，即使尽管记录在语义上是相关的，但它们由不同的客户端分隔。所以为了收集所有记录，我需要先收集所有客户，然后收集那里的所有记录。任何人都可以看到这是否会产生极其可怕的性能影响，执行这种“查询您刚刚查询的孩子的所有孩子”查询......？ AppEngineer/专家可以对此进行权衡吗？ （问题 6）

Answer 1

你这里有一些误解。

首先，文档对实体组的构成非常明确：它是根实体下的一切。

但是，我不知道您从哪里得到这样的想法，即在实体组内写入在某种程度上比在实体组外更“连续”。文档没有说，或暗示它。它唯一提到的就是写入单个实体组的速度不超过每秒 1 次。

您的其余问题根本没有意义：向链中添加另一个元素不会更改根实体。

我不知道你为什么首先需要这么深的实体组链。文档的advice on scaling 是为了保持实体组较小。如果每个叶子实体只会被一个客户端写入，听起来客户端本身应该是根，路径的其余部分根本不应该是祖先的一部分：也许你可以使用 ReferenceProperty 来引用一个或多个实体通过其密钥。