技能若只如初见，那么还会踩坑么?
在系统引入 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
