时间戳

首页 > 解决方案 > 为什么 Azure Cosmos 查询在指定分区键时具有更高的 RU？

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

问题描述

我有一个与此类似的问题。基本上，我一直在测试使用分区键的不同方法，并且注意到在任何时候，查询中引用的分区键越多，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 文档说，如果没有分区键，查询将“扇出”到所有逻辑分区。因此，我完全希望第一个查询针对单个分区，第二个查询针对所有分区，这意味着第一个查询应该具有较低的 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？

标签： azureazure-cosmosdbazure-cosmosdb-sqlapi

解决方案

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

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

推荐阅读