Azure存储表，其关系存储在Azure SQL中

Question

在Azure SQL数据库中存储所需的Azure存储表关系是否正确？例如，我可能有一个系统跟踪他们拥有的用户和书籍。我会在Azure存储表中保留用户实体和书籍实体，并在支持Azure SQL表格中保持关系（idUser，idBook）。

这是一个好方法吗？这个解决方案的缺点是什么？

修改： 这样做的动机只是降低成本。我需要存储大量数据，所以我打算使用Azure存储表，因为SQL数据库将简单到昂贵。但在某些情况下，我需要存储对象之间的关系。

Answer 1

我可能会遗漏一些东西，但坦率地说，我看不出有这么好的理由。

使用关系数据库的一个主要原因是存储关系数据，维护参照完整性，并依赖查询优化器来进行有效的连接。但是，由于您没有将相关用户或书籍数据存储在同一数据库中，因此无法在表中创建外键约束，也不能跨表连接数据，因为它不存在。事实上它更糟糕，因为首先你必须从SQL数据库中获取数据，然后你必须去表存储来获取其余的数据，所以你要连接到两个不同的服务只是为了检索一个列表数据

Answer 2

我想在@ Click-Rex的回答中添加一些内容：

1. 正如David所说，如果你不正确地查询表存储会很慢，即你的查询正在进行全表扫描。因此，如果您的分区设计得非常好，那么您应该获得比SQL Azure更好的性能。
2. 与SQL Azure相比，表存储非常便宜。
3. 确实认识到SQL Azure有点high density SQL server hosting，因此您可能会受到noisy neighbor行为的影响。表存储有点安全，因为隔离边界首先是您的存储帐户，然后是表，然后是PartitionKey。

@ Click-Rex提出的方法是我想要的方法，我想再做一件事：

在其他表中， duplicate the books and user information as well and not just BookId and UserId 。这样你只需要从一个表中读取而不是进行多次读取。这种方法的缺点是，您必须确保每当书籍信息或用户信息发生变化时，您都需要更新这些表格，但优点是您可以在阅读操作上节省很多。例如，假设您要查找用户拥有的书籍。如果您不将书籍信息存储在此辅助表格中，首先您将从此辅助表格中获取所有行键（书籍ID），然后对于每个书籍ID，您将从书籍表格中获取有关该书籍的信息。假设用户有500本书，则表示您正在执行500 + 1个读取事务。但是，如果您将书籍信息存储在辅助表本身中，那么您只需执行1次读取操作。

显然，如果 application is performing more reads than writes ，这种方法会有意义。您需要记住的另一件事是，您将无法获得事务支持，因为您将在许多表和分区中进行编写，因此您需要确保实体无论如何都会持久化。在我正在构建的应用程序中，我们正在遵循这种方法，我们实际上有一个工作者角色负责确保数据被持久化。

Answer 3

优点

• 在SQL Azure中获取关系比从表存储中获取关系更快

缺点

• 作为@Ic。说明;你没有简单的方法来维护参照完整性
• 由于必须从SQL Azure中将关系拉入内存而导致性能下降;然后通过它们枚举来获取正确的表存储条目
• 表存储本身比SQL Azure（参见this question）
慢得多
• 维护SQL Azure数据库仍然需要付出代价;即使它是一个小的

我听说有用户使用Azure Table Storage来存储关系;例如：

• 表1：用户（PartitionKey：UserID）
• 表2：图书（PartitionKey：BookID）
• 表3：UserBooks（ParititonKey：UserID，RowKey：BookID）
• 表4：BooksUsers（PartitionKey：BookID，RowKey：UserID）

UserBooks和BookUsers就像一个明确定义的索引;并允许您执行更快的搜索，因为PartitionKey和RowKey是您将用于关联的字段。

然而，明显的缺点是必须在数据旁边保留2个额外的表格。

真的可以归结为使用表存储而不是SQL Azure的性能下降（并且会严重下降）是否值得节省成本。