Azure Cosmos Document DB 中的自定义索引不起作用

Question

好的，所以 CosmosDb 集合将其索引策略设置为一致、自动、具有默认哈希和范围索引并且我们添加了一个指向我们自己的时间戳属性的路径，以便按它们进行排序。

我知道路径是正确的，因为除非我设置它们，否则我无法按它们订购。但是：

当按 Cosmos 内置属性 _ts 排序时 - OrderBy 查询的成本约为 20 RU/s。那太棒了。 现在，当按我们的 OWN 时间戳列进行排序时（我们有两个，其中一个是字符串时间戳，另一个是基于 Unix 的数字，就像内置的 _ts列。 此查询花费 400 RU/s !???

设置新的索引规则使我们能够对其进行查询和排序，但是 RUs 太疯狂了。为什么会这样，我们如何解决它？

我知道您之前无法更改 Ad Hoc 索引策略，但 Microsoft 已解决此问题。

编辑：这是一个简单的集合，没有配置分区，查询只针对这个集合运行，只选择一个文档（前 1 个）。

SELECT top 1 * FROM c WHERE c.AllCompleted = true ORDER BY c.EndFetchDateTimeUtcUnix DESC 对比

SELECT top 1 * FROM c WHERE c.AllCompleted = true ORDER BY c._ts DESC

索引如下所示： { "indexingMode": "consistent", "automatic": true, "includedPaths": [ { "path": "/", "indexes": [ { "kind": "Hash", "dataType": "Number", "precision": 3 }, { "kind": "Hash", "dataType": "String", "precision": 3 } ] }, { "path": "/EndFetchDateTimeUtcUnix/?", "indexes": [ { "kind": "Range", "dataType": "Number", "precision": -1 }, { "kind": "Hash", "dataType": "String", "precision": 3 } ] } ], "excludedPaths": [] }

Answer 1

这可能是您遇到索引冲突的情况（多个值映射到同一个索引项）。

为了最大程度地减少冲突的可能性，并且如果 order-by 项具有已知的最小/最大值，您可以在 order-by 项上添加一个过滤器以缩小检索到的索引词的范围。

例如，

选择 * 从 c WHWE c.DateTime BETWEEN '2000-01-01T00:00:00.0000000Z' AND '3000-01-01T00:00:00.0000000Z' 按 c.DateTime 排序

同样，您可以将相同的技术应用于数字时间戳。

Answer 2

我建议您调查一下 DocumentDB 的工作量。转到Query execution metrics 标题以获取线索。