Question

在查询Azure表存储数据时，我们发现了一些非常可变的延迟。我们有许多项目，每个时间序列数据按天分类如下：

分区键：{DATA_TYPE} _ {YYYMMdd} - 4种不同的数据类型，共有大约2年的数据

行键：{DataObjectId} - 每天大约3-4,000条记录。

记录本身是一个JSON编码的dateTime对象数组，每隔15分钟展开一次。

所以我想在过去几天检索特定对象的时间序列数据，因此我构建了以下查询：

string.Format("(PartitionKey ge '{0}') and (PartitionKey le '{1}') and     (RowKey eq '{2}')", lowDate, highDate, DataObjectId);

如上所述，我们有超过2 - 3年的记录。

总的来说，查询时间相当快600-800毫秒然而，一次或两次我们得到了几个值，似乎需要很长时间才能从这些分区中检索数据。即一个或两个查询需要50秒才能返回数据。

我们不知道系统负载很大。事实上，令人沮丧的是，我们发现门户网站中的所有图表都没有真正的问题。

想到一些建议：

1.) add year component first making the partition keys immediately more selective.

然而，最令人沮丧的是执行查询所花费的时间变化。

Azure门户中的Azure存储延迟平均为大约117.2毫秒，报告的最大值为294毫秒。我将此解释为网络延迟。

当然感激不尽的建议。最令人烦恼的是执行时间变化很大。在极少数情况下，我们看到我们的应用程序使用延续令牌，因为查询需要5秒钟才能完成。

Answer 1

已经看了一会儿。

我还没有找到答案为什么查询跨越分区遭受如此可变的延迟。我原以为它可以很好地处理索引。

然而，解决方案似乎只是简单地从6个不同的分区请求数据。因此，所有查询都利用了Partitionkey和rowkey索引。一旦实现这一点，我们的查询就会更快地返回。

仍然想了解为什么查询分区看起来如此缓慢，但我只能假设查询导致表扫描具有可变延迟。