本文由云 + 社区发表作者：磊哥
上期文章我们聊到了 redis。这期我们来说说另一个网红 nosql 数据库：MongoDB。有这么一个介绍 MongoDB 的说法是：MongoDB 是非关系数据库当中功能最丰富，最像关系数据库的。这么说是因为作为一个面向文档存储型、数据结构非常松散自由的的数据库，却拥有着丰富的功能特性如强大灵活的查询语言、支持二级索引等特性，新版本的 MongDB 甚至还支持事务。听小伙伴说 MongoDB 不仅功能丰富，而且读性能强大到远远把 MySQL 甩在后面，今天我就代替大家来动手进行一下数据库测试，揭开 MongoDB 的神秘“面纱”。
为了进行数据库对比测试，这次我购买了腾讯云 MongoDB 的主从版（1 主 2 从），同时在同样配置的云主机自建 MongoDB 作为对比。
下面给出 CentOS7 64 位上安装 MongoDB 3.6 的实践如下：
vim /etc/yum.repos.d/mongod-org.repo
编辑内容如下：
[mongodb-org]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/…$releasever/mongodb-org/3.6/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/stati…
执行指令 yum install mongodb-org - y 安装
vim /etc/mongod.conf
此处根据自己需求修改 bindIp: 0.0.0.0 #监听地址 port: 27017 #监听端口
systemctl start mongod.service #开启服务
netstat -anpt | grep 27017 #检查是否启动
服务开启后可以使用上面的指令测试服务是否启动，如果成功启动的话会看到结果如下图所示：
如果无法启动，需要根据日志分析具体原因。根据笔者的实践，大部分的原因会落在配置和权限上。如果排除错误太难，建议重新安装来的快一点。
接下来需要安装数据库测试工具，这次我们使用 YCSB，雅虎开发的一个很强大的测试工具。
在安装 YCSB 前需要安装 Java 和 Maven，测试前需要在 workloads 文件夹中创建配置文件，配置如下图所示：
考虑到购买的 mongoDB 是副本集配置，一个主节点带两个从节点，我们在本地也配置好副本集群，使用用 ./mongod –replSet amymongo –dbpath /data/27019 –port 27019 –logpath /var/log/mongodb/27019.log –fork 配置从节点，具体配置和初始化方法参考 https://cloud.tencent.com/dev…（当然部署在本机的方案不能保证高可用）
在 workloads 中防止配置文件，我们选择插入 1 千万条记录，执行 1 千万次操作，测试两种场景：read/update 9：1 和纯 insert 场景。
废话少说，下面就一起来看看测试结果吧。
场景读更新 read/update 9:1，单位 ops/sec:
场景纯写入 insert，单位 ops/sec:
场景读更新 read/update 9:1，单位 us(延时)：
场景纯写入 insert，单位 us(延时):
看来 mongodb 真的是一个高性能的数据库，为啥呢，因为 mongo 的延时单位居然是 us 微秒、微秒、微秒。。。16GB 的内存基本上 20 线程之后延时就会大大增加，在 100 线程的时候基本上延时基本在 1000us 以上，而读多场景跟写入场景相比，写入场景的性能略差一点，随着线程数的增大，写入场景的吞吐量和延时表现和读更新场景的差距会扩大。
有读者可能会有疑惑，既然数据库测试是比较云和自建，看起来差距也没有那么大，用自建好像也可以接受啊。这里我要把测试中的发现讲给大家听，听完之后大家就明白了。
第一点，笔者买的是 16G 内存的机器（流下了没有钱的泪水），测试的时候发现 cvm 的内存占用基本到了百分之 60 左右，笔者在建立副本集和加大测试数据量（购买数据量的百分之 80）之后发现，内存占用基本到了百分之 80 以上。看来 mongo 的第一个缺点，就是对内存的消耗真的非常可怕！！如果遇到高并发大数据量读写，恐怕分分钟就存在着存在着 OOM 的风险。
所以这里奉劝各位同学，如果要自建 MongoDB，还是尽量购买超大内存满足业务需求，避免在业务高峰的时候被“干掉”。如果因为跟笔者一样贫穷不想买那么大的内存，可以考虑使用云数据库，云 MongoDB 具备动态伸缩能力，即使没有买够大的内存，也完全来得及在业务高峰扩容，即使发生故障，也有完善的数据自动备份和无损恢复机制来恢复数据，在可用性上保障就高多了。
第二点，笔者在后续测试本地副本集的时候，尝试读 secondary 节点的数据，结果遇到了读延迟很高的情况。在网上研究了一下发现是因为，MongoDB 复制集里 Secondary 不断从主上批量拉取 oplog，然后在本地重放，以保证数据与 Primary 一致。这里为了防止脏读，会加一个锁阻塞所有的读请求。
所以如果遇到 Secondary 重放 oplog 占用锁时间长，读取的延时也会对应变长。这个锁最高能锁多久呢，看到有个案例锁了接近一个小时。。。看到的人内心一定是崩溃的，而在云 Mongo 测试的时候没有遇到这个情况，我想这一定是针对这个缺陷做了很大的改进，使用了其他方法实现同步。
总的来说，MongoDB 确实可以不借助其他第三方工具实现高可用和分片功能，具备的高可用的故障切换，分片可以实现数据的分部均衡，大数据量的时候通过路由实现了服务器的负载均衡。所以 MongoDB 自身的可用性较高，也难怪会在短短时间内成为流行的 nosql 数据库。
但是 MongoDB 也存在着一些坑：如对内存的占用过高、对网络的占用过高、存在从节点锁导致读几乎不可用的情况，这些情况在实际业务使用的时候会导致很严重的问题，集群宕机、服务瘫痪、数据丢失无时不刻不是覆盖在运维同学心头的阴影。这个时候云 MongoDB 几乎就是救星，弹性伸缩、随时扩容、真正安全的数据热备以及强大的专业运维架构师团队，才能真的确保业务安全无故障的运行下去。
写到这里，笔者也在思考，云数据库到底是什么，它仅仅是把数据库封装一下，改改内核，提供给使用者吗？不，云数据库应当是一整套专业服务，除了数据库之外，还有监控、安全、迁移、灾备、运维等一系列的服务提供。能让业务开发专注于业务本身，把专业的交给专业的人去做。
此文已由腾讯云 + 社区在各渠道发布
获取更多新鲜技术干货，可以关注我们腾讯云技术社区 - 云加社区官方号及知乎机构号