首页 文章

在cosmosdb中查询子文档的成本是多少?

提问于
浏览
1

在cosmosdb中查询子文档的成本是多少?在阅读文档时,似乎只有ID及其路径被编入索引 .

这是否意味着每次使用 From 这样的querying on a subdocuments时:

SELECT * 
FROM Families.children

它将解析匹配此路径的文档并创建它们的视图?子文件也存储好了吗?

1 回答

  • 0

    索引的工作原理

    CosmosDB将整个JSON文档存储为树(任何深度,包括我猜你称之为"subdocuments") . FROM..IN join语法只是一种语法糖,使您可以更轻松地在SQL查询中表达这些路径 . 例如,来自树路径的"remove"数组索引,并为 SELECTWHERE 部分提供了相当快捷方式 . 它实际上从未在查询中包含更多数据,只是将命名指针分配给每个待返回根文档中的部分 .

    索引路径只包含对匹配文档根的引用,它们不会复制“子文档” . 与关系SQL相反,CosmosDB中没有覆盖索引 .

    当您“选择子文档”时,实际上是在指示cosmosDB将根文档树表示的投影返回到其子部分 . 从某种意义上说,它是原始文档的(非序列化)视图 .

    Definitely go and check the video Azure Cosmos DB Indexing which explains it really well. 主要外卖是这张图片(以上视频截图):
    enter image description here

    关于表现

    对性能最重要的不是你如何引用索引树中的节点,而是它是否完全被索引并且选择性足够 . 索引值驻留在文档中的位置实际上并不太相关 .

    我想有一个理论上的开销可以更深入地遍历索引树(和文档树),但我很确定这种影响在实践中如此微观,你甚至无法测量它 . N ms查询中的大部分工作都花在别处(检查索引中匹配文档的附加谓词,从内部树模型构建输出Json对象,序列化) .

    与关系SQL类似,与完全根文档相比,仅返回“子文档”很可能稍微快一些,因为SELECT步骤可以跳过文档树的非相关部分 . 但可能它更多地取决于整体包含的树节点数和数据大小,而不是树的形状 .

    ..以及关于性能的通常建议 - DO write some tests . 对于CosmosDB,您可以测量RU成本并检查PopulateQueryMetrics header .

    更新:是否存储了子文档?

    上面的图形表明它们不是 - 仅链接到根文档 . 但这显然是一种简化,因此并不具有决定性 . 不过,你应该能够为此设计一个测试 . 另一种方法是通过askcosmosdb@microsoft.com向团队询问内部设计 .

相关问题