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

Question

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

我能想到以下几点：

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

任何人都知道其他技巧吗？

Answer 1

规范化或不规范化;我相信NoSQL的下腹部通常会让人们回到SQL / RDBMS。我不想规范化，以便提供具有基本后端和前端代码的近实时索引简单查询。下面是related question中的一些伪代码，它显示了规范化时所需的复杂代码。很难在NoSQL中模仿连接和关系。

授予NoSQL确实会打开像你的“如果父母被改变，相应的更新是O（n）”这样的问题，其中n是父母改变的文件的后代数“我称之为”关系维护脚本'。但我发现你可以在非工作时间按计划（crontab）运行。人们也可能会强烈考虑安全表/集合并构建易失性或工作表。有关OLAP表，请参阅this question。在那里，您可以在漂亮的整洁表格中建立关系，然后创建那些丑陋的快速集合。

确定NoSQL是否真的适合你。即使在个人层面上，您更喜欢更快，更具可扩展性和更混乱 - 或更慢，不可扩展和整洁/有组织。权衡类似于经典的快速，好又便宜的三角形。基本上，NoSQL快速而便宜; SQL很好。 NoSQL的优点是可扩展性;而SQL的快速实际上是可敬的。