google-app-engine - 谷歌应用引擎 : Is This a Good set of Entity Groups?

Question

我正在努力研究 Google AppEngine 中的实体组。我大体上理解它们，但由于听起来您无法在创建对象后更改关系，而且我要进行大数据迁移，所以我想尝试在第一时间做到正确。

我正在制作一个艺术网站，成员(member)可以在其中注册为普通成员(member)或少数非多态实体“类型”(艺术家、 field 、组织、艺术家代表等)之一。例如，艺术家可以拥有艺术品，而艺术品又可以拥有其他关系(画廊、媒体等)。所有这些都是通过引用连接起来的，我知道你不需要实体组来仅仅做引用。但是，一些引用需要存在，这就是我查看实体组的原因。

来自文档:“实体组的一个好的经验法则是它们的大小应该与单个用户的数据值(value)或更小。”

也就是说，我有几个希望是/否的问题。

问题 0:我了解到您不需要实体组来进行交易。但是，由于实体组存储在 Big Table 的同一区域中，这有助于减少一致性问题和竞争条件。这是对实体组和事务的公平看待吗？

问题 1:保存子实体时，是否会隐式访问/保存任何父对象？即，如果我使用路径 Member/Artist/Artwork 设置一个实体组，如果我保存一个 Artwork 对象，Member 和 Artist 对象是否得到更新/访问？我认为不会，但我只是在确定。

问题 2:如果问题 1 的答案是肯定的，访问/更新是否只沿路径传播而不影响其他 child 。即，如果我更新 Artwork，则不会更新 Member 的其他 Artwork 子项。

问题 3:假设当用户注册时成员(member)及其关联的账户类型实体存在非常重要，并且只有用户会更新其成员(member)和关联的账户类型实体，将它们放入是否有意义实体组在一起？

即成员(member)/艺术家、成员(member)/组织、成员(member)/ field 。

同样，假设只有用户能够更新 Artwork 实体，是否也包含这些实体有意义？注意:引用艺术作品的媒体/画廊/等可能与许多艺术作品相关，而不仅仅是用户拥有的作品(即多对多关系)。

如果它以我怀疑的方式工作(即 Q1/Q2 为“否”)，那么将所有用户位放在一个实体组中是有意义的，因为它们都将位于 BigTable 的同一区域中。然而，将艺术品添加到实体组似乎可能违反“保持小”的原则，老实说，除了在用户上传艺术品图像时节省带宽/重试之外，可能不需要在交易中。

有什么想法吗？我接近实体组是错误的吗？

Answer 1

• 0:您确实需要实体组来进行多个实体之间的交易
• 1:修改/访问子级不会修改/访问父级
• 2:不适用
• 3:听起来很合理。我的感觉是，除非您需要在它们之间进行交易，否则不应使用实体组。

出于许可目的，没有必要将艺术品作为 child 。但是如果您需要对它们进行事务性修改(包括例如创建和删除)，它可能会更好。例如:如果您删除一个帐户，则会删除用户实体，但在删除 child 之前，您会收到 DeadlineExceeded 或服务器崩溃。现在你有一个孤立的艺术品。如果您的某个艺术家的作品超过 1000 件，则必须批量删除。

祝你好运!