azure - 将点查询连接在一起时 Azure 表存储中的性能不可靠

Question

我一直遇到 Azure 表存储的性能问题。我正在查询一个保存用户帐户的表。该表将 userId 存储在 PartitionKey 和 RowKey 中，以便我可以轻松进行点查询。

我的问题是因为在某些情况下我需要在单个查询中检索多个用户。为了实现这一目标，我有一个为我构建过滤字符串的类。其工作方式与问题无关，但这是输出的示例:

(PartitionKey eq '00540de6-dd2b-469f-8730-e7800e06ccc0' and RowKey eq '00540de6-dd2b-469f-8730-e7800e06ccc0') or 
(PartitionKey eq '02aa11b7-974a-4ee9-9a8e-5fc09970bb99' and RowKey eq '02aa11b7-974a-4ee9-9a8e-5fc09970bb99') or 
(PartitionKey eq '040aec50-ebcd-4e5d-8f58-82aea616bd82' and RowKey eq '040aec50-ebcd-4e5d-8f58-82aea616bd82') or 
// up to 22 more (25 total)

首次执行查询时，执行时间较长(2-5 秒)，并且缺少数据，从而导致错误。第二次运行时，查询需要 0.2 到 0.5 秒才能完成，并且其中包含所有数据。

请注意，我也尝试过仅提供 PartitionKey，但没有什么区别。我原以为点查询会执行得更好。

从这个错误的演示中，我只能推测它是由首次请求时数据“冷”，然后在连续请求时从“热”缓存中提取数据引起的。

如果是这种情况，如何更改过滤字符串以提高性能？或者，如何更改表存储查询的超时以使其有更多时间完成？是否可以增加我的表存储的扩展？

Answer 1

请不要使用以“or”连接的点查询字符串，因为 Azure 存储表无法将其视为多点查询。相反，Azure Table会将其视为全表扫描，这在性能上很糟糕。您应该分别执行 25 个点查询以提高性能。