我什么时候应该在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/migration-from-rdbms-to-mongodb? lated=1

具体请看第 24 张以后的幻灯片。请注意 MongoDB 模式如何取代 SQL 和 RDBMS 惯用的多表模式。

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

另请参阅这个问题： MongoDB query multiple collections at Once