能否使用Cosmos DB SQL查询树层级任意深度的符合条件子节点

嵌套结构查询可行性说明 #

原生Cosmos DB SQL不支持递归查询语法，无法直接对未知深度的嵌套children数组做全层级遍历，你预期的直接返回所有nodeType = "foo"节点ID的高性能查询，在现有嵌套存储结构下无法实现。如果硬要通过多层JOIN写固定深度的查询，不仅无法覆盖未知深度的场景，还会产生极高的RU消耗，查询性能极差，完全不推荐。

更优存储与查询方案 #

方案1：扁平数组+树元数据存储（最推荐） #

你提到的将子对象存为扁平数组、单独维护树结构信息的方案，是当前场景下的最优解。调整后的文档结构示例如下：

{
  "id": 1,
  "text": "Root",
  "allNodes": [
    {"id": 2, "nodeType": "foo", "parentId": 1, "level": 1, "path": "/1/2"},
    {"id": 3, "nodeType": "foo", "parentId": 2, "level": 2, "path": "/1/2/3"},
    {"id": 6, "nodeType": "bar", "parentId": 2, "level": 2, "path": "/1/2/6"},
    {"id": 4, "nodeType": "foo", "parentId": 1, "level": 1, "path": "/1/4"}
  ]
}

调整后仅需要简单的SQL即可完成查询：

SELECT node.id FROM c JOIN node IN c.allNodes WHERE node.nodeType = "foo"

该查询可以通过添加索引实现极低的RU消耗和极高的查询性能，不受节点深度限制，后续对树节点的增删改操作只需要同步更新对应节点的parentId、level、path等元数据即可，适配绝大多数业务场景。

方案2：保留嵌套结构的替代方案 #

如果业务要求必须保留原有嵌套树结构，可以选择两种次优方案：

• 写入时冗余存储符合条件的ID：新增fooNodeIds字段，每次节点新增/修改/删除时，同步更新该数组字段，查询时直接读取该字段即可，性能最优，仅需要额外承担写操作的维护成本
• 应用侧遍历筛选：读取完整文档后，在应用代码中递归遍历筛选符合条件的节点ID，仅适合文档体积小、查询频率低的场景，RU消耗远低于多层JOIN查询。

内容的提问来源于stack exchange，提问作者Krumelur