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

时间：2018-02-23 05:18:01

标签： c# azure azure-table-storage

我的查询

我们是否应该期望在指定的时间段内（例如1小时）从不同的OR cls.customer_id LIKE '%%'内的存储中检索数据的速度很慢 - 如果预期Partitions“表存储中的分区”中的数据是非常非常巨大（以百万计）？

关于我的应用

  1. 我的网络应用处理来自不同设备的不同信号的接收数据。

  2. 从设备接收的数据频率可以是1分钟。

  3. 这样收到的数据将发布到Table Storage，并在仪表板上显示时显示。

  4. 还可以查询在选定时间段内与特定Table Storage相关的数据，以便在页面上显示。

    5. 我的问题

    目前，该应用正在进行测试，只有在测试发生时数据才会进入。使用此数据量较少的数据，从signal(s)查询和获取数据需要大约30秒才能获取~10,000行。

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

    所以我的查询是

    1. 当Table Storage内的Table Storage \中有数百万的数据时，对Partition的查询是否会导致完整的表扫描导致严重的性能问题？

      1. 检索要在我的网页上显示的数据的其中一个预期查询是

        2. 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 个答案:

答案 0 :(得分：1)

  

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

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

  

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

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

  

我们在查询时可以预期的最大延迟（简单\复数为   上面的表存储？

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

  

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

     

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

相关问题
最新问题