为什么要用MongoDB

两个关键：灵活性和横向扩展能力

1. MongoDB是灵活的文档模型，也就是说，如果预计我的数据可以被一个稳定的模型来描述，会倾向于使用MySQL等关系型数据库。而一旦我认为我的数据模型会经常变动，比如我很难预料到用户会输入什么数据，这种情况下更加倾向于使用MongoDB。
2. MongoDB更容易进行横向扩展。虽然关系型数据库也可以通过分库分表来达成横向扩展的目标，但是扩展和运维都比MongoDB要困难复杂的多，而这一切在MongoDB里都是自动的，你基本上不需要操心。

MongoDB的分片机制

当下，跟数据存储和检索有关的中间件基本上都会支持分片，或者步入分布式时代后诞生的中间件，基本都会考虑分片机制。
在MongoDB里，可以使用所谓的分片集合（collection）。每一个分片集合都被分成若干个分片，如果按照关系型数据库分库分表的说法，那么集合就是逻辑表，分片就是物理表。每个分片又由多个块（chunk）组成，在最新版本的默认情况下，一个块的大小是128MB

如果一个块满足了下面的任何一个条件，就会被拆分成两个块，简单来说就是数据太多或文档太多：

• 数据过多：默认一个块是128MB，但是这个块上放的数据超过了128MB，就会被拆分
• 文档太多：阈值是平均每个块包含的文档数量的1.3背，也就是，如果平均每个块可以放1000个文档，但是当前块上放了超过1300个文档，这个块也会被切分
  
  在分库分表里，经常会遇到的一个问题是，不同表之间的数据并不均衡，有的多有的少。所以这就要求在设计分库分表方案的时候，要尽可能准确预估每一个物理表的数据，确保均衡。
  在MongoDB里，会自动平衡不同分片的数据，尽量做到每个分片都有差不多的数据量，整个机制也叫做负载均衡。只不过一般意义上的负载均衡强调的是流量负载均衡，而这里强调的是数据量负载均衡。
  而发现数据不均匀之后，迁移数据的过程也叫做再平衡，本质上就是挪动块。
  
  什么时候才会触发再平衡过程呢？MongoDB设定了一些阈值，超过了这个阈值就会触发再平衡的过程，具体的阈值表如下：

举个例子，如果一个集合里面最大的分片有9个块，最少的集合有7个块，就会触发再平衡。假设我们要迁移块A，过程如下：

1. 平衡器发送moveChunk命令到源分片上
2. 源分片执行moveChunk命令，这个时候读写块A的操作都是源分片来负责的
3. 目标分片创建对应的索引
4. 目标分片同步块A的数据
5. 当块A最后一个文档都同步给目标分片后，目标分片会启动一个同步过程，把迁移过程中的数据变更也同步过来。
6. 整个数据同步完成之后，源分片更新元数据，告知块A已经迁移到了目标分片
7. 当源分片上的游标都关闭后，他就可以删除块A了。

整个过程和别的中间件的数据迁移过程都差不多