据我所知，在应用引擎教程中，实体组仅用于交易目的：
“仅在事务需要时使用实体组”（来自教程）
在同一个实体组中的定义是具有相同的根。在这种情况下，具有多于1个层次结构级别的用途是什么？ 也就是说，我为什么要使用“A - > B - > C”（A是根，B是他的儿子，C是他的孙子） 而不是“A - > B; A - > C”？ （A，B和C仍然在同一个实体组中，因为A是它们的根）。
如果实体组的唯一目的是在实体之间进行交易，为什么我应该使用多于1个层次结构级别（我从Root获得什么 - ＆gt;孙子链接）？
答案 0 :(得分：17)
当您进行查询时，可以使用ancestor()将查询限制为特定实体的子项 - 在您的示例中，您只能查找B的后代，但您无法查找如果他们都在顶层，那就行。
Keys and Entity Groups doc也说：
实体组关系告诉App Engine将多个实体存储在分布式网络的同一部分中...组中的所有实体都存储在 相同的数据存储节点
编辑：同一文档还列出了您不希望实体组变得过大的一些原因：
您的实体组越多 应用程序 - 也就是说，根目录越多 那里的实体 - 更多 有效的数据存储区可以 分配实体组 数据存储节点。更好的分配 提高了创作的表现 并更新数据。还有，多个 尝试更新实体的用户 同一个实体组 会导致一些用户重试他们的 交易，可能导致一些 无法提交更改。不要把所有 应用程序的实体 一根。
组中实体的任何事务都将导致对同一实体组的任何其他写入失败。如果您有一个包含大量写入的大型实体组，则会导致大量争用，然后您的应用程序必须处理预期的写入失败。 Avoiding datastore contention详细介绍了可用于减少争用的策略。
答案 1 :(得分：1)
实际上，交易是实体组的副作用。因为实体组行是共同定位的事务，所以它们是可能的。
我甚至会声称实体组是数据存储区的固有属性，使其类似于分层数据库。
答案 2 :(得分：0)
当您存储A - ＆gt; B - ＆gt; C，A有很多B，B有很多Cs。当您存储A - ＆gt; B和A - ＆gt; C，A有很多B，有很多Cs。换句话说，C不属于单个B.
您使用的结构实际上取决于您要存储的数据。
当使用大量写入访问时，您可能不得不对实体组执行不直观的操作，请参阅Sharding Counters以获取此示例：