它是被写实体的最近或最远的父亲，它决定了实体组吗？ （问题1 ）因为，如果我有，
两个同时写入两个不同实体的请求，在这个例子中，两个实体都具有直接父数据实体（带有键'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。哪个是实体组的正确确定者，人：9或数据：2？此外，如果两种实体来自Data：2，比如Record和Scheme，那么所有Record和Scheme实体都属于同一个实体组，由Data：2锚定，或者，由美德不同种类，属于独立的实体群体？ （问题2 ）
顺便提一下，如果确定实体组的是Person：9，并且父级下的不同种类在该父级下不形成不同的实体组，则所有来自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 ）
答案 0 :(得分：2)
你有一些误解。
首先，文档对构成实体组的内容非常明确：它是根实体下的所有。
但是我不知道你在哪里认为实体组内的写入在某种程度上比外部的更“串行”。文档没有说明或暗示它。它对此的唯一说法就是对单个实体组的写入每秒不超过1次。
其余的问题完全没有意义：在链中添加另一个元素不会改变根实体。
我不确定为什么你首先需要这么深的实体组链。文档的advice on scaling是为了保持实体组的小。如果每个叶子实体只会被一个客户端写入，听起来客户端本身应该是根，并且路径的其余部分根本不应该是祖先的一部分：也许您可以使用ReferenceProperty来引用这些实体中的一个或多个通过其密钥。