盘点2020 | 我要为分布式数据库mongodb在国内影响力提升及推广做点事
.背景
mongodb是一款功能完善的分布式文档数据库，在高性能、动态扩缩容、高可用、易部署、易使用、海量数据存储等方面拥有天然优势。虽然mongodb有很多优势，但是在国内缺存在不少的误解，影响力有待提升。
1.1 mongodb历年数据库得分排名
DB-Engines是一个对数据库管理系统受欢迎程度进行排名的网站，近年来，MongoDB在DB-Engines数据库流行度排行榜稳居榜单前五。在DB-Engines排名可以看出，mongodb历年得分数据呈现持续增长的趋势，具体如下图所示：
近两年得分如下：
从历年得分排名可以看出，mongodb总体趋势呈现持续增长态势，稳固了它在数据库系统中的使用优势。
1.2 mongodb roadmap：不仅仅是文档数据库
mongodb-4.2版本开始已经支持分布式事务功能，当前对外文档版本已经迭代到version-4.2.11，分布式事务功能也进一步增强。此外，从mongodb-4.4版本产品规划路线图可以看出，mongodb官方将会持续投入开发查询能力和易用性增强功能，例如union多表联合查询、索引隐藏等。mongodb产品路线图如下：
从mongodb-4.2版本分布式事务功能支持以及4.4版本roadmap规划图可以看出，mongodb后续发展会持续朝着NewSQL方向前行，预计会为用户提供更全面的数据库服务功能。
1.3 谈谈当前国内对mongodb的误解？-业务接入过程中真实感受
第1章节的mongodb排名和mongodb-4.x版本产品规划路线图可以看出mongodb在全球数据库服务系统有着重要的地位。当前，mongodb也为我司互联网系统提供了重要的数据库存储服务，支撑着每天近千万级QPS峰值读写，数万亿级数据量存储服务。
但是，在真实业务接入过程中，发现业务首次使用mongodb前，咨询最频繁的几个问题如下(通过和对应业务开发沟通得知，这些误解全来之网上，或者从其他同行听说而来)：
问题一：mongodb会不会丢数据呀，网上说mongodb会丢数据？
答：mongodb有完善的rollback及写入策略(WriteConcern)机制，除非非常极端的情况(例如主从同一时刻全挂)才可能丢数据，其他情况不会存在该问题。
我司推广mongodb过程中，我接触的业务中有收到三起反馈mongodb丢数据的情况，最后通过我们的流量审计功能，最终都分析出是业务有删数据逻辑引起。
问题二：mongodb不安全，网上说数据库被黑客攻击要挟？
答：这是DBA的锅，因为被攻击的mongodb数据库没有做鉴权认证、没有设置白名单等功能，黑客拿到IP即可攻击。而我司线上所有集群都有鉴权账号认证及白名单功能，不存在该问题。
问题三：很多运维Mysql的DBA反应mongodb很难维护？
答：针对该问题，接触了公司内部及前东家一些DBA，有些人确实有这感觉。难维护原因大概主要集中在mysql是非分布式数据库，主从结构部署，单个集群节点数有限，确实分析问题相比分布式数据库更加快速简单。mongodb是分布式数据库，部分大数据量大流量集群几十个分片，每个分片几个主从节点，分片与分片之间都是有状态的逻辑关系，所以相比mysql确实维护难度会大一点。
但是，从我自身维护mongodb集群经验(线上数千个实例，最大集群万亿级数据量)，只要掌握了mongod分片集群实现原理，个人没感觉运维有多大难度。
国内误解根因总结：
1. mongodb本身很优秀，但是很多DBA或者相应开发把控不住。
2. 国内系统性分析mongodb内核实现原理的资料较少，遇到问题无从下手。
3. 网络社会以讹传讹，DBA或者开发自身的问题演变为mongodb问题。
1.4 针对国内对mongodb的误解我能做些什么？如何做？
mongodb在我司遇到的问题应该不是个例，预计国内其他公司也会存在类似情况，正如我在Qcon演讲中说的那样，只要国内有更多的人加入mongodb实现原理研究和更多案例、踩坑等分享，mongodb国内影响力会越来越高，国内对mongodb的误解也会逐渐消失。
后续持续分享《MongoDB内核源码设计、性能优化、最佳运维实践》系列文章，该系列文章已经陆续在infoq、知乎、github分享：
2. 2020年总结
2020年即将过去，今年总体上是收获的一年，也是历份工作中最有成就感的一年，为自己加油。
2.1收获的一年：为自己点赞
2020最大的收获莫过于人力不足的情况下，凭一己之力把我司不受待见的mongodb数据库从内部淘汰边沿变为公司主流数据库。同时，也获得了更多对外分享及外部奖项，主要如下：
内部mongodb推广：从淘汰边沿变为公司主流数据库
第一期mongodb中文社区征文一等奖获得者
第二期mongodb中文社区征文一等奖
QCON全球软件开发大会分享
2020年1月mongodb年终盛会受邀分享
2021年1月mongodb年终盛会受邀分享
dbaplus受邀分享(2-3场分享，时间待定)
2.2踩坑的一年：时刻反思，转变工作方式
虽然在过去的一年中把我司mongodb从内部淘汰边沿变为了公司内部主流数据库，但是在这个过程中还是踩了很多坑，坑了自己，也坑了业务，哈哈，在此得给对应业务陪个不是。
踩坑过程主要集中在如下几个方面：
数百个业务接入过程中，出现过多次踩坑，甚至出现同一个核心业务多次抖动，还出现一次核心业务雪崩故障。之前分享了一篇雪崩故障的典型案例，如下所示：
该案例是数十个踩坑案例中的一个，后续空余时间整理其余的数十例典型踩坑案例逐步分享到社区。
虽然踩坑引起了一些不愉快，但是可以给其他同学一些借鉴，减少其他同学踩类似的坑。
3. 21年规划：继续为mongodb在国内推广及影响力提升做点事
国内真正拥有自研分布式系统的国内互联网公司主要集中在头部巨头(例如：阿里、腾讯等)，大部分公司任然忍受着Mysql分库分表的痛点。实际上随着mongodb-4.x分布式事务、联合查询等功能的支撑，很大一部分场景可以考虑采用分布式文档数据库mongodb来满足业务需求，做到快速迭代开发。
然而，由于当前国内系统性的mongodb资料文档欠缺（主要依赖官方文档满足要求）、网上以讹传讹的对mongodb的误解，造成了mongodb在国内影响力不足。此外，mongodb源码级实现细节几乎没有一本完整的书籍讲解。2021年希望能为文档数据库mongodb在国内的推广做点事，在此给自己立个小目标。
3.1 短期目标
短期目标主要是把我司数万亿级数据量mongodb业务接入过程所遇到的核心踩坑过程、性能优化案例、机房多活案例等分享到社区，避免国内其他mongodb用户踩同样的坑，这些核心踩坑点主要如下：
300条数据操作引发的血案-记一次线上300条数据变更操作引起某10亿级mongodb核心集群不可用故障。
主节点持续性OOM-记一次业务排序操作不合理使用引起的核心mongodb集群故障。
千亿级/万亿级集群最优索引添加方法-记一次数十亿级核心集群后台索引添加引起的集群抖动及快速恢复过程。
链接数耗光如何快速恢复集群-记一次百亿级核心集群链接数耗光的快速自救过程。
mongodb机房多活方案-实现成本、性能、一致性"三丰收"。
mongodb线程模型瓶颈及其优化方法。
并行迁移-集群扩容速率N倍提升优化实践。
千亿级核心元数据mongodb集群性能数倍提升优化实践。
万亿级数据量mongodb集群性能数十倍提升优化实践。
成本节省-记某服务千亿级数据迁移mongodb，百台SSD服务器节省优化实践。
如何快速完成数千亿数据从SSD高IO服务器迁移到SATA盘低IO服务器？
。。。。。。
期望完成时间：2021年4-5月
3.2 中期目标
完成Qcon、知乎、github、itpub中专栏《mongodb内核源码实现、性能调优、最佳运维实践系列》中核心文章的分享。
期望完成时间：2021年11月
3.3 年度目标
期望通过对mongodb核心内核核心技术内幕的分享整理，完成如下书籍的编写整理：
《分布式mongodb数据库内核设计与实现》
《分布式mongodb数据库最佳运维实践》
期望完成时间：2021年12月底
3.4 公司内部目标
公司自研mongodb内核深度优化，最大化解决高并发大流量、大数据量情况下的抖动问题。
快速掌握mongodb-4.2分布式事务实现原理，开始大力推广分布式事务功能。
持续分享内部推广过程中的集群踩坑、性能优化等案例到社区。
其他
期望完成时间：全年