为什么指定分区键时Azure Cosmos查询具有更高的RU？

Question

我有一个与此类似的问题。基本上，我一直在测试使用分区键的不同方法，并且注意到在任何时候，查询中引用的分区键越多，RU就越高。这是非常一致的，甚至不知道如何使用分区键。因此，我将其缩小到用于测试的基本查询。

首先，这个数据库有大约85万个文档，大小都超过1KB。分区键基本上是数字形式的id的100模数，设置为/partitionKey，容器使用默认的索引策略:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/\"_etag\"/?"
        }
    ]
}

这是我的基本查询测试：

SELECT c.id, c.partitionKey
FROM c
WHERE c.partitionKey = 99 AND c.id = '99999'
-- Yields One Document; Actual Request Charge: 2.95 RUs

SELECT c.id, c.partitionKey
FROM c
WHERE c.id = '99999'
-- Yields One Document; Actual Request Charge: 2.85 RUs

Azure Cosmos留档表示如果没有分区键，查询将“散开”到所有逻辑分区。因此，我完全期望第一个查询针对单个分区，第二个查询针对所有分区，这意味着第一个查询应该具有较低的RU。我想我正在使用RU结果作为Cosmos是否散开并扫描每个分区的证据，并将其与留档所说的应该发生的情况进行比较。

我知道这些结果只有0.1个罗斯的差异。但是我的观点是，查询越复杂，差别就越大。例如，下面是另一个稍微复杂一点的查询:

SELECT c.id, c.partitionKey
FROM c
WHERE (c.partitionKey = 98 OR c.partitionKey = 99) AND c.id = '99999'
-- Yields One Document; Actual Request Charge: 3.05 RUs

请注意，RUs继续增长，并与完全没有指定分区键的情况相分离。相反，我希望上面的查询只针对两个分区，相比之下，没有分区键检查应该会分散到所有分区。

我开始怀疑分区密钥检查发生在其他过滤器之后（或每个分区扫描内部）。例如，返回第一个查询，但将id更改为不存在的内容：

SELECT c.id, c.partitionKey
FROM c
WHERE c.partitionKey = 99 AND c.id = '99999x'
-- Yields Zero Documents; Actual Request Charge: 2.79 RUs

SELECT c.id, c.partitionKey
FROM c
WHERE c.id = '99999x'
-- Yields Zero Documents; Actual Request Charge: 2.79 RUs

请注意，RU完全相同，并且两者（包括带有分区过滤器的RU）的RU比文档存在时少。这似乎是分区过滤器对结果执行的症状，而不是限制扇出。但这不是文件所说的。

为什么在指定分区键时 Cosmos 具有更高的 RU？

Answer 1

就像注释指定的那样，如果您通过门户（或通过代码，但使用您提供的查询）进行测试，则会变得更昂贵，因为您不是查询特定分区，而是查询所有内容，然后引入另一个过滤器，这会更昂贵。

相反，您应该做的是 - 在代码中使用正确的方式传入分区键。我的结果非常令人印象深刻：PK为3 ru，没有PK的参数为20.000 ru，因此我对intworks非常有信心（我有一个非常大的数据集）