我有一个16GB的集合,有2个分区 . 当我通过它的Id查询文档时,它非常慢 . 但是通过索引字段进行查询的速度很快 . 两者都是跨分区查询,如果我使用查询传递分区键,它很快但分区键并不总是可用于我的查询 . 在Azure门户中使用.NET SDK和文档资源管理器查询得到了类似的结果 .
该集合具有自定义索引策略,但据我所知,您不需要索引 Id
或者甚至可能不可能 .
以下是我的查询及其相应的请求费用 .
SELECT * FROM c where c.id = 'unique-id-123'
-- Request Charge: 344940.79 RUs, Document Count: 1
SELECT * FROM c WHERE c.otherId = 'NOT-so-uniqueId-123'
-- Request Charge: 5.08 RUs, Document Count: 3
如您所知,Id是唯一的,因此查询返回1个文档,而第二个查询由_1786630过滤,这不是那么唯一并返回3个文档 . 还要注意第一个查询的RU消耗量非常高 .
那么为什么第二个查询比Id要快?
Update:
以下是上述查询的已收集指标 .
按ID查询:
Read 1 records in 1497 ms, 339173.109 RU, Size: 6873022 KB
QueryPreparationTime(ms): CompileTime = 2, LogicalBuildTime = 0,
PhysicalPlanBuildTime = 0, OptimizationTime = 0
QueryEngineTime(ms): DocumentLoadTime = 1126, IndexLookupTime = 0,
RuntimeExecutionTimes = 356, WriteOutputTime = 0
按索引字段查询:
Read 4 records in 2 ms, 7.56 RU, Size: 9 KB
QueryPreparationTime(ms): CompileTime = 0, LogicalBuildTime = 0,
PhysicalPlanBuildTime = 0, OptimizationTime = 0
QueryEngineTime(ms): DocumentLoadTime = 0, IndexLookupTime = 1,
RuntimeExecutionTimes = 0, WriteOutputTime = 0
这些证明Id的查询正在进行表扫描,因为大部分时间都来自 DocumentLoadTime
而 IndexLookupTime
没有值 .
但我认为Id应该是主键,默认情况下会根据@ andrew-liu的answer索引 .
2 回答
微软的支持得到了回复,他们为该集合添加了
IndexVersion
2 . 不幸的是,门户网站尚未提供它,新创建的帐户/集合仍未使用新版本 . 您必须与Microsoft支持部门联系以更改您的帐户 .以下是索引版本2的集合的新结果,并且有了很大的改进 .
“Id”字段仅在分区键中是唯一的 . 如果您手动配置索引,这可能是您的查询成本如此昂贵的一方 .
不幸的是,无法控制'id'字段的索引 . 如果索引所有内容,您可以尝试检查查询性能是否会提高 . 如果它改变了你的数据,那将会很有趣,尽管它对我的小样本集没有任何改变 .
根据我的经验,如果在每个分区中有几个结果,DocumentDB查询实际上可以变得更便宜 . 如果在分区内有 no 结果,它们可能会非常昂贵 . 尝试将具有相同ID的第二个文档放在不同的分区中,并查看性能如何变化 . 在没有跨分区查询的情况下,无论结果计数如何,使用索引字段查询时响应总是非常快 .
我从来没有调查过更多,因为它从来没有打扰我的真实用例 . 也许每个分区的项目数量没有实际影响,我的数据本身也是负责任的 .