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

Question

我有一个类似于this one 的问题。基本上，我一直在测试使用分区键的不同方法，并注意到在任何时候，查询中引用的分区键越多，RU 就越高。它非常一致，甚至不关心如何使用分区键。所以我把它缩小到测试的基本查询。

首先，这个数据库有大约 850K 文档，大小都超过 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 文档说没有分区键，查询将“fan out”到所有逻辑分区。因此，我完全希望第一个查询针对单个分区，第二个查询针对所有分区，这意味着第一个查询应该具有较低的 RU。我想我正在使用 RU 结果作为 Cosmos 是否正在扇出并扫描每个分区的证据，并将其与文档中所说的应该发生的情况进行比较。

我知道这些结果仅相差 0.1 RU。但我的观点是查询越复杂，差异就越大。例如，下面是另一个稍微复杂一点的查询：

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

请注意，RU 会继续增长，并且根本没有指定分区键。相反，我希望上述查询仅针对两个分区，而没有分区键检查据称会散播到所有分区。

我开始怀疑分区键检查发生在 其他过滤器之后（或在每个分区扫描内）。例如，返回第一个查询但将 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

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

您应该做的 - 是在代码中使用正确的方式来传递分区键。我的结果非常令人印象深刻：3 ru\s 有 PK 和 20.000 ru\s 没有 PK，所以我很有信心 intworks（我有一个非常大的数据集）