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

Question

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

例如,我可能有一个系统跟踪他们拥有的用户和书籍.我在SO上找到了另一个帖子,建议在用户上有一个String属性,它基本上存储了用户拥有的Book ID列表.虽然我知道有时这是一种可接受的存储数据的方法,但问题是Azure只允许您在String中存储64KB的数据.这绝对限制了用户可能拥有的书籍数量.

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

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

除了这个问题,在使用Azure表存储时,有没有人对其他模式和实践有任何好的建议？

Answer 1

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

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

   然后,要查找用户的所有书籍,您需要在映射表中选择Book键,然后为每个键选择Books表中的Book实体.您可以使用异步提取并行执行Book检索,但即便如此,此解决方案显然无法扩展.

2. 使用上面的映射表,但也包括映射表中所需的所有Book数据.这是您已经使用OwnedBooks表提出的非规范化或"重复数据"解决方案.

   这种方法的主要缺点是,如果您需要更新任何Book数据,您可能会更新许多实体 - 并且当它们位于Book本身的单独表中时,它将无法在单个事务/批处理(我想你无论如何都会使用用户身份作为映射表中的分区键,这已经排除了该表中的单个批量更新).

3. 将Book键存储在User的单个属性中.再次,您已经建议了这种方法.

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

4. 使用Azure表存储的"无模式"特性将关联的Book键存储为单个属性.例如,一个用户实体可能如下所示:

   { Name: "User1", Book_4325: true, Book_5123: true }

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

   { Name: "User2", Book_5346: true, Book_8753: true, Book_6135: true }

   然后,如果您确实想要找到拥有特定书籍的所有用户,您可以选择该特定属性的真实位置(嗯,它只需要真正存在).

   显而易见的缺点是它有点脆,你需要在属性名称中使用键,并且你无法使用StorageClient的标准方法 - 你必须自己动手.此外,Azure仅支持实体上的255个属性.所有这一切,我认为它会扩展得很好 - 虽然我从未尝试过.

在所有这些选项中,我会说你要使用的选项,选项2,将是最好的,只是因为它目前支持Azure,你通常可以用更少的查询实现一切.

考虑到原子事务不在窗口,您只需要仔细检查用例以决定数据的更新方式和时间.我几乎可以保证你能够忍受"最终一致"的事情,并且只考虑到你的映射表可能并不总是100%最新的事实.

如果在主表的同时更新映射表中的数据变得太昂贵,则可以在队列上放置消息并获取辅助角色以异步方式为您执行更新.

Answer 2

你没有.这是Azure Table上的一篇很好的,完整的白皮书(.docx链接),其中有一节介绍最佳实践.但是,您应该将Table用于非关系属性包或ORM类型设计.如果您想在云中使用关系,则应使用SQL Azure数据库.

这是关于无架构存储与关系的另一篇好文章.它适用于不同的架构免费云存储产品,但概念是相同的.