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

Question

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

我有一个查询电视节目数据的应用。每个节目应该有自己的集合，还是应该将它们都存储在一个集合中，并在同一个文档中包含相关数据。请解释你为什么选择你所做的方法。 （我对 MongoDB 还是很陌生。我已经习惯了 MySql。）

Answer 1

MongoDB 中最流行的两种模式设计方法

1. 将数据嵌入文档并将它们存储在单个集合中。
2. 跨多个集合规范化数据。

嵌入数据

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

标准化数据

即使 MongoDB 不支持连接，我们仍然可以跨多个集合存储相关数据并且仍然可以访问所有数据，尽管是以一种迂回的方式。这要求我们将一个集合中的键的引用存储在另一个集合中。这听起来类似于关系数据库，但 MongoDB 不像大多数关系数据库那样为我们强制执行任何关键约束。执行关键约束完全取决于我们。不过，我们足以应付它，对吧？

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

何时嵌入数据

1. 当嵌入的数据与文档的其余部分同时被访问时，嵌入数据。经常一起使用的预连接数据减少了我们必须编写的跨多个集合查询的代码量。它还减少了到服务器的往返次数。
2. 当嵌入数据仅与单个文档相关时嵌入数据。像大多数规则一样，我们需要在盲目遵循之前考虑一下。如果我们为用户存储地址，我们不需要创建单独的集合来存储地址，因为用户可能有一个具有相同地址的室友。请记住，我们没有在这里进行标准化，因此在某种程度上复制数据是可以的。
3. 当您需要“类事务”写入时嵌入数据。在 v4.0 之前，MongoDB 不支持事务，但它确实保证单个文档写入是原子的。它会写文件，否则不会。跨多个集合的写入不能成为原子的，并且对于我们可以想象的多少个场景都可能发生更新异常。从 v4.0 开始不再是这种情况，但更常见的是对数据进行非规范化以避免需要事务。

何时规范化数据

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

MongoDB 架构设计最重要的考虑因素是......

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

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