Question

我正在努力将数据库移植到MongoDB，并且遇到了文档大小限制的一些问题。

我的理解是，如果您要始终在另一个实体的上下文中查看一个实体，那么嵌入就是最佳选择。

然而，数据（基因组）有很多每种类型的实体，即使只是在嵌入文档中存储_id字段，我也会超过16 MB的大小限制：

Genome
{
  ...
  has_reactions:[id1, id2, ... idn] // Where n is really large
}

我也尝试过以其他方式对其进行建模，但遇到了同样的限制：

Reaction
{
  ...
  in_genomes:[id1, id2, ... idn] // Still really large
}

MongoDB documentation提供了一对一和一对多关系的很好的例子，但在多对多关系中没有多少说法。

在传统的SQL中，我使用Genome，Reaction和GenomeReaction表格对其进行建模。这是去这里的唯一方法吗？

修改

至于背景，反应是一种代谢反应，尽管在这种背景下基因组和反应的含义并不重要。它也可能是我的每个小部件中垫圈类型之间的关系。这是一个标准的多对多关系，其中“many”的两个实例都可以是一个非常大的数字。

我知道Mongo不允许连接，但使用多个查询很容易解决，这是处理document references in Mongo的推荐方法。

我们没有选择Mongo作为解决方案，我们只是将其作为可能的解决方案进行评估。它看起来很有吸引力，因为它被称为能够处理“huMONGOus数据集”，所以我对这个限制感到有些惊讶。

在我们所有其他用例中，Mongo运行良好。只是这种特殊的关系，我无法在不使用Genome，Reaction和GenomeReaction集合的情况下从mysql移植到mongo。我可以轻松地做到这一点，但我希望有更多的mongoy方式来处理它。

也许mongo没有很好地处理多对多关系，这可以解释它在文档中data model scenarios列表中的明显缺失。

Answer 1

在官方的mongo-db邮件列表上询问了这个问题之后，我发现处理这样的场景的推荐方法是使用我在原帖中提到的三个集合映射，或者使用“{{3 “其中一个集合存储在存储桶中。

所以你有类似的东西：

// genomes collection
{
  _id: 1,
  genome_thingee: 'blah blah'
  ...
}

// reaction_buckets collection
{
  _id: ObjectId(...),
  genome_id: 1,
  count: 100,
  reactions: [
    { reaction-key1: value, reaction-key 2: value},
    { reaction-key1: value, reaction-key 2: value},
    { reaction-key1: value, reaction-key 2: value},
    { reaction-key1: value, reaction-key 2: value},
    { reaction-key1: value, reaction-key 2: value},
    ...]
}

正如您可能想象的那样，在hybrid schema design时，您的应用程序必须考虑到这种模型的各种含义。

虽然最终这种方法并不真正吸引我（因此我决定在@ Philipp的建议下看看Neo4j），我想我会发布解决方案以防其他人需要解决类似问题不介意混合/桶方法。

如何在MongoDB中为非常多的关系建模

1 个答案: