在MongoDB中存储树数据结构的最有效方法是什么？

Question

我在想最简单的事情就是一个单一的列表：

{
  id: ObjectId()
  parentId:  ObjectId()
  value: ‘foo’,
}

只是一个大集合。要查找节点的子节点，只需搜索列表并查找parentId等于当前节点ID的所有实例。 id / parentId上的索引。

写入可能会更快，但读取可能会变得非常可怕。 而且我们将有更多的读取而不是写入！

MongoDB有一些内置的树数据结构： https://docs.mongodb.com/manual/applications/data-models-tree-structures/

但我想知道这与我提议的那个平面列表有什么不同。

Answer 1

如果您在id上定义索引并在parentId上定义索引，请找到节点的子节点应该非常快。

为什么你认为它会变得可怕？

更新：最糟糕的情况是O(log N)，但重要的是要注意Mongo使用的存储分区大小是8192（source）。这意味着这个时间乘以一个非常小的常数，这意味着MongoDB操作可以非常快。

Answer 2

这在实际应用中很棘手。 MongoDB 推荐五种方式：

<块引用>

带有父引用的模型树结构： 展示了一个数据模型，通过在“子”节点中存储对“父”节点的引用，以树状结构组织文档。

<块引用>

具有子引用的模型树结构： 展示了一个数据模型，通过在“父”节点中存储对“子”节点的引用，以树状结构组织文档。

<块引用>

使用祖先数组建模树结构： 展示了一个数据模型，通过存储对“父”节点的引用和一个存储所有祖先的数组，以树状结构组织文档。

<块引用>

具有实体化路径的模型树结构： 提供一个数据模型，通过存储文档之间的完整关系路径，以树状结构组织文档。除了树节点之外，每个文档都将节点的祖先或路径的 _id 存储为字符串。

<块引用>

具有嵌套集的模型树结构： 提供一个数据模型，该模型使用嵌套集模式以树状结构组织文档。这以牺牲树的可变性为代价优化了发现子树。

查找完整说明 here。