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

我在Mongo数据库集合中有数据，其中每个文档都有一个父级id。如果我想搜索在其祖先（即P是其父母、祖父母、曾祖父母等）中包含特定文档（我将其称为P）的所有文档，我有哪些有效的选项，以及这些选项的优点和缺点是什么

我可以想到以下几点：

• 在每个文档中存储整个祖先，以便您可以搜索祖先列表中包含P的文档。
  • 优势：
    • 定时查找
  • 弱点：
    • 如果父项发生更改，则相应的更新为O（n），其中n是父项发生更改的文档的子代数
    • 一些存储开销，O（a），其中a是文档的平均深度
• 搜索时，首先构建P的子文档的ID列表，然后是孙子文档等。然后使用这些ID搜索所有文档
  • 优势：
    • 无需更改存储结构，无需额外的空间开销
  • 弱点：
    • 建立id列表是一个O（n）操作，其中n是从P派生的文档数
    • 通过数百个ID进行搜索可能效率不高

---

有人知道其他技术吗？

正常化或不正常化；我相信这就是NoSQL的不足之处，它常常让人们转向SQL/RDBMS。我不希望为了提供具有基本后端和前端代码的近实时索引简单查询而进行规范化。下面是a中的一些伪代码，显示了规范化时所需的复杂代码。在NoSQL中很难模拟连接和关系

假定NoSQL确实打开了一个真正的问题的巢穴，比如“如果父项发生了更改，相应的更新是O（n），其中n是父项发生更改的文档的子代数”，我称之为“关系维护脚本”。但我发现您可以在非工作时间按计划（crontab）运行这些程序。还可以强烈考虑安全表/集合并构建易失性或工作表。请参阅有关OLAP表的信息。在那里，你可以在漂亮整洁的表格中建立你的关系，然后创建那些丑陋的快速集合

---

这是一个确定NoSQL是否真正适合您的问题。即使在个人层面上，你更喜欢更快、可扩展、杂乱无章，还是更慢、不可扩展、整洁/有条理。这种权衡类似于经典的快速、优质和廉价三角形。基本上，NoSQL是快速和廉价的；SQL很好。NoSQL的优点是可伸缩性；虽然SQL的fast实际上是值得尊敬的。

您是否研究过-？我没有，但它是一个非常相关的参考资料。看起来“祖先数组”和“物化路径”本质上是一样的，都是我的第一选择。嵌套集对我来说不是一个选项，另外两个基本上是我已经在做的，所以实际上我认为在关系数据库中也会有完全相同的问题。连接或不连接，树也不容易在SQL中表示。脱机运行“关系维护脚本”只有在对基本损坏的数据没有问题的情况下才可以。这对我不管用。我不太清楚你在建议什么。你给出的链接似乎与我的问题关系不大。我建议你选择选项1。可以对树执行单个（但很复杂）sql语句，但使用nosql是不可能的。因此，要么构造数据以适应单个查询，要么创建一个非常复杂且缓慢的map/reduce或后端。对我来说，这是快速而丑陋的数据和干净的专有代码。你也可以看看neo4j或类似的图形nosql，也许它们会提供一个很好的平衡b/w速度和丑陋的数据结构。我猜这种递归查询在mysql之类的系统中是不可能的，但在其他系统中是可能的。所以我可以使用多个查询，这使得它与sql中的查询一样，而且基本上也是可伸缩的。为了更快地完成这项工作，即使在使用递归查询的SQL中，我认为您也必须构建同样混乱的数据。但是谢谢。