MongoDB的需求目标
MongoDB是一款知名的NoSQL数据库，其设计哲学是结合关系型数据库的核心能力和NoSQL的关键技术。
上图的左侧即MongoDB目标实现的关系型数据库的关键能力：
- 善于表达的查询语言：用户应能够使用丰富的方法访问和操作数据，以支持联机应用和分析应用。
- 辅助索引：索引是高效访问数据的关键，数据库系统应提供对索引的原生支持。
- 强一致性：应用应当立即读到提交到数据库的数据。应避免渐近一致性数据模型(Eventually Consistent Model)导致的复杂应用开发。
- 企业级管理和集成：数据库应当与企业的IT技术栈无缝的集合，满足企业级的需求。组织需要数据库是安全的、可监控的、自动化的，并且可与已有技术基础架构、流程和人员(运维，DBA，分析师)集成。
上图的右侧，展示了MongoDB目标实现的NoSQL数据库的技术，以满足现代应用的需求：
- 灵活的数据模型：与传统关系型数据库相比，现代的NoSQL数据库提供了灵活的数据模型，可以方便的存储任何结构的数据，并且允许不停机且不影响性能的情况下修改Schema。
- 可扩展性和性能：NoSQL数据库专注于可扩展性(Scalability)，都有某种形式的分片(sharding)或分区(partitioning)。这使得NoSQL数据库可以在商用硬件上水平扩展，获得几乎无限的高吞吐量和低延时。
- 无中断全球部署：NoSQL设计用为持续可用系统，可为全球用户提供一直的高质量的体验。NoSQL数据库被设计用于在众多结点间运行，可在服务器，机柜，甚至跨地域的数据中心间自动同步数据。
MongoDB架构概览
笔者暂时没找到一张完整的架构图可以体现MongoDB的组件和它们之间的关系。
MongoDB灵活存储架构
存储引擎是数据库和硬件之间的接口，它负责处理用什么数据结构存储数据，以及如何写入、删除和读取数据。不同的工作负载类型对于读写性能的需求不同，例如新闻网站需要大量的读，而社交类网站需要大量的写。MongoDB 3.0开始，提供了可插拔的存储引擎API，使得用户可以在MongoDB和第三方提供的多种存储引擎之间切换。
在一个MongoDB复制集中，多种存储引擎可以并存，可以满足应用更复杂的需求。例如，使用In-memory存储引擎进行低延时的操作，同时使用基于磁盘的存储引擎完成持久化。
WiredTiger
目前MongoDB默认使用的是WiredTiger存储引擎，WiredTiger是SleepyCat提供的一款开源数据引擎。通过使用现代编程技术，如Hazard指针和Lock-free算法，WiredTiger实现了多核可扩展性。
《MongoDB实战》的作者在书中对WiredTiger和老的存储引擎做了MMAPv1比较测试，WiredTiger要节省85%的存储空间，开启压缩后比WiredTiger节省90%；写操作时优势不明显；从磁盘顺序读时，WiredTiger要快69%，开启压缩后比WiredTiger快68%。
三方存储引擎
RocketsDB是Facebook开发的一款键值存储数据库，通过使用LSM树引擎，RocketsDB适合于需要高速写入性能的应用，如社交媒体。
In-memory存储引擎可为实时分析应用提供极高的性能，MongoDB自带的In-memory存储引擎是企业高级版中才有的，Percona Server for MongoDB中提供了免费的In-memory存储引擎，有需求的读者可以试用。
复制——MongoDB的高可用方案
MongoDB提供了复制集（Replica Set）以提供数据保护、负载均衡和容灾能力。复制集是一组配置成可自动同步数据和故障切换（Failover）的结点。早期版本MongoDB提供的主从（Master Slave）数据复制只支持数据同步，而不支持自动故障切换，已被复制集替代。MogoDB的Journaling日志功能也提供了数据保护能力，与复制集相比，Journaling可以大幅提升故障后数据恢复的速度，常与复制集一起使用。虽然备份不能像复制一样准实时进行，但是备份可以挽救逻辑错误，比如应用或运维人员误删除了数据，因此也需要在生成环境使用。
如图所示，一个MongoDB复制集至少由3个节点组成，其中可写可读的主节点（Primary）有且仅有一个。副节点（Secondary）可以有一致多个，副结点使用长轮询（Long Polling）技术准实时地从主节点local集合中获取包含数据变化信息的Oplog，应用于副结点库，这个过程是异步的，即复制故障不会影响主节点的读写。为了减少复制数据，复制集中还可以添加仲裁节点（Arbiter），仲裁节点参与主节点的选举，但不从主节点复制数据。
复制集中的节点每隔2秒会向复制集中的其它节点发出心跳请求（Hearbeat），以检测和维护复制集。MongoDB复制集中有一个重要的概念是多数集（Majority），指的是复制集中超过50%的节点构成的集合。当复制集中的节点或网络发生故障时，如果多数集中没有主节点了，将在多数集中选举新的主节点，同时不在多数集中的主节点将被降级为副节点。为了保持超过50%的节点，复制集中的节点数一般为奇数，而最小复制集由3个节点组成。
关于数据一致性
MongoDB规定，只有当数据被复制到多数集以后，一个写操作才能被认为提交成功。发生故障导致没有被复制到多数集的数据将被回滚。这样就存在一种可能性，程序写入数据时正常返回了，但因没有复制到多数集，后续被回滚掉了。MongoDB提供了接口可以细粒度的控制复制集的读写，可以在写入关键数据时设置数据被复制到多数集后再返回，可以避免这个问题。
水平分区——MongoDB的可扩展架构
水平分区（Sharding）指的是将数据库分为更小块，以支持更大量的数据量存储和负载。MongoDB提供了对水平分区的支持，对于应用是透明的，即应用可以向访问单个MongoDB数据库一样访问一个MongoDB分区集群（Sharded Cluster）,如图，MongoDB分区集群由以下的组件构成：
- 分区（Shards)：存储应用数据的MongoDB进程。在分区集群中，应用不直接连接到分区。
- mongos路由器（router）：按照分区元数据将应用的操作路由到分区。为了提高效率，路由器中缓存了分区元数据。
- 配置服务器（Config server）：持久化存储分区集群的元数据，包括哪些数据子集归属于哪个分区。
最小高可用部署
为了保持MongoDB的高可用性，一个最小的分区集群环境需要四台服务器，如下图所示：
最小高可用+容灾部署
为了支持容灾，数据应当至少复制到一个异地的数据中心，如图所示，在增加容灾需求以后，部署一个最小的分区集群至少需要六台服务器：
分区键的选择
在一个MongoDB分区集群上创建一个新的数据库时，新数据库会被分配到一个分区中，而不会自动水平扩展到整个分区集群。需要配置允许对数据库上的集合分区，并为集合设置分区键(Shard Key)，才能达到分布式存储的效果。分区键一旦选择则无法修改，而不当的选择分区键，可能引起集群存储或负载不均衡、查询效率低等问题，因此要在规划时合理的选择分区键。
MongoDB的水平分区是基于分区键的范围的，当DBA设置了集合的分区键以后，MongoDB按照分区键自动将集合划分为数据大块（Chunk）,划分时是基于值范围的，如Abbot->Dayton分为一个大块，Dayton->Harris分为一个大块。随着数据的增多，（默认大块大于64MB时）MongoDB会将一个大块切分为两个大块，MongoDB也会将大块从大块数量较多的分区迁移到数量较少的分区，以保持整个分区集群的平衡。
下面来结合两个具体的例子看看如何选择分区键：
例1：有一个数据集合中存储了用户的Office文档，每个用户都有唯一的userId。首先的想法是使用mongodb文档的_id作为分区键，_id是全局唯一的，可以避免产生无法分割的大块问题，但_id是一个递增序列，缺点是因分区是基于范围的，写操作将集中于最后的一个大块，会造成集群的负载不均衡；用户的userId是查找用户文档时的常用条件，也是一个分区键的候选，但以userId为分区键时，如果一个用户存储了大量的文档（如超过10GB），这些文档因分区键userId相同只能存在于一个分区，会造成集群的存储不均衡。在这个案例中，使用userId+_id的组合分区键是一个理想的选择，可以对前两个方案取长补短。
例2：有一个数据集合中存储了用户的邮件，邮件有一个发件人，一致多个收件人。可以发件人的userId来作为分区键，但是在收件人收邮件时，需要查找所有的分区以找到收件人的所有邮件。反之，也可以以收件人的userId来作为分区键，但是需要为每一位收件人复制一份邮件的副本，会影响写的速度并消耗更多的存储。在这个案例中，因为接收邮件比发送邮件是更高频的场景，较理想方案是使用收件人的userId来作为分区键。
强调一点，即使使用了合理的分区键，也要为查询创建适当的索引，分区键不能代替索引提供的能力。
参考资料
1. https://www.mongodb.com/mongodb-architecture
2. https://www.safaribooksonline.com/library/view/mongodb-in-action/9781617291609/