开源共创，全球领先——腾讯MongoDB

主讲人：杨亚洲 •腾讯云MongoDB/WiredTiger内核PR贡献列表•MongoDB内核性能优化PR贡献举例•MongoDB官方感谢信 腾讯云MongoDB贡献列表01 腾讯云MongoDB/WiredTiger贡献列表 做为MongoDB官方合作伙伴，最近几年腾讯云MongoDB产品发展迅速，除了云服务基础服务能力不断增强之外，内核能力的提升也是产品能力和影响力提升的核心因素。除了自研内核能力给客户带来更多的服务外，我们也将自己在云上服务广大客户锁进行的技术积累，积极贡献给MongoDB/WiredTiger开源社区。 过去一年腾讯云给MongoDB内核贡献涵盖稳定性、性能、功能和可观测性等诸多方面，涉及B+tree、checkpoint、reconcile持久化、block、page锁、api、事务、wtperf性能压测、wt问题分析工具、系统诊断分析、分片路由等，贡献数总结如下: 我们的影响力 业务无缝迁移 •除了MongDB官方，腾讯云是全球唯一一家能同时对MongoDB及wiredTiger存储引擎进行深度PR贡献的外部云厂商。 •腾讯对MongoDB/wiredtiger内核贡献全球排名: top 35左右。•腾讯云是全球给MongoDB/wiredtiger存储引擎PR贡献最多的外部云厂商。•MongoDB官方连续两封感谢信表达对腾讯MongoDB的谢意。 新特性: 7个 性能优化: 10个 可观察性: 18个 Bug fix: 13个 其他: 10 性能优化PR贡献举例02 PR1：路由底座优化，性能千倍提升 问题背景 当前线上接触的真实分片集群，当单个表的路由chunks达到20W(约3-5T数据)，增量路由获取就会有200ms左右的抖动；随着数据量越来越大，路由chunks也会继续增加，抖动也会越加明显，当达到100W路由chunks(约15-25T数据)后，抖动增加到秒级。 影响 如果分片间chunk不均、chunk split或者balance的时候会引起路由版本的变化，只要mongos或者mongod检测到路由版本发生变化就会从config server获取最新的变化路由信息。获取路由过程中，只要chunk表路由过多(例如百万路由)，就会引起秒级别的业务请求抖动，即使获取很少的几个增量chunk，整个过程业务请求也会全部阻塞。影响版本：所有MongoDB分片集群内核版本。 问题现象 当一个70万路由的表获取增量变化路由的时候，慢日志中会因为刷新路由产生大量慢查，刷路由耗时如下： PR1：路由底座优化，性能千倍提升 线上真实抖动案例1 (4.0版本) 线上真实抖动案例2 (4.2版本) 数据量：55亿行，25T数据 数据量：50亿行，1.2T数据 chunk数：25万 chunk数：约150万 获取增量路由抖动程度：mongos约1200ms抖动|mongod约1500ms抖动 获取增量路由抖动程度：mongos约200ms抖动|mongod约300ms抖动 线上真实抖动案例4 (4.2版本) 线上真实抖动案例3 (3.6版本) 数据量：200亿行，30T数据 数据量：1200亿行，80T数据 chunk数：450万 chunk数：约200万 获取增量路由抖动程度：mongos约4000ms抖动|mongod约4500ms抖动 获取增量路由抖动程度：mongos约1200ms抖动|mongod约1400ms抖动 PR1：路由底座优化，性能千倍提升 服务千行百业助力业务创新 流程1：根据已有的oldChunkVector和变化的增量chunkInfo-2生成一个最新ChunkVector 性能瓶颈点: 如左图所示，假设chunkInfo-2拆分为了两个新的chunkInfo2和chunkInfo3，由于整个chunkVector是一个连续的内存，因此存在数组中chunkInfo的拷贝和移动。当vector中ChunkInfo过多，则拷贝移动耗时会很长。 PR1：路由底座优化，性能千倍提升 流程2：遍历新生成的ChunkVector，计算出每个分片的ShardVersion 性能瓶颈点: 遍历整个vector，计算每个shard的shardVersion。如果vector中路由太多，这里遍历也会非常耗时。 PR1：路由底座优化，性能千倍提升 流程3：遍历老的old vector，释放历史无用资源 性能瓶颈点: old verctor中的指针空间释放，这时候也需要遍历整个old vector，因此有一定耗时。 PR1：路由底座优化，性能千倍提升 腾讯云MongoDB路由底座优化 性能瓶颈点: 如左图所示，腾讯云采样二维排序搜索算法对chunkInfo进行二维排序。当需要修改指定增量chunkInfo时，只需要快速定位到其所在的纵向列，对该列做修改即可，从而避免整个vector的修改。 该PR(SERVER-71627)优化来着官方的感谢： PR2：WiredTiger小page压缩功能支持 问题背景 问题根因 PR(WT-12653)收益 通过深入分析，最终确认该问题是wt的一个bug，wiredtiger忽略了16K以下leaf page的压缩功能。最终，腾讯云提交PR优化，支持了16K以下page的压缩功能。 某用户在做分布式数据库选型的时候，发现MongoDB大部分场景性能不错，但是在大量随机点查场景性能没有优势，通过优化调小MongoDB存储引擎WiredTiger的leaf_page_max从32K到4K，该大量随机点查SQL性能提升一倍。 1.大量随机点查性能提升一倍。2.小leaf page磁盘占用节省3倍。 但是该优化却引入了另外一个问题，mongod节点磁盘占用增加了4倍。 更多PR优化 更多PR优化 来自MongoDB的感谢信03 来着MongoDB存储引擎团队的官方感谢信 基于腾讯云MongoDB团队对MongoDB/WiredTiger的贡献，MongoDB存储引擎团队特地给腾讯发送了两封中英文感谢信，感谢腾讯云对MongoDB社区贡献：