问题标签 [entity-group-transactions]

我目前正在编写一种方法，为了降低交易成本，将实体以 100 个批次插入 Azure 表服务。

插入的实体是不可变的。即，如果两个实体对象之间的 PartitionKey 和 RowKey 相同，则意味着所有其他属性也相同。因此，我永远不需要更新此表，因为插入后实体将保持不变。

我面临的问题是，在这批中，我不能 100% 确定之前没有插入任何实体。因此，如果我只是正常插入实体（通过 AddObject 和 SaveChanges），则事务可能会失败，并出现无法添加实体的错误，因为它已经存在。由于事务是原子的，这意味着没有添加任何实体。

我无法检查事务中是否存在每个实体，因为这样做成本太高（每个实体一个查询的成本太高，而使用 OR 的单个查询会导致整个表的表扫描）。因此，我需要某种方法来添加一个对象，如果它不存在并忽略它或更新它，如果它存在（忽略或更新对我来说是相同的，因为实体是不可变的）。

如何在 Azure 表服务中实现这一点？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我无法弄清楚如何为我的在线选举应用程序创建唯一的键名。这是一组典型的相关实体：

• 1 选举
• 5名候选人
• 100,000 名选民
• 最多 100,000 票

出于此处所述的原因，我需要为每个 Voter 实体设置一个唯一的键名。电子邮件地址对于特定选举中的选民来说是唯一的，但不一定跨多次选举（因为同一选民可能是多次选举的一部分）。

如果选举是选民实体的父实体，那么将选民电子邮件与选举父实体结合使用就足以获得唯一密钥。由于我需要在更新 Voter 实体时使用事务（以确保选民不能多次投票），我想我不想使用实体组，因为根据docs一次只能更新一个 Voter 。

另一种解决方案可能是为表单的每个选民创建一个唯一的密钥：

例如，

这是为每个 Voter 实体创建唯一键名的合理方法吗？

我需要在 Google App Engine 中的一些实体组中使用 XG（跨组）事务。不幸的是，当我在本地 Jetty (Eclipse) 服务器上运行任何这些操作时，App Engine 开发包装器会抛出“java.lang.IllegalArgumentException：多个实体组上的事务仅在高复制应用程序中允许”。

这非常令人沮丧，因为一旦我的应用程序部署在实时 GAE 服务器上，完全相同的 XG 事务运行得非常好。这是否意味着既然我已经合并了 XG 事务，我就必须在任何时候想要测试我的应用程序时部署我的应用程序？任何帮助是极大的赞赏。

PS 我使用的是低级数据存储 API，因为我使用的原始 JDO 层没有给我所需的加载细节粒度，以防万一有所不同。

根据 MSDN (http://msdn.microsoft.com/en-us/library/windowsazure/dd894038.aspx)，

• 事务最多可以包含 100 个实体，其总有效负载大小可能不超过 4 MB。

问题）在发送 group-transaction 请求之前，我们如何测量负载大小以保证大小不超过 4MB？

提前致谢！

从文档中我不清楚哪个祖先是事务的边界。最接近的，还是根的？

我有一个根实体（A），它有几个后代（B1，B2 ... Bn），这些后代可以有很多祖先（C1，C2...）。我将在 C 实体 (Cs) 上进行交易，我将使用基于 B 实体的祖先查询来获得这些交易。问题是，ConcurrentModificationException如果另一笔交易同时改变了 B2 下的一些 C，B1 下 C 的变化会抛出 a 吗？

所有的 C 都属于其祖父 A 下的同一个实体组，还是实体组也划分为更小的“子实体组”，即 B 下的每组 C 都有自己的实体组？

我们有成千上万的用户，每个用户都有 1000 条记录。在我们的应用程序中，用户和记录都由模型表示。

每个用户单独保存 1000 条记录需要很长时间（30 多秒）。但是，考虑到所有这些记录都属于同一个用户，可以一次保存吗？

据我了解，使用实体组，它可以在一个事务中完成，但找不到任何关于如何执行此操作的明确文档。

有什么建议么？

我正在从 Dataflow 写入数据存储区，pcollection 具有要写入数据存储区的同一实体组的多个实体。由于相同的实体写入/更新限制，将它们写入数据存储会很慢吗？我可以以某种方式从数据流中进行交易吗？如果是，在单个事务中编写相同的实体组会更快吗？

我有一个问答评论应用程序（类似于 stackoverflow）。这些问题及其相关答案和评论在逻辑上构成了App Engine 文档中定义的实体组的一部分。

我想使用实体组/祖先路径将我的实体组合在一起，原因有两个：

1. 通过将问题和答案实体物理存储在一起来提高查询效率
2. 允许我执行祖先查询，从而无需我将答案键存储在问题实体（关系）上

我不想要强一致性，因为它最终会引起争用。

App Engine 是否总是在更新时锁定实体组，还是仅在事务中完成更新时锁定？换句话说，实体组是强制更新在事务中发生还是只是提供使用事务的选项？