azure - 为什么在 Cosmos SQL API 查询的 WHERE 子句中包含分区键会增加某些查询消耗的 RU？

Question

我想针对消耗的 RU 优化我的 Azure Cosmos DB SQL API 查询(部分是为了减少 429 响应的频率)。

具体来说，我认为在 WHERE 子句中包含分区键会减少消耗的 RU(例如，我读过 https://learn.microsoft.com/en-us/azure/cosmos-db/optimize-cost-queries 和 https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning-overview 这让我想到了这一点)。

但是，当我运行时

SELECT TOP 1 * 
FROM c
WHERE c.Field = "some value"
AND c.PartitionKeyField = "1234"
ORDER BY c.TimeStampField DESC

它消耗 6 个 RU。

而没有分区键，例如

SELECT TOP 1 * 
FROM c
WHERE c.Field = "some value"
ORDER BY c.TimeStampField DESC

它消耗 5.76 RU - 即更便宜。

(虽然上述数字根据所选的具体文档存在一些变化，但第二个查询总是更便宜，并且我已经针对最小和最大分区进行了测试。)

我的数据库目前有大约 400,000 个文档和 29 个分区(两者预计都会增长)。最大的分区包含大约 150,000 个文档(不可能比这个增长得更多)。

以上结果表明我不应该在该查询的 WHERE 子句中传递分区键。请有人解释一下为什么会这样，因为我认为相反的情况应该是正确的？

Answer 1

可能有几个原因，这取决于查询引擎决定使用哪个索引或者是否有索引。

我要说的第一件事是，这个容器中可能没有太多数据，因为容器越大，没有分区键的查询的成本就会逐渐增加，尤其是当它们跨越物理分区时。

如果分区键上没有索引并且在通过 c.field 过滤后对其进行扫描，第一个可能会更昂贵。

它也可能更昂贵，具体取决于是否存在复合索引以及是否使用它。

确实，您无法获取小型容器的查询指标并进行推断。测量的唯一方法是将足够的数据放入容器中。而且这里的数量太小了，不值得优化。我会将您希望在生产中使用的数据量放入此容器中，然后重新运行您的查询。

最后，关于测量和优化，帕累托原则适用。你会疯狂地追求每一个优化。找到您的高并发查询并专注于这些查询。

希望这对您有所帮助。