Google Appengine：这是一组好的实体组吗？

Posted 2023-03-24

【中文标题】Google Appengine：这是一组好的实体组吗？

【英文标题】：Google Appengine: Is This a Good set of Entity Groups?

【发布时间】：2010-01-29 17:35:37

【问题描述】：

我正试图围绕 Google AppEngine 中的实体组。我大体上理解它们，但是由于听起来一旦创建对象就无法更改关系并且我要进行大数据迁移，因此我想尝试在第一时间就正确处理。

我正在创建一个艺术网站，会员可以注册为普通会员或少数非多态实体“类型”之一（艺术家、场地、组织、艺术家代表等）。例如，艺术家可以拥有艺术品，而艺术品又可以拥有其他关系（画廊、媒体等）。所有这些东西都通过引用联系起来，我知道您不需要实体组来仅仅做引用。但是，一些参考需要存在，这就是我关注实体组的原因。

来自文档： “实体组的一个好的经验法则是，它们的大小应该与单个用户的数据价值差不多或更小。”

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

问题 0：我认为您不需要实体组来进行交易。但是，由于实体组存储在大表的同一区域中，这有助于减少一致性问题和竞争条件。这是对实体组和交易的公平看法吗？

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

问题 2：如果问题 1 的答案是肯定的，那么访问/更新是否只会沿着路径进行而不影响其他孩子。即，如果我更新 Artwork，则不会更新 Member 的其他 Artwork 子项。

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

即会员/艺术家、会员/组织、会员/场地。

同样，假设只有用户能够更新 Artwork 实体，是否也包含这些实体？注意：引用 Artwork 的 Media/Gallery/etc 可能与很多 Artwork 相关，而不仅仅是用户拥有的那些（即多对多关系）。

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

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

【参考方案1】：

0：您确实需要实体组来处理多个实体之间的事务 1：修改/访问子不修改/访问父 2：不适用 3：听起来很合理。我的感觉是，除非你需要它们之间的交易，否则不应该使用实体组。

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

祝你好运！

【讨论】：

谢谢你！我认为这为我设置迁移提供了一个良好的开端。

如何批量删除？