问题标签 [entity-groups]

我知道有关实体组如何在 GAE 存储中工作的所有详细信息，但昨天（在帕洛阿尔托的 App Engine 聚会上），当一位演讲者解释他对实体组的使用时，我突然意识到我从未真正使用过它们在我自己的 GAE 应用程序中，我不记得在我使用过的开源 GAE 应用程序中看到它们。

所以，我怀疑我只是忽略了（没有注意到或记住）这样的例子，因为我根本不习惯它们，无法立即将“使用实体组”与“正在解决的应用程序问题类型”联系起来——而且我认为我应该通过研究这些资源来解决这个问题，重点关注 EG 使用正在解决的问题（即，为什么应用程序可以使用它，但没有它就无法工作或无法正常工作）。

任何人都可以建议此类代码的好 URL 吗？（论文也将受到欢迎，如果他们专注于应用程序级问题的解决，但如果像我所见过的大多数人一样，他们只关注 EG 如何工作的细节！-）。

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

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

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

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

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

问题 1：保存子实体时，是否有任何父对象被隐式访问/保存？即，如果我使用路径成员/艺术家/艺术品设置实体组，如果我保存艺术品对象，成员和艺术家对象是否得到更新/访问？我不认为，但我只是确定。

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

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

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

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

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

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

更新：经过进一步测试，这个问题似乎影响了我的实体组中的所有子实体。所有这些不同实例的根父级是用户类型，这是我自己创建的，而不是内置的用户类型。从子 Kind 的构造函数中删除 parent=user 后，get_by_key_name 将按预期工作。但是，如果可能的话，我希望能够将实体组功能与定义的键一起使用。

-- 嗨，我正在尝试在我的 GAE 项目中使用定义的键名来加快查询速度。

但是，我遇到了一个奇怪的问题，我无法获取它们的密钥。此代码似乎不起作用：

一些注意事项：

• 我只在 SDK 中测试过

• l.key().name() 当我查看数据存储时，返回与实体一起列出的键名字符串。我可以将字符串从数据故事中复制并粘贴出来，并将其用作 get_by_key_name() 的参数，但这也不起作用。

• Login 类型的键名都以“l”（即小写“L”）为前缀，否则都是小写的，可能包含下划线或破折号，但小于 500 个字节。

• 其他种类的 serches 喜欢这项工作。

• 关键是 Login 类型的 2 个属性的插值，我可以使用常规 .filter() 方法很好地获取对象
• 实例的“父级”是一个用户类。（提到以防这对我必须获取的方式有影响）

所以我不得不问，是否有任何明显的原因导致这不起作用？使用 SDK 进行键名搜索的任何已知问题？

我正在使用 JDO 构建基于 google app engine (Java) 的应用程序以实现持久性。

有人可以给我一个例子或指出一些代码，这些代码显示在事务中使用 javax.jdo.PersistenceManager.makePersistentAll() 持久化多个实体（相同类型）。

基本上我需要了解如何将多个实体放在一个实体组中，以便可以在事务中使用 makePersistentAll() 保存它们。

简短的问题：

实体组的母公司是否包含在该实体组中（即交易是否会影响实体的母公司以及实体本身）？

谢谢。

继我之前关于 GAE 数据存储实体层次结构的问题之后，我仍然对何时使用实体组感到困惑。

举个简单的例子：

• 每个Company都有一个或多个Employee实体
• anEmployee不能移动到另一个Company，与一个打交道的用户Company永远看不到Employee另一个的 s 。Company

这看起来像是我可以制作Employee的子实体的情况Company，但实际后果是什么？这会提高可扩展性、损害可扩展性还是没有影响？使用或不使用实体层次结构的其他优点/缺点是什么？

（实体组启用事务，但在此示例中假设我不需要事务）。

我已经四处寻找这个问题的答案，但没有找到任何关于钱的东西。我真的很想听听人们的想法。开始：

在 Google AppEngine 中，假设我有许多 User 对象，每个对象都可以有许多 Photo 对象。User 对象需要是其各自 Photo 对象的父对象。

但我也希望能够为每张照片提供漂亮的短网址。我打算通过对每张照片的自动生成的 ID 属性进行 Base64 编码来生成这些，但我意识到我不能这样做，因为 AppEngine 生成的 ID 不能保证在实体组之间是唯一的（即对于具有不同父级的实体）。因此，可以想象作为一个用户的孩子的照片与作为不同用户的孩子的照片具有相同的 ID。

这让我陷入困境。我可以：

1. 尝试想出我自己独特的 ID 生成器并使用它

2. 失去父->子层次结构，因此 ID 将是唯一的（根本不热衷于此）

3. 建议一些超级聪明的选项作为这个问题的答案

我真的希望选择3。

任何有关处理此问题的最佳方法的想法或想法都会很棒。

提前致谢。

编辑

就在发布后，我有了将迷你 URL 缩短服务整合到应用程序中的想法。我只需要一个没有父级的模型和一个指向我想要链接的照片的“键”属性。然后我可以对这个实体的 ID 进行 Base64 编码，我就完成了。你怎么看？

假设我有一个实体 A 和一个实体 B，A 是 B 的父级，也就是说，许多 B 可以是单个 A 的实体组的一部分。

现在，假设我向 HRD 提交了一堆 B（跨越许多实体组 - 即它们跨越许多 A 父母）。如果我现在查询单个实体组中的所有 B（即同一个 A 父级），我是否可以保证强一致性？这里的微妙之处在于，尽管我查询的是单个实体组，但原始 PUT 是针对多个实体组的。

我有一个名为 Movie 的实体。

我想为 Movie 实体提供一个 get_or_create 方法。现在每个电影实体都在自己的实体组中。

我读到我必须将它们放在同一个实体组中并使用事务来避免重复的实体。

我也可以选择我自己的唯一键，这将导致覆盖一些条目（幂等）而没有任何影响。

电影数量可以从 1 到 50000。在某些时候，我想把它们全部拿走。对单个实体组或多个实体组执行查询会更快吗？是否因为整个实体组存储在特定节点中而更快？

我的要求是快速阅读所有电影。

谢谢！

我的 Python 高复制数据存储应用程序需要一个包含 100,000 到 1,000,000 个条目的大型查找表。我需要能够为某些方法提供代码，该方法将返回与该代码关联的值（如果没有关联，则返回 None）。例如，如果我的表包含可接受的英语单词，那么我希望函数在找到该单词时返回 True，否则返回 False（或 None）。

我当前的实现是为每个表条目创建一个无父实体，并让该实体包含任何关联的数据。我将该实体的数据存储键设置为与我的查找代码相同。（我将所有实体放入它们自己的命名空间以防止任何键冲突，但这对于这个问题不是必需的。）然后我只需在代码上调用 get_by_key_name() 并获取相关数据。

问题是我无法在事务期间访问这些实体，因为我试图跨越实体组。回到我的例子，假设我想对聊天会话中使用的所有单词进行拼写检查。我可以访问聊天中的所有消息，因为我会给他们一个共同的祖先，但我无法访问我的单词表，因为那里的条目是无父的。我必须能够在事务期间引用该表。

请注意，我的查找表是固定的，或者很少更改。这再次与拼写检查示例匹配。

一种解决方案可能是在一个事务期间加载聊天会话中的所有单词，然后对它们进行拼写检查（保存结果），然后启动第二个事务，对保存的结果进行拼写检查。但这不仅效率低下，而且可能已将聊天会话添加到事务之间。这似乎是一个笨拙的解决方案。

理想情况下，我想告诉 GAE 查找表是不可变的，因此我应该能够在不抱怨事务中跨越实体组的情况下对其进行查询。但是，我看不出有任何方法可以做到这一点。

将表条目存储在内存缓存中很诱人，但这也有问题。这是大量的数据，但更麻烦的是，如果 GAE 启动了一个 memcache 条目，我将无法在事务期间重新加载它。

有谁知道大型全局查找表的合适实现？

请理解，我不是在寻找拼写检查网络服务或类似的东西。我使用单词查找作为示例只是为了清楚地说明这个问题，并且我希望为任何类型的大型查找表提供通用解决方案。