12

我读过很多关于比较 SQL Azure 和 Table Service 的帖子和文章，其中大多数都说 Table Service 比 SQL Azure 更具可扩展性。

对不起 http，我是新用户 >_< 但是http://azurescope.cloudapp.net/BenchmarkTestCases/基准测试显示不同的图片。

我的情况。使用 SQL Azure：一张表有很多插入，每天大约 172,000,000 次（每秒 2000 次）。当我在一个表中有 200 万条记录或 9999....90 亿条记录时，我能否期望插入和选择具有良好的性能？

使用表服务：一张带有一定数量分区的表。分区的数量可以很大，非常大。

问题 #1：表服务在一张表中创建许多、许多、许多分区是否有一些限制或最佳实践？

问题 #2：在单个分区中，我有大量的小实体，例如上面的 SQL Azure 示例。当我在一个分区中有 200 万条记录或 99990 亿个实体时，我能否期望插入和选择具有良好的性能？

我知道分片或分区解决方案，但它是一种云服务，云不是很强大，并且没有我的代码技能就可以完成所有工作吗？

问题 #3：谁能告诉我查询 SQL Azure 和表服务的大量数据的基准？

问题#4：也许你可以为我的案例提出一个更好的解决方案。

4

2 回答 2

6

简答

  1. 我还没有看到很多分区导致 Azure 表 (AZT) 问题，但我没有这么多数据。
  2. 分区中的项目越多，该分区中的查询越慢
  3. 抱歉，没有，我没有基准
  4. 见下文

长答案

在您的情况下，我怀疑 SQL Azure 不适合您，仅仅是因为 SQL Azure 数据库大小的限制。如果您插入的每一行都是 1K 的索引，那么您将在大约 300 天内达到 50GB 的限制。微软确实在谈论大于 50GB 的数据库，但他们没有给出任何时间框架。SQL Azure 也有一个我目前无法找到的吞吐量限制（我很确定它比你需要的要少）。您可以通过在多个 SQL Azure 数据库中对数据进行分区来解决此问题。

SQL Azure 确实具有的优势是能够运行聚合查询。在 AZT 中，您甚至无法在select count(*) from customer不加载每个客户的情况下编写 a。

AZT 也有每个分区每秒 500 个事务的限制，以及每个帐户每秒“数千”个事务的限制。

我发现选择用于分区键 (PK) 和行键的内容取决于 (RK) 您将如何查询数据。如果您想单独访问这些项目中的每一项，只需为每一行赋予它自己的分区键和一个常量行键。这意味着你有很多分区。

例如，如果您插入的这些行是订单并且订单属于客户。如果您更常见的是按客户列出订单，那么您将拥有 PK = CustomerId，RK = OrderId。这意味着您只需在分区键上查询即可为客户查找订单。要获得特定订单，您需要知道 CustomerId 和 OrderId。客户的订单越多，找到任何特定订单的速度就越慢。

如果您只需要通过 OrderId 访问订单，那么您将使用 PK = OrderId, RK = string.Empty 并将 CustomerId 放在另一个属性中。虽然您仍然可以编写一个为客户返回所有订单的查询，因为如果您的查询不使用 PartitionKey，AZT 不支持 PartitionKey 和 RowKey 以外的索引（有时即使它确实取决于您的编写方式他们）将导致表扫描。就你所说的记录数量而言，这将是非常糟糕的。

在我遇到的所有场景中，拥有大量分区似乎并不会让 AZT 太担心。

另一种在 AZT 中不常提及的分区数据的方法是将数据放在不同的表中。例如，您可能希望每天创建一个表。如果要运行上周的查询，请对 7 个不同的表运行相同的查询。如果您准备在客户端做一些工作，您甚至可以并行运行它们。

于 2010-10-06T19:58:25.097 回答
0

Azure SQL 可以轻松地摄取更多数据。这是我几个月前录制的一段视频，其中展示了一个示例（可在 GitHub 上获得），展示了您可以做到这一点的一种方法。

https://www.youtube.com/watch?v=vVrqa0H_rQA

这是完整的回购

https://github.com/Azure-Samples/streaming-at-scale/tree/master/eventhubs-streamanalytics-azuresql

于 2020-09-27T17:01:40.930 回答