Azure CosmosDB 多项目数组关联JOIN查询无结果的原因与实现

为什么查b2能出结果、查b7无返回 #

• Azure Cosmos DB 的JOIN能力有明确边界：仅支持对单个根文档内部的嵌套数组做关联匹配，完全不支持跨独立根文档的联表操作，和关系型数据库的跨表JOIN逻辑有本质区别。
• 能查到b2的原因：和b2相关的所有关联数据（作者列表、关联关系记录）全部存储在id为33a127b7-a0b6-4207-8092-caf15aaae820的单个根文档内。执行JOIN时，操作范围限定在这个根文档的author_documents、joining_documents两个数组间，能命中“作者id和关联记录作者id匹配”的规则，因此正常返回结果。
• 查b7无结果的原因：和b7相关的所有关联数据被拆分到了三个完全独立的根文档中：
  • 作者a3的信息存在id为271ffe0c-56c1-4eec-be6c-a5b1d6ff6e72的单独文档
  • 书籍b7的信息存在id为c88a968e-4d4e-4a25-be6b-4661f314b7c5的单独文档
  • 作者a3与书籍b7的关联记录存在id为9c7279ab-9e13-4a39-b61b-a03ad2b2652a的单独文档
• 遍历每个独立根文档时，要么缺失author_documents字段，要么缺失joining_documents字段，JOIN阶段直接产生空集被过滤，最终没有任何匹配结果。

多关联查询的可行性说明 #

• 你写的JOIN语法本身完全合法，单文档内部的多数组关联查询可以稳定实现，且因为不需要跨文档匹配，查询延迟远低于关系型数据库的联表操作，只要关联的数组都存在于同一个根文档内，查询逻辑就能正常运行。
• 跨独立根文档的关联查询无法通过SQL JOIN实现，常见的可行落地方式：
  • 调整存储模型：把需要关联查询的作者、书籍、关联关系统一存储在同一个根文档的对应数组中，避免把强关联数据拆分到多个独立文档。
  • 应用层聚合：如果业务场景不允许调整存储结构，可以先通过按id、分区键批量拉取的方式，分别获取作者、书籍、关联关系的原始数据，在应用代码中完成关联匹配。

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