编者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文由毕洪宇分享。转载请注明来自高可用架构公众号「ArchNotes」。
“2015 年 MongoDB 在年初发布了 3.0，标志一个新的里程碑，分离 Server 层和 Storage 层，并引入了 WiredTiger 存储引擎，基于此，我们也才敢再把 MongoDB 捡起来用。” 毕洪宇 存储引擎的发展MongoDB 拆分后的架构图如下 下面先从存储引擎层开始介绍一下一些改进点，现在已知支持的存储引擎包括：MMAP，WiredTiger，RocksDB，Memory 以及 Encryption 等。 MMAP 在 3.0.x 的时候依然还是默认的存储引擎，新的改进就是在并发方面，由原来的 database-level 锁转为 collection-level 锁，不过在 3.2 以后默认的存储引擎替换为 WiredTiger。 WiredTiger 应该是 MongoDB 2015 年最大的亮点了，内部架构图： 那么它有哪些比较突出的 feature 呢？ Document-level concurrency control MongoDB 早期的锁粒度是简单粗暴的，instance-level，database-level 这也是一直被吐槽的地方；有一些场景为了适应这么粗粒度锁拆了一堆数据库出来，如果没有自动化管理配合的话，运维压力非常大。而 document-level 并发控制的引入使得 MongoDB 的并发能力得到极大的释放。 这里的数据也是存多版本的，有些类似 RDBMS 中 MVCC ( multi version concurrency control )，来实现同一行的读写之间的并发访问，进一步提高系统的并发访问能力。 Compression WiredTiger 支持两种压缩方式 snappy ( 默认 ) 和 zlib； 官方的测试效果： 我们一个业务场景之前在 2.6 上，1.18 Billion 记录数占用磁盘空间 3.12 TB，而升级到 3.0.x 后空间占用降到了 270 GB，使得 PCIE/SSD 的使用更划算。 我们在 MongoDB 3.0 正式生产之前使用 YCSB 进行了简单的压测：
在压测过程中，也遇到了一些问题，比如会有短暂的 stall，以及 replication enable 后 Primary 的写入吞吐量会降低非常多，这些都是 MongoDB 在和 WiredTiger 融合后存在的一个不足之处。 WiredTiger 在 eviction，checkpoint 和 capped collection 的处理算法还在持续改善中，感兴趣的可以在 JIRA（WT-1788，SERVER-16736）上跟进。我们也在使用过程中也发现一些问题，也算是接下来对 MongoDB 2016 的一个展望。 另外，关于 WiredTiger 内部也有很多 internal 参数可以调整，这部分基本上在压测时没有调整，只是把 eviction worker min，max 都设置为 4。 RocksDB 该存储引擎是 facebook 开源的，写入强劲 NoSQL Storage ( http://rocksdb.org/ )，不过对于 MongoDB 来说是非官方 built-in 支持的存储引擎 ( https://github.com/mongodb-partners/mongo-rocks )，有朋友在测试写入性能比较野性。 但是 WiredTiger 本身也支持 LSM option (默认是 btree )，可以通过 internal 的参数在创建表时指定，我简单测了一下 LSM 方式的写入也是很强，感兴趣的朋友可以深入 benchmark 下。 不过，关于 WiredTiger 的 LSM 特性和 MongoDB 的结合还在进行中，所以现在使用是修改 undocument parameter，并且也存在比如 memory leak 的 Bug，这里只是 preview test，并没有生产环境使用。 Memory 企业版存储引擎，非开源，有些类似于 MySQL 的 memory engine，也是表级锁；这里简单提下感兴趣的朋友请参考 SERVER-1153。 复制集改进Replication protocol 在 3.2 之后改进了 Replication Election/Consensus 算法，通过配置协议版本来指定。主要改进点：
通过以上，可以进一步保证 MongoDB 的 MTTR。关于复制集另外一个改进，加入了 read concern。 Read Concern 在 3.2 之前复制集只支持 Write Concern，因此如果想做到强一致读的话只能将 Read_Preferanence 设置为 Primary，否则依然会导致 stale read。而 read concern 的引入弥补了这个不足。类似 CAP 中 W R |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
