Azure 表存储上大量数据对性能的影响答案

【问题标题】：Performance impact with huge data on Azure Table StorageAzure 表存储上大量数据对性能的影响
【发布时间】：2018-02-23 05:18:01
【问题描述】：

我的查询

我们是否应该预计在指定时间段内从不同 Partitions 中的存储中检索数据会很慢 - 比如 1 小时 - 如果预计 Table Storage`表存储中的分区`中的数据会非常非常非常庞大（比如说以百万计）？

关于我的应用

我的网络应用处理从不同设备接收不同信号的数据。
从设备接收数据的频率可以是 1 分钟。
这样收到的数据将发布到Table Storage，并在收到时显示在仪表板上。
还可以查询特定signal(s)在选定时间段内的数据以显示在页面上。

我的问题

目前该应用正在测试中，只有在进行测试时才会提供数据。由于数据量较少，从 Table Storage 查询和获取数据需要大约 30 秒才能获取大约 10,000 行。

我一直在这里阅读不同的帖子，例如Very Slow on Azure Table Storage Query on PartitionKey/RowKey List 这表示从Table Storage 获取数据存在一些延迟。

所以我的查询是

当Partition 中的Table Storage \ 中有数百万数据时，对Table Storage 的查询是否会进行完整的表扫描，从而导致严重的性能问题？
1. 检索数据以显示在我的页面上的预期查询之一是
(((((((((((((PartitionKey eq 'D4AS1') or (PartitionKey eq 'D4AS2')) or (PartitionKey eq 'D4AS3')) or (PartitionKey eq 'D4AS4')) or (PartitionKey eq 'D4AS5')) or (PartitionKey eq 'D4AS6')) or (PartitionKey eq 'D4AS7')) or (PartitionKey eq 'D4AS8')) or (PartitionKey eq 'D4AS9')) or (PartitionKey eq 'D4AS10')) or (PartitionKey eq 'D4AS11')) or (PartitionKey eq 'D4AS133')) and (TimeReceived ge datetime'2018-02-21T23:53:40.4622407Z')) and (TimeReceived le datetime'2018-02-22T23:53:40.4622407Z') 是否应该重新构建上述查询以获得更好的性能？如果是，请建议需要以什么方式解决？
1. 查询时我们可以预期的最大延迟是多少（简单\复杂如上）Table Storage？

【问题讨论】：

我的假设是查询错误并导致扫描。您是否尝试过手动将其拆分为并发查询？
TimeReceived 是行键吗？如果没有，您正在执行完整的分区扫描。并且由于您指定了多个分区键，如果 TimeReceived 只是一个附加属性，那么您正在执行多个分区扫描。
@CoryNelson 谢谢。我没有收到splitting it up into concurrent queries。上述查询是动态形成的 - 就像从分区键的输入 List<string> 一样，方法框架查询相应地使用 Or\And Condition。请详细说明您的建议。
@DavidMakogon TimeReceived' is not the row key. Will changing the query to Timestamp` Table Storage 的属性，而不是当前的 TimeReceived 帮助？或者我们还有其他方法可以提高性能吗？请提出建议。
Timestamp 不是行键。您需要将 TimeReceived 属性存储在行键中，然后重试。但是......我无法帮助您设计您的表格，尤其是在不知道您将执行的所有类型的查询的情况下。您可以做的最好的事情是查看Table Storage Design Guide，以更好地了解表和相关查询的工作原理。

标签： c# azure azure-table-storage

【解决方案1】：

当一个表存储中有数百万条数据时\ 分区将查询表存储进行完整的表扫描导致严重的性能问题？

如果您的查询包含PartitionKey，则不会进行表扫描。但是它会进行分区扫描（除非您使用 PartitionKey 和 RowKey 发出了点查询）。

检索数据以显示在我的页面上的预期查询之一是 (((((((((((((PartitionKey eq 'D4AS1')或(PartitionKey eq 'D4AS2'))))或 (PartitionKey eq 'D4AS3')) 或 (PartitionKey eq 'D4AS4')) 或 (PartitionKey eq 'D4AS5')) 或 (PartitionKey eq 'D4AS6')) 或 (PartitionKey eq 'D4AS7')) 或 (PartitionKey eq 'D4AS8')) 或 (PartitionKey eq 'D4AS9')) 或 (PartitionKey eq 'D4AS10')) 或 (PartitionKey eq 'D4AS11')) 或 (PartitionKey eq 'D4AS133')) 和 (TimeReceived ge datetime'2018-02-21T23:53:40.4622407Z')) 和 (TimeReceived le datetime'2018-02-22T23:53:40.4622407Z') 上述查询是否被重新构建以获得更好的性能？如果是这样请建议需要以什么方式解决？

正如史蒂夫在您链接的答案中所提到的，这个查询并没有真正优化。您应该创建多个查询并并行触发它们。所有查询的结果返回后，您应该在客户端将它们组合起来并呈现给您的用户。

查询的最大延迟是多少（简单\复杂为上面）表存储？

从此link，分配给执行查询的最长时间是 5 秒，分配给查询的最长时间是 30 秒。从这个链接：

针对表服务的查询最多可能返回 1,000 个项目一次，最多可以执行五秒钟。如果结果集包含超过 1,000 个项目，如果查询没有在五秒内完成，或者如果查询跨分区边界，响应包括为开发人员提供的标头使用延续标记来恢复查询结果集中的下一项。继续令牌标头可能是为查询表操作或查询实体操作返回。

请注意，分配给调度请求的总时间和处理查询是 30 秒，包括 5 秒查询执行。

【讨论】：