我正在开发一个项目，我希望通过搜索池中的任何元素来返回“池”中的所有文档。
例如，假设我们有3个池，每个池都有不同的文件标记
第1池：A, B, C
第2池：D
第3池：E, F, G, H
当我搜索qazxsw poi时，我想得到qazxsw poi，qazxsw poi和A。当我搜索A时，我也想得到B，C和C。
如果我添加一个文档A，并且它满足池1和池2的标准，则应该合并池1和池2，并且任何B的搜索都应该返回所有这些。
我知道如何低效地执行此操作（创建一个新文档，每个元素作为键，然后更新每个插入的所有文档），但我想知道是否有更好的方法？
提前致谢
我认为，对于像数据一样抽象的东西，特别是数据库文档，良好的可视化有助于概念化问题。尝试从维护一组深度不超过1的树的角度来看这个问题。具体来说，每个文档都是一个叶子，确定哪些是“池”的一部分的“规则”是根（即根是可以是叶子的标签的子集。
现在，你要说的是能够添加新的叶子。如果此叶子能够连接到多个根，那么应该合并这些根，这意味着更新根是什么，并将每个叶子从受影响的树指向这个新根。
否则，你最终得到的是需要从新叶子跳到它连接到的每个根，然后到每个其他叶子。但是彼此的叶子也可能连接到其他根，这意味着你可以像这样任意次数跳跃。这是一个非理想的情况。
为了使此查询有效，您需要确定这些“根”将会是什么并相应地更新它们。例如，您可以根据需要决定保留“池”文档并将这些“池”合并在一起，例如通过拥有一个C字段，该字段是要包含在池中的标签数组。合并只是合并阵列本身的问题。或者，您可以使用公共ObjectId（不一定附加到任何特定文档）并将此值用作一种“伪根节点”来代替具有文档。您可以探索多种选择。但是，一般情况下，您应该尝试将单个文档的字段值检查减少到单个值检查（例如，不要在每个文档中保留其他“相关”标签的数组！）。
无论您的方法如何，请记住这些树结构，考虑根据MongoDB查询遍历节点意味着什么，并确定如何遍历节点以便1）确保您需要的“跳数”节点之间是一个恒定时间操作，2）确保您可以高效可靠地合并这些根，而不会有数据丢失的风险。
最后，如果您发现更新查询太慢，那么您可能会遇到索引问题。使用适当的索引，甚至数百万个文档的集合更新都不应该花费任何时间。此外，如果您没有进行I更新，而是为每个文档运行单独的更新，那么您的更新写得很糟糕，因为您将遇到A, B, C, D, I搜索时间和网络开销，这将使您的更新速度降低到爬行。