design-patterns - 如何正确存储与 Microsoft Azure 表存储的数据关系？

Question

来自关系世界的事情显然与 Azure 表存储有很大不同。我遇到的第一个主要问题是如何正确存储多对多关系。

例如，我可能有一个系统来跟踪他们拥有的用户和书籍。我在 SO 上发现了另一篇文章，建议在用户上有一个字符串属性，该属性基本上存储用户拥有的图书 ID 列表。虽然我知道有时这是一种可接受的数据存储方式，但问题是 Azure 只允许您在字符串中存储 64KB 的数据。这肯定限制了用户可能拥有的图书数量。

另一种可能的解决方案是拥有重复的数据。我可能有一个表来存储系统中所有已知的书籍。但是，当用户需要与图书关联时，我将图书数据复制到名为 OwnedBooks 的不同表中，该表本质上与图书表完全相同，只是它也具有 OwnedByUserID 属性。

还有其他可能的解决方案吗？

除了这个问题之外，在使用 Azure 表存储时，是否有人对其他模式和实践有什么好的建议？

Answer 1

对此有很多解决方案 - 当然都有缺点:-)

1. 像在 RDBMS 中一样使用简单的映射表。每行将包含一个 Book key 和一个 User key 。

   然后，要查找用户的所有书籍，您需要在映射表中选择“书籍”键，然后对于每个键，从“书籍”表中选择“书籍”实体。您可以使用异步获取并行执行图书检索，但即便如此，该解决方案显然无法扩展。

2. 使用上面的映射表，但也将您需要的所有图书数据包含在映射表中。这是您已经针对 OwnedBooks 表提出的非规范化或“重复数据”解决方案。

   此方法的主要缺点是，如果您需要更新任何图书数据，您将可能更新许多实体 - 并且由于它们位于与图书本身不同的表中，因此它无法在单个事务/批处理中完成(而且我想您无论如何都会使用用户身份作为映射表中的分区键，这已经排除了该表中的单个批量更新)。

3. 将书籍 key 存储在用户的单个属性中。同样，您已经建议了此方法。

   如果不是因为 Azure 目前不支持“包含”类型查询，这实际上不会那么糟糕 - 即，您无法搜索子字符串，所以如果您想查找如果哪个用户拥有一本特定的书籍，这是不可能的。有趣的是，Google App Engine 在其存储系统中相当透明地支持这一点 - 并且也会为您索引该列表。无论如何，您仍然需要使用此方法检索每本书的数据。

4. 使用 Azure 表存储的“无架构”性质将关联的 Book key 存储为单独的属性。例如，一个 User 实体可能如下所示:

   { 名称:“用户1”， Book_4325:正确， Book_5123:正确 }

   而另一个可能看起来像这样:

   { 名称:“用户2”， Book_5346:正确， Book_8753:正确， Book_6135:正确 }

   然后，如果您确实想要查找拥有特定书籍的所有用户，您可以选择该特定属性为 true 的位置(好吧，它只需要确实存在即可)。

   这样做的明显缺点是它有点脆弱，您需要摆弄属性名称中的键，并且您将无法为此使用 StorageClient 的标准方法 - 您必须推出自己的方法。此外，Azure 仅支持实体上的 255 个属性。话虽如此，我认为它可以很好地扩展 - 尽管我从未尝试过。

在所有这些选项中，我想说您要选择的选项 2 是最好的，因为它目前受 Azure 支持，并且您通常可以通过更少的查询来实现所有目标。

您只需要仔细检查您的用例来决定如何以及何时更新数据，考虑到原子事务已经排除在外了。我几乎可以保证您能够接受“最终一致”的情况，并且只需考虑您的映射表可能并不总是 100% 最新的事实。

如果与主表同时更新映射表中的数据成本太高，您可以将消息放入队列并让辅助角色为您异步执行更新。