如何在 mongo 中有效地搜索树的子集？

Question

我在 Mongo 数据库集合中有数据，其中每个文档都有父级的 id。如果我想搜索在其祖先中具有特定文档（我将其称为 P）的所有文档（即 P 是它的父母、祖父母、曾祖父母等），我有什么选择可以有效地做到这一点，并且这些选项的优缺点是什么？

我能想到以下几点：

• 将整个祖先存储在每个文档中，这样您就可以搜索祖先列表中包含 P 的文档。
  • 优势：
    • 恒定时间查找
  • 缺点：
    • 如果更改了父级，则相应的更新为 O(n)，其中 n 是更改了父级的文档的后代数
    • 一些存储开销，O(a)，其中 a 是文档的平均深度
• 搜索时，首先建立一个P的子文档的id列表，然后是孙文档等。然后搜索所有具有这些id的文档
  • 优势：
    • 无需更改存储结构，无需额外的空间开销
  • 缺点：
    • 建立 id 列表是一个 O(n) 操作，其中 n 是 P 的后代文档数
    • 按可能数百个 ID 进行搜索可能效率不高

有人知道其他技术吗？

Answer 1

规范化或不规范化；我相信这就是经常让人们转向 SQL /RDBMS 的 NoSQL 的弱点。我不喜欢规范化，以便通过基本的后端和前端代码提供近乎实时的索引简单查询。这是related question 中的一些伪代码，显示了规范化时所需的复杂代码。在 NoSQL 中很难模拟连接和关系。

Granted NoSQL 确实打开了一个真正的老鼠窝，例如您的“如果更改了父级，则相应的更新是 O(n)，其中 n 是父级更改的文档的后代数”我称之为“关系维护脚本”。但我发现您可以在非工作时间按计划（crontab）运行这些。人们也可能会强烈考虑安全表/集合并构建易失性或工作表。有关 OLAP 表，请参阅 this question。在那里，您可以将您的关系放在漂亮整洁的表格中，然后创建那些丑陋的快速集合。

这是一个确定 NoSQL 是否真的适合您的问题。即使在个人层面上，您更喜欢更快、可扩展和混乱 - 还是更慢、不可扩展和整洁/有条理。类似于经典的快速、好和便宜的三角形的权衡。基本上，NoSQL 又快又便宜； SQL 很好。 NoSQL 的优点是可扩展性；而 SQL 的速度实际上是值得尊敬的。