Why should one choose an entity group transaction when XG (cross group) transaction can do the same job?

Question

Consider these two cases in app engine datastore design:

1. A is ancestor of B. We use a transaction to update this entity group.
2. A and B are both without an ancestor. We use an XG transaction to update both entities.

I can see these advantages in case 2:

• Just like case 1, it achieves atomicity.
• If I give A and B the string or integer id, given that they are different kinds, I can lookup one of them when I have the other one. This would be an equivalent for looking up by parent or child in case 1.
• Because the entities are not in the group, they do not suffer the write throughput limit.

Are the above points correct? When and why should case 1 be used over case 2?

Answer 1

XG事务只能跨越25个不同的实体组，因此对单个批次中可以进行的多个更改的数量进行限制。另外，使用祖先允许您对祖先组内的数据构建查询。

考虑一个简单的微博网站示例，用户可以在该网站上发帖并查看其他用户的帖子。您的主页显示所有用户的最新帖子，因此执行最终一致的查询以获取此数据是可以的（我们可以容忍这里的一些陈旧性）。但是，当用户发帖时，他们应该始终看到该帖子显示在他们的Feed中。

如果您将每个帖子存储在自己的EG中，那么您对用户帖子的查询可能如下所示：SELECT * FROM Post WHERE author = $current_user。但是，这最终是一致的。因此，用户可以发布帖子，然后不会将其显示在其Feed中。相反，我们可以利用EG并使每个Post成为创建它的User的孩子。然后，我们可以使用SELECT * FROM Post WHERE __key__ HAS ANCESTOR KEY('User', $current_user)查询单个用户的帖子。

在这种情况下，用户将被限制为每秒创建1个帖子，但是这与自然边界很好地对齐 - 此时用户被限制为键入a所需的时间交。