我什么时候应该在MongoDB中创建一个新的集合？

Question

这里只是一个快速的最佳实践问题。我怎么知道何时应该在MongoDB中创建新的集合？

我有一个查询电视节目数据的应用。每个节目是否都有自己的集合，或者它们是否应该存储在一个集合中，并在同一文档中包含相关数据。请解释您选择所采用方法的原因。 （我仍然是MongoDB的新手。我已经习惯了MySql。）

Answer 1

MongoDB中两种最流行的架构设计方法

1. 将数据嵌入文档并将其存储在单个集合中。
2. 将数据标准化为多个集合。

嵌入数据

MongoDB不支持跨集合的连接有几个原因，我不会在这里介绍所有这些。但是我们不需要连接的主要原因是因为我们可以将相关数据嵌入到单个分层JSON文档中。在我们存储数据之前，我们可以将其视为预加入数据。在关系数据库世界中，这相当于对我们的数据进行非规范化。在MongoDB中，这是我们可以做的最常规的事情。

规范化数据

尽管MongoDB不支持连接，但我们仍然可以将相关数据存储在多个集合中，并且仍然可以实现所有这些，尽管可以实现。这要求我们存储对另一个集合中一个集合的密钥的引用。它听起来与关系数据库类似，但MongoDB并没有像大多数关系数据库那样对我们强制执行任何关键约束。执行关键约束完全取决于我们。我们已经足够管理了，对吧？

以这种方式访问​​所有相关数据意味着我们需要为存储数据的每个集合至少进行一次查询。由我们每个人决定我们是否能够忍受这一点。

何时嵌入数据

1. 在与文档其余部分同时访问嵌入数据时嵌入数据。经常一起使用的预加入数据减少了我们必须在多个集合中写入查询的代码量。它还减少了到服务器的往返次数。
2. 当嵌入数据仅与该单个文档相关时嵌入数据。像大多数规则一样，我们需要在盲目跟随之前给出一些想法。如果我们为用户存储地址，我们不需要创建单独的集合来存储地址，因为用户可能有一个具有相同地址的室友。请记住，我们在这里没有规范化，所以在某种程度上重复数据是可以的。
3. 在需要“类似交易”的写入时嵌入数据。在v4.0之前，MongoDB不支持事务，但它确保单个文档写入是原子的。它会写文件或不会。跨多个集合的写入无法成为原子，并且可能会出现更多异常情况，因为我们可以想象有多少场景。自v4.0以来不再是这种情况，但是更典型的是对数据进行非规范化以避免需要进行事务处理。

何时归一化数据

1. 当适用于许多文档的数据频繁更改时，对数据进行规范化。所以这里我们谈论的是“一对多”关系。如果我们有大量的文件，其城市字段的值为“纽约”，纽约市突然决定将其名称更改为“新纽约”，那么我们必须更新很多文件。有异常吗？在这种情况下，我们怀疑其他城市会效仿并更改其名称，那么我们最好创建一个包含每个城市单个文档的cities集合。
2. 在数据频繁增长时规范化数据。文档增长时，必须将它们移动到磁盘上。如果我们嵌入的数据经常超出其分配的空间，则必须经常移动该文档。由于这些文件每次移动时都会变大，因此过程变得越来越复杂，随着时间的推移不会变得更好。通过规范化经常增长的嵌入式部件，我们无需移动整个文档。
3. 当文档预计增长超过16MB 时规范化数据。 MongoDB中的文档限制为16MB。这就是事情的方式。如果我们接近这个限制，我们应该开始将它们分解成多个集合。

MongoDB中对模式设计的最重要考虑是......

我们的应用程序如何访问和使用数据。这需要我们思考？ UHG！什么数据一起使用？哪些数据主要用作只读？经常写什么数据？让您的应用程序数据访问模式驱动您的架构，而不是相反。

Answer 2

你所描述的范围对于“一个集合”来说绝对不是太多。事实上，能够将所有内容存储在一个地方是MongoDB集合的重点。

在大多数情况下，您不希望像在SQL中那样考虑跨组合表进行查询。与SQL不同，MongoDB允许您避免考虑“JOIN” - 实际上MongoDB甚至不支持它们本地。

请参阅此幻灯片： http://www.slideshare.net/mongodb/migrating-from-rdbms-to-mongodb?related=1

具体看一下前面的幻灯片24。请注意MongoDB架构如何替换SQL和RDBMS习惯的多表架构。

在MongoDB中，单个文档包含有关记录的所有信息。所有记录都存储在一个集合中。

另见这个问题： MongoDB query multiple collections at once