mongodb - MongoDB 中海量关系的最佳数据模型

Question

我们正在采用 MongoDB 作为一种新的解决方案，目前正在努力设计最有效的数据模型来满足我们对数据项之间关系的需求。

我们必须在用户、项目和列表之间保持三向关系。一个用户可以有很多项和很多列表。一个列表将有一个用户和许多项目。一个项目可以属于多个用户和多个列表。后者尤其重要——一个项目可能属于潜在的大量列表:数千个，当然也可能有数万或数十万个。 future 甚至可能达到数百万。我们需要能够在两个方向上导航这些关系:例如，获取列表中的所有项目或项目所属的所有列表。我们还需要通用的解决方案，以便我们可以在需要时添加更多类型的文档和它们之间的关系。

所以看起来有两种可能的解决方案。第一个是数据库中的每个文档都有一个由 ID 数组组成的“关系”集合。因此，列表文档将有一个关系集合，其中包含所有项的 ID，以及一个包含单个用户 ID 的关系集合。在此模型中，当一个项目属于很多很多用户或很多很多列表时，这些数组将变得庞大。

第二个模型需要一种新型文档，一种“关系”文档，用于存储每个合作伙伴的 ID 和关系名称。这总体上存储了更多数据，因此会影响磁盘空间。在 NoSQL 中，它看起来也是一种“不自然”的解决方法。

性能方面、空间方面、架构方面，哪个更好，为什么？

干杯，马特

Answer 1

这取决于您的访问模式。

• 嵌入的 id 数组更利于阅读。通过快速阅读，您可以获得所有相关对象的 ID，现在可以去获取它们。但是如果你的更新率很高，你就会遇到一些麻烦，因为 mongodb 将不得不一遍又一遍地复制相同的(已经很大的)对象，因为它超出了它的磁盘边界。

  但是这个解决方案真的不利于写入。想象一下属于几百万个列表的项目。你决定删除它。现在您必须遍历所有这些列表并从它们的引用数组中提取该项目的 ID。这很令人兴奋，不是吗？

• 将引用文献存储为单独的文档有利于写入。添加、编辑和删除新引用非常快。但是这个解决方案需要更多的磁盘空间，更重要的是，需要宝贵的 RAM。读取速度也没有那么快，尤其是当您有很多引用文献时。

  鉴于您的数字(“ future 可能甚至数百万”)，我会选择这个解决方案。你总是可以投入一些硬件来加速查询。传统上，扩展写入是最困难的部分，而在此解决方案中，写入速度快且可分片。