MongoDB World 2016参会全记录

lyhabc

本次会议举办得非常用心，演讲主题丰富，涵盖了MongoDB产品规划、内部实现、用户案例、devops、driver使用等很多内容，能满足各种不同岗位听众的需求。我目前在阿里云数据库团队主要负责MongoDB源码方面的开发工作，所以重点会放在MongoDB内部实现的部分，接下来跟大家分享下参会的一些重要内容及感悟。

MongoDB 3.4 preview

MongoDB的版本迭代非常快，我接触MongoDB还不到一年的时间，已经经历了MongoDB 3.0、3.2两个大版本，云数据库为了跟官方保持同步，已经使用了最新的3.2版本。大版本的发布，新功能改进上还是非常给力的，比如3.2相比3.0版本，重大的改进包括：

默认的存储引擎从mmapv1切换为wiredtiger，提升性能的同时也能通过压缩降低存储成本
复制集的选举使用raft协议，可靠性进一步增强
支持文档校验功能（document validation）
支持left join（$lookup）
支持in memory存储引擎（企业版），MongoDB支持复制集各成员使用不同的存储引擎，应用场景的想象空间很大
本次会议上介绍了下一个大版本3.4里的主要特性

全量同步（initial sync）改进，目前如果initial sync中间断开了，需要整个重来，改进后并行度提高，而且断开后能够接着上次的进度继续同步。
支持自定义文档排序规则（比如按ascii、utf8来排序）
只读视图（readonly view）
recursive lookup，目前只支持简单的left join
mongodb compass（企业版）在geo index、explain、crud操作上有很大的改进
bi connector功能提升（企业版）
总体看来，MongoDB还是很注重社区反馈的，像collation、只读视图的功能都是社区vote比较多的特性；企业版本支持上，3.2里只有企业版支持的功能主要包括审计日志、数据加密、mongodb compass/ops manager、bi connector，in memory存储引擎，大都是数据库外围的增值功能，放在商业版本里很能理解，但in memory存储引擎放到企业版我觉得很意外。

数据库引擎是MongoDB核心的组成部分，开发一个新的引擎很复杂的，而且引擎在各个场景下是否能表现得符合预期，不经过大量的使用验证是很难稳定的，以wiredtiger为例，wiredtiger在作为mongodb存储引擎之后，社区的各种使用案例遇到的问题也帮助wiredtiger改进了很多；希望官方能把in memory引擎放出来，让社区一起来提升它，这样MongoDB就能适应于更多场景了，比如在缓存的场景代替redis…成为真正强大的NewSQL。

MongoDB Atlas

本次大会最重量级的内容就是MongoDB Atlas Cloud Service的发布，MongoDB公司正式提供Database-as-a-service服务模式，用户可以选择在AWS（后续可能支持azure，gcp）上部署MongoDB云服务，模式跟现在的mlab类似。



Async network framework

这个主题主要介绍MongoDB 3.2异步网络框架的改造，Mongos跟Mongod的通信，典型的流程是connect ==> auth ==> [send request ==> recv response] * N ==> close，在之前的版本里整个过程是按顺序同步进行的，总体效率很低。

在3.2里实现了Async network framework，采用状态机转换的模式实现异步通信。一个线程池负责做实际的工作，并处理状态转换。请求的状态可分为『connect、auth、send、recv、close』等状态，connect状态会触发线程执行connect动作，并在连接成功的回调函数里将请求设置为auth状态，然后auth触发认证过程，成功后进入send状态，依此类推…整个过程异步化。



目前这个网络框架主要用于mongos与mongod、复制集mongod之间的通信，driver到MongoDB之间还是connection per thread的模式，跟MongoDB的工程师交流了下，这块有改进计划但不在3.4里。

Async network framework在设计实现时还考虑了代码可读性方面的问题，异步代码是非常难读的，各种回调很容易把人绕晕；MongoDB在在实现时大量使用了C++ 11的lamda表达式，尽可能将异步的代码写得『同步化』，以提升代码可读性。

Raft Protocol in MongoDB

从3.2版本起，MongoDB使用raft协议来保证一致性，这个主题思远同学在之前中文社区的Webinar也分享过，有兴趣的同学直接去看中文的PPT及视频，不做过多介绍。



Sharded cluster

这个主题主要介绍了Sharded cluster的config server从『多个独立mongod节点』演变为『复制集』后的一些设计考虑。

config server改为复制集模式后，复制集的备节点同步可能存在延时，而且primary节点还可能出现回滚（rollback）的情况，为了让所有mongos看到一样的视图，一致性的问题得重新考虑，3.2版本里引入了Read Concern的功能来解决这个问题。

mongos向config server写入时，使用默认的write concern，但读取时使用read concern majority级别，确保读取的数据已经成功写入大多数节点，这样就不会读到可能会回滚的数据了；

但光靠majority还不够，读到的数据可能不是最新的，比如3节点复制集，primary上成功更新了信息，比如chunk迁移后更新路由信息，但2个secondary还未同步，通过majority级别的read concern读取时，仍然可能读到未更新的路由信息。为了解决这个问题，在readConcern里加了一个afterOpTime的选项，指定读取的数据一定在某个时间戳以后，以确保读到最新的数据。

Testing Infrastructure

本次大会有好几个分享MongoDB内部测试相关的主题，我听了3个分享，分别讲MongoDB的持续集成测试、宕机测试、性能测试，感觉MongoDB在测试上的确做得很好，非常值得学习，总的来说就是将所有的测试『自动化』。

MongoDB使用evergreen(evergreen目前也是开源的）做持续继承测试，因为MongoDB实现上包含很多模块如replication、sharding、index等，再加上MongoDB是能在linux、windows、solaris等多个平台上运行的，测试是相当难做的。



MongoDB通过evergreen来实现自动化的持续集成测试，其自动追踪代码commit，并根据配置（哪个模块、哪个OS平台、哪些测试case）来执行测试，测试通过后，将代码提交到内部的代码仓库。绝大部分的测试工作都是在AWS机器上完成的，而且ervegreen还能弹性的控制测试需要的AWS的机器资源，以尽量降低成本。

为了保证MongoDB在异常情况下的数据可靠性，需要针对MongoDB运行的不同环境（虚拟机 or 物理机）进行断电测试，他们使用一种可编程插座来实现通过ssh的方式来自动启停服务器，以模拟断电测试环境。



性能测试（这里说的性能测试并不是说单纯测MongoDB的服务能力，目的是要发现MongoDB可能存在的性能问题，并进行优化），性能测试的基础还是『测试自动化』，多种workload持续测试，当发现性能问题后（有的问题可能要跑很久才会出现），就做case study，分析原因以及如何让问题重现，然后改进代码，重新测试…直到问题解决。

Wiretiger cache调优

wiredtiger cache的配置是个老大难的问题，社区里最近很多用户遇到持续insert场景下，cache满了之后，cache evict导致请求响应很慢，通过设置小的cache size可以缓解这个问题，所以wiredtiger的cache并不是越大越好。

wiredtiger的cache里存储解压缩后的数据，访问时如果WT cache命中，则直接读取数据；如果cache不命中，则会在OS page cache查找，再不命中则从磁盘读取。如果WT没有开启压缩、加密，则数据不会存储到WT cache里，相当于关闭了cache（这一点未实际验证过）。



对于WT cache的配置，没有明确的规则，建议如果读多写少，可以配置较大的cache size；如果写多读少，则配置较小的cache size。

存储引擎API及mongorocks

MongoDB 3.2已经支持wiredtiger、mmapv1、in-memory存储引擎，其他的一些存储引擎比如rocksdb、terakdb也对MongoDB做了适配，但没有被合到官方代码里。

MongoDB存储引擎适配工作量还是很大的，需要实现的接口挺多，还需要考虑各种可能的优化，比如wiredtiger引擎针对oplog采用特殊的删除策略来提升性能。希望存储引擎API的抽象能做得越来越好，适配起来更简单，这样才能让更多的引擎加入进来，让用户能有更多的选择。



SQL Proxy （BI Connector）

MongoDB 3.2企业版里支持bi connector来适配了多种bi分析工具如tableau等，通常这些工具都是直接使用SQL来进行数据分析，MongoDB开发了SQL proxy用于实现从sql到MongoDB的查询语言MQL的转换。



SQL里大部分操作都在MongoDB里都能找到对应操作符，重点需要解决数组字段的查询、MongoDB在实现SQL PROXY时，把数组的多个元素当做多个文档来看待（类似与$unwind操作符的工作），目前也有类似的项目做SQL到MQL的转换，如querymongo。

send_linux

转载最好写明转载出处哈·