通过id检索文档在cosmos db中的分区之间很慢

Pet*_*ter 5 azure azure-cosmosdb

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

从我的理解写出一个简单的查询

SELECT * from c WHERE c.id = "id here"
Run Code Online (Sandbox Code Playgroud)

应该是要走的路,但我遇到了这个查询的严重性能问题.大多数查询需要30到60秒才能完成,并且似乎消耗了大量的RU/s.执行10个并发查询时,每个分区的最大RU/s高达30.000.(每个分区配置10.00)导致限制甚至更慢的响应.

该集合包含10个分区,每个分区大约3 Mb,总共30 Mb和大约1,00,000个文档.我的索引策略如下所示:

{
    "indexingMode": "lazy",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*",
            "indexes": [
                {
                    "kind": "Range",
                    "dataType": "Number",
                    "precision": -1
                },
                {
                    "kind": "Hash",
                    "dataType": "String",
                    "precision": 3
                }
            ]
        }
    ],
    "excludedPaths": []
}
Run Code Online (Sandbox Code Playgroud)

并且设置了一致性,EVENTUAL因为我并不真正关心读/写顺序.该集合受到一些写入压力,每分钟大约30次写入,每个文档的TTL为1年,但这似乎不会对RU产生可测量的影响.我只在查询文档时遇到这种问题.

有没有人有类似的问题,可以提供修复/缓解?我的查询或索引策略有问题吗?我不知道为什么我的查询消耗了那么多资源.

Mar*_*dad 6

我甚至遇到了类似的问题.我的数据库是16 GB,有2个分区,每个分区有10,000 RU.

通过收集查询指标,我发现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
Run Code Online (Sandbox Code Playgroud)

注意主要用于DocumentLoadTime和的时间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
Run Code Online (Sandbox Code Playgroud)

与id的查询相比,这不会因使用DocumentLoadTime索引而消耗,IndexLookupTime为1 ms.

问题id应该是主键,默认情况下应该编入索引,但看起来不是.你甚至无法为它添加自定义索引策略.

我目前正在记录微软支持的门票并等待澄清.

更新:

微软支持得到了回复,他们已经解决了这个问题.他们已经IndexVersion 2为这个系列添加了.不幸的是,门户网站尚未提供它,新创建的帐户/集合仍未使用新版本.您必须与Microsoft支持部门联系以更改您的帐户.

以下是索引版本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
Run Code Online (Sandbox Code Playgroud)


Gre*_*olf 5

我的测试数据库大约有30万条记录当我尝试仅选择ID时,像这样

SELECT * FROM c where c.id = 'xxx'
Run Code Online (Sandbox Code Playgroud)

我花了很多时间和精力

但是当我尝试使用分区键

SELECT * FROM c where c.id = 'xxx' AND c.partitionField = 'yyy'
Run Code Online (Sandbox Code Playgroud)

很快

因此,我认为您必须重新构建数据库,并考虑要对哪个字段进行分区