2

Is it a correct approach to store needed Azure Storage Table relations in Azure SQL database? For example, I may have a system that keeps track of Users and Books that they own. I would keep Users entities and Books entities in Azure Storage Table and the relations (idUser, idBook) in supporting Azure SQL table.

Is it a good approach? What will be the drawbacks of this solution?

EDIT: The motivation to do it is simply to lower cost. I'll need to store a lot of data, so I plan to use Azure Storage Tables, becuase SQL database will be simply to expensive. But in some scenarios I'll need to store relations between objects.

4

3 回答 3

4

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

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

于 2013-08-23T00:00:04.713 回答
3

我想在@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 次阅读交易。但是，如果您将书籍信息存储在辅助表本身中，那么您

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

于 2013-08-23T14:58:46.120 回答
1

优点

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

缺点

  • 作为@Ic。陈述；您没有简单的方法来维护参照完整性
  • 由于必须将关系从 SQL Azure 拉入内存，导致性能下降；然后枚举它们以获得正确的表存储条目
  • 表存储本身比 SQL Azure 慢得多（参见这个问题）
  • 维护 SQL Azure 数据库仍然需要成本；即使是很小的

我听说过用户也使用 Azure 表存储来存储关系；例如：

  • 表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 所带来的性能下降（而且这将是一个严重的下降）是否值得节省成本。

于 2013-08-23T10:36:30.513 回答