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

Question

在cosmosdb中查询子文档的成本是多少？阅读文档时，似乎仅对ID及其路径进行了索引。

这是否意味着您每次querying on a subdocuments都使用From子句，像这样：

SELECT * 
FROM Families.children

它将解析与该路径匹配的文档并创建它们的视图吗？子文档也存储吗？

Answer 1

如何编制索引

CosmosDB将整个JSON文档存储为树（任何深度，包括我想您所说的“子文档”）。 FROM..IN连接语法只是一个语法糖，使您可以更轻松地在SQL查询中表达这些路径。例如，从树路径中“删除”数组索引，并为SELECT和WHERE部分提供漂亮的快捷方式。实际上，它永远不会在查询中包含更多数据，而只是将命名指针分配给每个要返回的根文档中的各个部分。

已建立索引的路径仅包含对匹配文档根目录的引用，它们不构成“子文档”的副本。与关系SQL相反，CosmosDB中没有覆盖索引。

“选择子文档”时，实际上是在指示cosmosDB将投影从根文档树表示形式返回到其子部分。从某种意义上讲，它是原始文档的（非序列化）视图。

肯定要去看一下视频Azure Cosmos DB Indexing，它解释得很好。主要要点是此图像（以上视频的截图）：

关于性能

对于性能而言最重要的不是如何在索引树中引用节点，而是是否对索引进行了索引并具有足够的选择性。实际上，索引值位于文档中的位置不太相关。

我想深入遍历索引树（和文档树）在理论上有开销，但是我很确定这种影响实际上是存在的，因此您通常甚至无法测量它。 N ms查询中的大部分工作都花在其他地方（检查与索引匹配的文档上的其他谓词，从内部树模型构建输出Json对象，序列化）。

类似于关系SQL，与完整根文档相比，仅返回“子文档”最有可能稍微快一点，因为SELECT步骤可以跳过文档树中无关的部分。但这可能更多地取决于总体上包含的树节点数和数据大小，而不取决于树的形状。

..和有关性能的通常建议-要做一些测试。对于CosmosDB，您可以测量RU成本并检查PopulateQueryMetrics header。

更新：是否存储了子文档？

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