如何加速跨两个集合的自定义GraphLookup实现？

问题背景 #

我在两个集合中存储了数百万个节点：较大的trustedNodes集合和较小的pendingNodes集合。每个节点包含UUID类型的_id、parentNodeId字段，以及文本类型的content字段。需要构建rootPath——从叶子节点到根节点的有序文档列表，优先使用trustedNodes中的节点，若不存在则使用pendingNodes中的节点（有时中间节点缺失，无法构建完整路径，平均路径深度约为3，最长可达100）。

当前实现的核心问题是请求次数过多：最多需要2*N次数据库请求（N为最终路径长度），伪代码逻辑如下：

• 先查询db.trustedNodes.find( { _id: 目标ID } )，未找到则查询db.pendingNodes.find( { _id: 目标ID } )
• 将找到的节点加入结果数组，再用该节点的parentNodeId重复上述查询逻辑
• 直到找不到节点或parentNodeId为空，最后返回结果数组，同时标记pathIsComplete（当最终节点的parentNodeId为空时为true）

此前尝试的方案均存在缺陷：

• 用$unionWith->$set->$group创建视图后执行$graphLookup，但视图无法创建索引，速度太慢
• 按需物化视图加索引不可行，因为需要强一致性，每次查询前更新物化视图同样缓慢
• 目前想到的优化是缓存已计算的可信路径（trusted路径不会变化），但希望找到更优雅的解决方案

优化方案 #

方案1：批量查询+内存拼接路径 #

利用平均路径深度低的特点，将多次单条查询合并为批量查询，大幅减少请求次数：

1. 收集ID链：从目标节点开始，循环查询节点并收集所有parentNodeId，直到parentNodeId为空或节点不存在，得到完整的待查ID列表
2. 批量查询可信节点：执行db.trustedNodes.find({_id: {$in: idList}})，将结果存入以_id为键的内存Map
3. 批量查询待处理节点：从idList中筛选出未在trustedNodes中找到的ID，执行db.pendingNodes.find({_id: {$in: missingIds}})，同样存入Map
4. 拼接路径：从目标ID开始，依次从Map中取节点，直到取不到或parentNodeId为空，最终生成有序路径并标记pathIsComplete

该方案最多仅需3次数据库请求，相比原实现的2*N次请求，性能提升显著。

方案2：单聚合管道完成路径查询 #

通过MongoDB聚合管道的$graphLookup和$lookup组合，一次性完成跨集合的路径查询，同时保证trustedNodes的优先级：

// 替换targetId为实际查询的节点ID
const targetId = "目标节点UUID";

db.pendingNodes.aggregate([
  // 合并目标节点的trusted和pending查询结果，优先保留trusted节点
  { $match: { _id: targetId } },
  { $unionWith: { coll: "trustedNodes", pipeline: [{ $match: { _id: targetId } }] } },
  { $group: { _id: "$_id", doc: { $first: "$$ROOT" } } },
  { $replaceRoot: { newRoot: "$doc" } },

  // 递归查询trustedNodes中的父节点路径
  { $graphLookup: {
      from: "trustedNodes",
      startWith: "$parentNodeId",
      connectFromField: "parentNodeId",
      connectToField: "_id",
      as: "trustedPath",
      depthField: "depth" // 记录节点在路径中的深度，用于后续排序
    }
  },

  // 收集trusted路径中缺失的父节点ID，用于查询pendingNodes
  { $addFields: {
      pendingIds: {
        $reduce: {
          input: "$trustedPath",
          initialValue: ["$parentNodeId"],
          in: { $concatArrays: ["$$value", ["$$this.parentNodeId"]] }
        }
      }
    }
  },

  // 查询pendingNodes中缺失的父节点
  { $lookup: {
      from: "pendingNodes",
      localField: "pendingIds",
      foreignField: "_id",
      as: "pendingPath"
    }
  },

  // 合并路径并排序（从叶子到根）
  { $addFields: {
      fullPath: {
        $concatArrays: [
          [$$ROOT],
          "$trustedPath",
          { $filter: {
              input: "$pendingPath",
              cond: { $not: { $in: ["$$this._id", "$trustedPath._id"] } }
            }
          }
        ]
      },
      sortedPath: {
        $reverseArray: {
          $sortArray: { input: "$fullPath", sortBy: { depth: 1 } }
        }
      },
      pathIsComplete: { $eq: [{ $last: "$sortedPath.parentNodeId" }, null] }
    }
  },

  // 返回最终结果
  { $project: { sortedPath: 1, pathIsComplete: 1 } }
])

注意：需给两个集合的_id和parentNodeId字段建立索引，才能保证聚合管道的执行效率。

方案3：强化缓存策略 #

针对trustedNodes路径不变化的特性，优化缓存逻辑：

1. 用Redis等缓存工具预计算并存储所有trustedNodes的完整路径，缓存键为节点_id，值为有序路径数组
2. 查询时优先查缓存：若存在则直接返回，再检查路径是否断链，若断链则补充查询pendingNodes
3. 若缓存不存在，先查询trustedNodes构建路径并存入缓存，再处理pendingNodes的补充逻辑

该方案适合查询频率高的场景，能进一步降低数据库压力。

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