MongoDB 初见指南

在系统引入 MongoDB 也有几年了，一开始是由于 MySQL 中有单表记录增加太快（天天几千万条吧）容易拖慢 MySQL 的主从复制。而这类数据增加迅速的流水表，对数据一致性也没那么高要求，并且业务上也不须要关联查询它，就考虑分出去。为何是 MongoDB？刚巧遇上公司 DBA 团队引入了这个数据库，有人帮助运维，对业务团队就成了一个天然的选择。不过对于任何技术产品你若是要把它用在生产环境上，最好肯定对它的架构和运做机理有个全面的理解。

形态

MongoDB 是一种 NoSQL 数据库，它在数据存储的形态上和 MySQL 这类关系数据库有本质区别。MongoDB 存储的基本对象是 Document，因此咱们把它称为一种文档数据库，而文档的集合则组成了 Collection。与 SQL 的概念类比，Collection 对应于 Table 而 Document 对应于 Row。Document 使用一种 BSON（Binary JSON）结构来表达，JSON 你们都熟悉，像下面这样。

Document 在内部是如何存储的？每一个 Document 被保存在一个 Record 中。Record 至关于 MongoDB 内部分配的一块空间，除了保存 Document 的内容可能还会预留一些填充的额外空间。对于写入后的 Document 若是还会更新，可能致使 Document 长度增长，就能够利用上额外的填充空间来。若业务对于写入后的 Document 不会再更新或删除（像监控日志、流水记录等），能够指定无填充的 Record 分配策略，更节省空间。

了解了 Document 形态的基础上，咱们再说点针对 Document 的访问操做。新的 WiredTiger 存储引擎提供了 Document 级别的并发操做，因此并发性能有所改善。另外 MongoDB 仅对单一 Document 提供事务的 ACID 保障，若是一个操做涉及多个 Document 则不能保证事务特性。不一样的业务数据对事务一致性的要求不一样，因此应用开发者须要知道将数据放在不一样的 Document 中写入时在一致性方面可能的影响。详细的操做 API 直接看官方文档，不赘述了。

安全

这里的安全指的数据安全，安全就是说数据被安全的保存好了，不会丢失。关于 MongoDB 数据安全在早期的版本（1.x）引起了不少争论。（能够看参考[2]）

安全和效率实际上是相互制约的，越安全则效率越低，越高效则越不安全。MongoDB 的设计场景考虑的是应对大量的数据写入和查询，而数据的重要性相对没那么高。因此 MongoDB 的默认设置在安全和效率之间，更偏向效率。

咱们先看下一个 Document 被写入到 MongoDB 后它内部的处理方式。MongoDB 的 API 提供了不一样安全级别的写入选项来让使用方根据其数据性质灵活的选择。

Write To Buffer Without ACK

这个模式下 MongoDB 是不确认写请求的，Client 端调用驱动写入后若没有网络错误就认为成功，实际到底写入成功没有是不肯定的。即便网络没有问题，数据到达 MongoDB 后它先保存在内存 Buffer 中，再异步写入 Journaling 日志，这中间有 100ms（默认值） 的落盘（写入磁盘）时间窗口。通常数据库的设计都是先写 Journaling 的流水日志，随后异步再写真正的数据文件到磁盘，这个随后可能就比较长了，MongoDB 是 60 秒或者 Journaling 日志达到 2G。

Write To Buffer With ACK

这个比上一种模式稍微好一点，MongoDB 收到写入请求，先写入内存 Buffer 后回发 Ack 确认。Client 端能确保 MongoDB 收到了写入数据，但依然有短暂的 Journaling 日志落盘时差致使潜在的数据丢失可能。

Write To Journaling With ACK

这个模式确保至少写入 Journaling 日志后才回发 Ack 确认，Client 端能确保数据至少写入磁盘了，安全性较高。

Write To Replica Buffer With ACK

这个模式是针对多副本集的，为了提高数据安全性，除了及时写入磁盘也能够经过写多个副原本提高。在这个模式下，数据至少写入 2 个副本的内存 Buffer 中才回发 Ack 确认。虽然都在内存 Buffer 中，但两个实例在落盘短暂的 100ms 时差中同时故障的几率很低，因此安全性有所提高。

明白了不一样的写入模式选项，咱们才能更好的真对数据的性质选择合适的安全级别。后面效率一节咱们再分析不一样写入模式下的效率差别。

容量

在考虑 MongoDB 总体的存储容量前，先考虑做为基本单元的 Document 的容量。Document 这种 JSON 形态天生会带来数据存储冗余，主要是 field 属性每一个 Document 都会保存一遍。目前 3.2 版本的 MongoDB 已经将新的 WiredTiger 做为默认存储引擎，它提供了压缩功能，有两种压缩形式：

• Snappy 默认压缩算法，在压缩率和 CPU 开销之间取得平衡。

• Zlib 更高的压缩率，但也带来更高的 CPU 开销。

而每一个 Document 依然有最大容量限制，不能无限增加下去，这个限制目前是 16MB。那么我要存大于 16MB 的文件怎么办，MongoDB 提供了 GridFS 来存储超过 16MB 大小的文件。以下图所示，一个大文件被拆分红小的 File Chunk，每一个 Chunk 大小 255KB，并存放在一个 Document 中。GridFS 使用了 2 个 Collection 来分别存放文件 Chunk 和文件元数据。

单机的容量老是受限于磁盘大小，而 MongoDB 解决方案依然是分片化。是用更多的机器来提供更大的容量，分片集群采用代理模式（《Redis 集群的合纵与连横》一文中写过这类模式），以下图。

而每一个分片上的数据又以 Chunk 的形式组织（相似于 Redis Cluster 的 Slot 概念），以便于集群内部的数据迁移和再平衡。比较容易混淆的是这里的 Chunk 不是前面 GridFS 里提到的 Chunk，它们的关系大概以下图（吐槽下，干吗要用同名的术语来表达彻底不一样的概念）。

支持水平扩展和数据再平衡功能的 MongoDB Cluster 基本上数据容量就再也不是个问题了。

效率

前面「安全」一节列举了不一样的写入模式，咱们看下在这些不一样模式下写入的效率如何。因为官方没有提供基准性能测试数据，下面的数据来自参考文献[5]一个从 2009 年开始使用 MongoDB 的专业技术公司博客分享的写入基准测试数据。我这里根据数据结果作一些分析总结，下面是测试结果数据的表格和图形展现。

• w=0, Write To Buffer Without ACK

• w=1, Write To Buffer With ACK

• j=1, Write To Journaling With ACK

• w=2, Write To Replica Buffer With ACK

测试类型多了一项将 Journaling 日志放在 SSD 和机械硬盘上的差别，这让咱们能够直观的感觉 SSD 和机械硬盘在顺序写状况下的性能差别。对于机械硬盘最大的性能制约是在磁头移动，因此 MongoDB 官方文档也建议将 Journaling 日志和数据文件放在不一样的磁盘上。保证顺序写 Journaling 日志的磁头不会被随机写数据文件影响，而数据文件的写入是经过内存 buffer 缓冲的一个异步过程，对交互性能延迟的影响不大。

根据测试结果数据看，有无 Ack 之间响应延时相差一倍，基本就是多了一个网络传输的延时等待时间。开启 Journaling 保证及时落盘，不管是 SSD 仍是机械硬盘，这个延时都上升了 2 个数量级，翻了百倍，而 SSD 的顺序写比机械硬盘平均快 3 倍。而写双副本的平均延时比我预期高了很多，应该说延时的波动很大，不像写磁盘延时最小、最大和平均的值很是接近。理论上写双副本不落盘的状况延时只应该比单一状况多一倍的网络开销外加部份程序开销，而实际测试数据显示远远高于预期并且延时波动范围大了不少。这种模式下 MongoDB 延时表现波动范围太大，不够稳定，具体究竟是实现上的缺陷仍是测试不够准确，就不得而知。并且当时测试的版本是 2.4.1 不知道最新的 3.2 版本如何，若是采用这类写模式，可模拟本身生产环境实测得出结论。

至于读取性能是无法作基准测试了，不一样的文档模型，选择不一样的查询条件，性能均可能不一样。虽然 MongoDB 是 Schemaless 的，但不意味着不须要对文档的 Schema 进行设计，不一样的 Schema 设计对性能的影响仍是很大的。

总结

面临一个新的技术产品或系统，「形态」是针对这个产品或系统最独特部分的描述，属于核心模型。而「安全」、「容量」、「效率」三个核心维度全面反应了一个技术产品或系统的不一样设计和实现考虑，可类于比机械设计中的「三视图」。对于初次面对一个新的技术产品或系统，这是一个适合的切入点来帮助作初步的技术决策，而后跟着进一步的实践测试来验证思考和理解，这样才能更好的理解和用好现有技术，作一个合格的技术拿来主义者。

参考

1] MongoDB Doc. [MongoDB Manual
2] MongoDB White Paper. [MongoDB Architecture Guide
3] 陈皓. [千万别用MongoDB？真的吗？. 2011.11
4] David Mytton. [Does everyone hate MongoDB?. 2012.09
5] David Mytton. [MongoDB Benchmarks. 2012.08
6] David Mytton. [MongoDB Schema Design Pitfalls. 2013.02

---

写点文字，画点画儿，「瞬息之间」一切都变了。以为不错，可长按或扫描二维码关注。