Azure 表存储密钥延迟变化很大答案

【问题标题】：Azure Table Storage key latency very variableAzure 表存储密钥延迟变化很大
【发布时间】：2023-03-14 21:50:01
【问题描述】：

在查询 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 秒以上才能完成。

【问题讨论】：

【解决方案1】：

关注这个有一段时间了。

对于跨分区查询为何会遭受如此多变的延迟，我没有找到答案。我曾假设它可以很好地与索引一起使用。

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

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

【讨论】：

Would still like to understand why querying accross partitions seemed so slow 显然，如果您按顺序查询 n 个不同的服务器以获取数据，它比并行查询所有服务器要慢。
嗯！我想我最大的挫折是延迟的巨大变化，从完全可以接受到完全令人震惊。我现在的解决方案似乎很浪费，因为我需要提交 6 个请求，这会花费更多。
在下面，它也在执行 6 个请求，但不是并行的。