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

我有一个Mongo数据库集合中的数据，其中每个文档都有父节点的标识。如果我想搜索所有具有特定文档（我将其称为P）的文档（即P是父母，祖父母，祖父母等），那么我有什么选择可以有效地做到这一点，并且那些选项的优点和缺点是什么？如何在mongo中高效搜索树的子集？

我能想到如下：每个文档中

存储整个血统，所以你可以搜索文档谁的祖先列表中包含P.
- 优势：
  - 固定的时间看up
- 缺点：
  - 如果更改了父项，则相应的更新为O（n），其中n是父项已更改的文档的后代数
  - 某些存储开销O（a）其中a是文档的平均深度
在搜索时，先建普的子文档，然后孙子文件等的ID的列表，然后搜索所有文件与IDS
- 优势：
  - 无需改变存储Ë结构，不需要额外的空间开销
- 弱点：
  - 构建ID列表是为O（n）操作，其中n是文件的数量与P
  - 后代的可能上百个搜索IDS的可能不是有效的

任何人都知道的其他技术？

来源

2014-12-02 B T

你看过 - http://docs.mongodb.org/manual/applications/data-models-tree-structures/？ – BatScream 2014-12-02 22:07:50

我没有，但它是一个非常相关的参考。看起来像“祖先阵列”和“物化路径”本质上是相同的东西，都是我的第一选择。嵌套设置对我来说不是一种选择，其他两个实质上就是我已经在做的 – 2014-12-02 23:40:03

正常化或不正常化;我相信那些经常让人们转向SQL/RDBMS的NoSQL下腹部。为了使用基本的后端和前端代码提供接近实时的索引简单查询，我宁愿不进行规范化。 Heres在related question中有一些伪代码，它显示了规范化时需要的复杂代码。很难模拟NoSQL中的连接和关系。 “如果父母改变了，相应的更新是O（n），其中n是父母改变的文档的后代数目”我称之为'关系维护脚本'。但是我发现你可以在非工作时间以计划的（crontab）为基础运行它们。人们也可以强烈考虑安全的表/集合并构建易失性表或工作表。有关OLAP表，请参见this question。在那里，你可以在漂亮整洁的桌子上建立你的关系，然后创建那些丑陋的快速收藏。

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

来源

2014-12-02 22:32:32

嗯，所以实际上我认为你在关系数据库中会遇到同样的问题。连接或不连接，树也不容易在SQL中表示。离线运行“关系维护脚本”仅适用于基本上损坏的数据。这对我不起作用。我不是很清楚你的建议或推荐。你给的链接似乎只与我的问题有很小的关系。 – 2014-12-02 23:56:01

即时通讯建议你做选项1.一个人可以对树进行单个（但复杂）的sql语句，但使用nosql是不可能的。因此要么构造数据以适合单个查询，要么创建非常复杂且缓慢的映射/减少或后端。对我来说，它的快速和丑陋的数据和干净的专有代码。你也可以看看neo4j或类似的图形nosql，也许这些将提供一个很好的平衡黑白速度和丑陋的数据结构。 – 2014-12-05 20:51:11

我想那种类似mysql的递归查询是不可能的，但是在其他系统中。所以我对多个查询很满意，这使得它尽可能的像在sql中一样，基本上也是可扩展的。要做到这一点，即使在使用递归查询的SQL中，我也认为你必须构建相同的混乱数据。但是，谢谢。 – 2014-12-06 01:18:09

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

回答

相关问题