在cosmos db中，通过id检索文档的速度很慢

Question

我有一个场景，我需要根据其id属性从azure cosmos db检索单个文档。唯一的问题是我不知道分区键，因此无法使用文档URI来访问它。

根据我的理解，编写一个简单的查询，如

SELECT * from c WHERE c.id = "id here"

这应该是一条路，但我遇到了这个查询的严重性能问题。大多数查询需要30到60秒才能完成，并且似乎消耗了大量的RU/s。当执行10个并发查询时，每个分区的最大RU/s高达30.000（每个分区配置10.00），导致节流和响应更慢。

该集合包括10个分区，每个分区大约有3 Mb，因此总共有30 Mb，大约有10万个文档。我的索引策略如下所示：

{
    "indexingMode": "lazy",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                },
                {
                    "kind": "Hash",
                    "dataType": "String",
                    "precision": 3
                }
            ]
        }
    ],
    "excludedPaths": []
}

一致性设置为< code > finally ，因为我并不关心读/写顺序。该集合有一定的写入压力，大约每分钟30次写入，每个文档的TTL为1年，但这似乎不会对RU/s产生可测量的影响。我只在查询文档时遇到这种问题。

有人遇到过类似的问题并且可以提供修复/缓解吗？我的查询或索引策略有问题吗？我不知道为什么我的查询会消耗这么多资源。

Answer 1

宇宙的关键是重新思考分区的关键。我不知道您正在使用什么，但请让它非常可用。

最近，我在我的所有文档中添加了一个“表”属性，但是您可以很容易地将表名用作分区键！这实际上几乎就像有一堆SQL表在CosmosDB集合的布丁中浮动。

Answer 2

我的测试DB关于300k记录当我尝试选择ID只有这样

SELECT * FROM c where c.id = 'xxx'

这花了我很多时间和RU

但是当我尝试使用分区键时

SELECT * FROM c where c.id = 'xxx' AND c.partitionField = 'yyy'

它非常快

所以我认为你必须重建你的数据库，并考虑用哪个字段来分区

Answer 3

我也有类似的问题。我的数据库是16 GB，有两个分区，每个分区有10，000 RU。

通过收集查询指标，我发现< code>query by id可能正在进行表扫描，而不是从索引中查找。

这是按id查询的指标：

SELECT * FROM c where c.id = 'id-here'
--Read 1 record in 1497.00 ms, 339173.109 RU
--QueryPreparationTime(ms): CompileTime = 2, LogicalBuildTime = 0, 
     PhysicalPlanBuildTime = 0, OptimizationTime = 0
--QueryEngineTime(ms): DocumentLoadTime = 1126, IndexLookupTime = 0, 
     RuntimeExecutionTimes = 356, WriteOutputTime = 0

请注意，时间主要花在文档加载时间和IndexLookupTime=0上。

而按索引字段的查询速度非常快。

SELECT * FROM c WHERE c.indexedField = 'value'
--Read 4 records in 2.00 ms, 7.56 RU
--QueryPreparationTime(ms): CompileTime = 0, LogicalBuildTime = 0, 
       PhysicalPlanBuildTime = 0, OptimizationTime = 0
--QueryEngineTime(ms): DocumentLoadTime = 0, IndexLookupTime = 1, 
       RuntimeExecutionTimes = 0, WriteOutputTime = 0

与按 id 查询相反，这不会消耗文档加载时间，因为使用了索引，索引查找时间为 1 毫秒。

问题是< code>id应该是主键，并且在默认情况下应该被索引，但看起来却不是。你甚至不能为它添加自定义索引策略。

我目前正在登录Microsoft支持并等待澄清。

更新:

微软支持部门做出了回应，他们已经解决了这个问题。他们为集合添加了索引版本 2。不幸的是，它尚未从门户中获得，并且新创建的帐户/集合仍未使用新版本。你必须联系微软支持部门才能对你的帐户进行更改。

以下是索引版本2的集合的新结果，它有了巨大的改进。

SELECT * FROM c where c.id = 'uniqueValue'
-- Index Version 1: Request Charge: 344,940.79 RUs
-- Index Version 2: Request Charge: 3.31 RUs

SELECT * FROM c WHERE c.indexedField = 'value' AND c.id = 'uniqueValue'
-- Index Version 1: Request Charge: 150,666.22 RUs 
-- Index Version 2: Request Charge: 5.65 RUs