C# Azure表存储密钥延迟非常可变

在查询Azure表存储数据时，我们看到一些非常可变的延迟。我们有许多项，每个项都获取时间序列数据，这些数据按天细分如下：

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

行键：{DataObjectId}-每天大约3-4000条记录

记录本身是一个JSON编码的dateTime对象数组，每15分钟排列一次

因此，我想检索过去几天特定对象的timeseries数据，因此构建了以下查询：

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

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

总的来说，查询时间是相当快的600-800毫秒，但是有一两次我们得到了几个值，从这些分区检索数据似乎需要很长的时间。i、 e.一次或两次查询需要50秒以上的时间才能返回数据

我们不知道该系统正处于巨大的负荷之下。事实上，令人沮丧的是，我们在门户网站中找到的所有图表都表明没有真正的问题

我想到了一些建议：

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

然而，最令人沮丧的是查询时间的变化

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

当然，任何建议都会受到感激。最令人烦恼的是，执行时间如此多变。在极少数情况下，我们看到我们的应用程序求助于使用延续令牌，因为查询已经花费了超过5秒的时间来完成

---

我们已经研究了一段时间了

我还没有找到一个答案来解释为什么查询accross分区会遭受如此可变的延迟。我假设它可以很好地处理索引

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

---

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

仍然想理解为什么跨分区查询看起来如此缓慢

显然，如果您按顺序查询n个不同的服务器的数据，则比并行查询所有服务器都要慢。嗯！我想我最大的挫折是延迟的巨大变化，从完全可以接受到完全令人震惊。我现在的解决方案看起来很浪费，因为我需要提交6个请求，这会花费更多。在下面，它也做了6个请求，但不是并行的。