据我从应用引擎教程中了解到，实体组的存在仅用于交易目的：
“仅在事务需要时使用实体组”（来自教程）
在同一实体组中的定义是具有相同的根.. 在那种情况下，具有多个层次结构级别有什么用？ 也就是为什么要使用“A -> B -> C”（A是根，B是儿子，C是孙子） 而不是 "A -> B ; A -> C" ？ （A、B 和 C 仍然在同一个实体组中，因为 A 是它们的根）。
如果实体组的唯一目的是使实体之间的交易成为可能，我为什么要使用超过 1 个层次结构级别（我从 Root -> Grandson 链接获得什么）？
【问题讨论】：
当您进行查询时，您可以使用 ancestor() 将查询限制为特定实体的子代 - 在您的示例中，您可以只查找 B 的后代，如果他们无法做到这一点都是顶级的。
Programming Google App Engine 中有更多关于祖先查询的内容
Keys and Entity Groups 文档还说：
实体组关系告诉 App Engine 将多个实体存储在分布式网络的同一部分......一个组中的所有实体都存储在 同一个数据存储节点
编辑：同一文档还列出了您不希望实体组变得太大的一些原因：
您的实体组越多 应用程序有——也就是说，根越多 存在的实体——越多 数据存储可以有效地 将实体组分布在 数据存储节点。更好的分布 提高创建性能 和更新数据。还有，多 试图更新实体的用户 同时同一个实体组 将导致一些用户重试他们的 交易，可能导致一些 未能提交更改。不要把所有 下的应用程序实体 一个根。
对组中实体的任何事务都会导致对同一实体组的任何其他写入失败。如果您有一个包含大量写入的大型实体组，这会导致大量争用，然后您的应用程序必须处理预期的写入失败。 Avoiding datastore contention 更详细地介绍了可用于最小化争用的策略。
【讨论】：
实际上，事务是实体组的副作用。因为实体组行是位于同一位置的事务，所以它们上的事务是完全可能的。
我什至会声称实体组是数据存储的固有属性，使其类似于分层数据库。
【讨论】：
当你存储 A -> B -> C 时，A 有很多 B，而 B 有很多 C。当你存储 A -> B 和 A -> C 时，A 有很多 B，也有很多 C。换句话说，C 不属于单个 B。
您使用哪种结构实际上取决于您存储的数据。
当使用大量写访问时，您可能不得不对实体组做一些不直观的事情，请参阅 Sharding Counters 以获取此示例：
【讨论】：