网易云背后的数据库:Facebook开源,完全兼容MySQL( 三 )


网易云背后的数据库:Facebook开源,完全兼容MySQL

文章插图
 

网易云背后的数据库:Facebook开源,完全兼容MySQL

文章插图
 
上图为经过参数调优后的MyRocks节点性能表现,DDB1上的节点读写QPS/TPS达到1.5w/s,DDB2上的业务读QPS达到0.5w/s,读延迟大部分时间均在2ms以下,平稳度高,波动小 。
总的来说,实时推荐通过将Redis替换为MyRocks集群,在性能上扛住了业务负载的情况下有效降低了所需投入的硬件成本 。
其他适用场景依托高写入性能和低存储开销的特点,MyRocks还可作为MySQL高可用实例的低成本从库,比如防止数据误删的延迟从库(比线上数据延迟n个小时),用于数据导入的专用从库等 。目前云音乐的歌单、用户和曲库等所有P0级的MySQL核心库,均建立了延迟从库,这些节点都部署在同一个物理机服务器上,每个节点仅需5G内存,原数据量1/3以下的存储空间,如下图所示 。基于MyRocks的延迟从库以非常低的成本换来了核心业务数据更高的安全保障 。
网易云背后的数据库:Facebook开源,完全兼容MySQL

文章插图
 
除了上面所述的场景外,还有更多其他场景可以使用MyRocks,在此不一一展开说明 。
 
【使用心得】当然,MyRocks在落地使用过程并不是一帆风顺的 。在新的场景类型落地时遇到了不少问题,杭研的数据库内核团队和杭研DBA、业务开发一道为最终的推广使用做了至关重要的贡献,包括对MyRocks进行功能增强、BugFix、参数调优和使用经验输出等 。下面举例介绍 。
1.问题与优化在使用过程中,我们发现、定位和解决了数十个大大小小的问题,对MyRocks进行优化增强来满足业务需求 。先后发布了3个MyRocks内核版本,其中第一个版本将开源的MyRocks代码合入杭研MySQL分支InnoSQL中,后两个版本(v4a和v4b)均是对MyRocks的优化增强和BugFix 。
InnoSQL 5.7.20-v4a:
网易云背后的数据库:Facebook开源,完全兼容MySQL

文章插图
 
InnoSQL 5.7.20-v4b:
网易云背后的数据库:Facebook开源,完全兼容MySQL

文章插图
 
2.MyRocks XA事务增强这里要展开说的是我们为MyRocks增加了完整的XA事务处理能力,这是MyRocks想要在网易内部大规模使用所必备的能力 。因为网易众多业务均使用DDB作为MySQL分库分表的解决方案,而DDB可能会大量产生XA事务 。
开源版MyRocks仅支持执行XA事务,但不支持回放XA事务,因为XA事务PREPARE后对应Session不能执行除XA COMMIT或XA ROLLBACK外其他操作,这在主库是没有问题的,可以通过创建新的Session执行其他事务操作,但在Slave端,用于回放事务的worker线程(等同于主库的Session)是有限的 。这种情况下,也就是说如果存在XA事务,那么就无法使用MyRocks高可用实例,其原因是MySQL的XA事务复制框架与存储引擎强相关 。
网易云背后的数据库:Facebook开源,完全兼容MySQL

文章插图
 
MyRocks并没有适配这套框架,如在XA START和PREPARE时必须的detach/reattach操作等,杭研数据库内核团队参考InnoDB实现了MyRocks的XA事务相关API接口 。
除了实现API接口外,由于目前MySQL官方仅有InnoDB一个支持事务的存储引擎,所以MySQL对多存储引擎混合的XA事务支持上有较大问题,最典型的问题是多种不同原因导致的内存泄露;此外,我们发现MyRocks的XA PREPARE并未进行WAL持久化,会导致mysqld crash后数据丢失 。这些问题均通过源码级分析完成问题定位并得到了有效解决 。
3.参数调优RocksDB有数百个配置参数,其中暴露到MySQL上的有100+个 。这些参数影响了MyRocks内存使用、MyRocks性能和数据持久性等方方面面,需要根据不同的业务场景进行最优化配置 。
合理配置内存相关参数【网易云背后的数据库:Facebook开源,完全兼容MySQL】MyRocks与内存相关的参数较多,如block cache、MemTable和CF相关配置等 。设置过小可能影响写性能,设置过大可能导致OOM 。
网易云背后的数据库:Facebook开源,完全兼容MySQL

文章插图
 
在云音乐历史听歌记录场景下,我们本来采用每个用户数据表一个CF的配置方案 。由于每个CF均有独立的MemTable,会占据几百MB甚至数GB的内存空间,而该场景下每个MyRocks实例有较多数据表,出现因为MemTable占据内存过多而OOM的情况 。所以需要合理规划CF个数,每个CF的MemTable总大小由于max_write_buffer_size,max_write_buffer_number*等4个参数共同决定,其大小会影响该CF的写性能,应根据业务场景进行合理配置 。


推荐阅读