前沿追踪|网易云背后的数据库：Facebook开源，完全兼容MySQL( 三 )

2026-01-27

在没替换为MyRocks前，历史听歌记录为一个下挂有16个MySQL高可用实例的DDB集群。数据采用InnoDB压缩表形式存储，每个节点数据约1TB ，整个集群共32TB ，如上图所示。下图为替换为MyRocks后的情况，设置RocksDB的压缩算法为Snappy ，单个节点的数据量降为322GB ，节省了700GB 。整个集群可省下20TB SSD盘，节省了超过2/3的存储成本；由于计算资源利用率低，存储缩小后，可提高物理服务器的MyRocks实例部署密度，进一步节省计算资源；同时数据增长速度也得到控制，集群扩容周期变长。
写密集型场景这类场景的特点是数据量不小，对写性能要求超过了MySQL/InnoDB的能力，且对读的延迟和平稳性有较高要求。如果仅需高写入能力，那么可选择分布式KV系统，比如HBase ，其提供了不弱于MyRocks的写入能力，且扩展性更好。但若对读性能有较高要求，那么选择MyRocks会更好，因为基于C++实现的MyRocks没有Java的GC等问题，性能更加平稳。
如果是数据量较小，且对读写均有较高要求的场景，可采用Redis等缓存方案。但若业务场景的数据量较大，使用缓存的方案成本就会过高。
这类场景有推荐类、业务流水和日志类等等。在网易公司内部各部门均广泛存在类似的场景，目前云音乐的实时推荐、离线推荐等， NOS内部数据反查服务等均已使用MyRocks ，这里举云音乐实时推荐为例。
在本案例中主要还是关心成本。因为数据量比较大，需要大量的内存，而且随着推荐的实时化改进和推荐场景的增多，内存使用成本急剧增加，甚至可能出现内存采购来不及的情况。
显然，单个MyRocks肯定扛不住全部的压力，于是仍采用DDB+MyRocks的方式将压力拆分到多个实例上。但落到MyRocks的写入压力仍较大，虽MyRocks主库能够扛住，但由于MySQL主从复制跟不上，所以MyRocks从库延迟不断增加。由于推荐类业务对数据一致性有一定的容忍度，所以，最终落地的方案是业务层双写2个MyRocks而不是MyRocks层做主从复制。下图为当前的部署架构。
图中分左右两部分，左边为8个MyRocks节点组成的DDB1集群，右边也是8个MyRocks组成的DDB2集群，推荐算法逻辑相关的单元用Flink来表示。算法单元从DDB1读取上一周期的推荐数据，跟当前实时变化的新数据相结合计算出本周期的推荐数据，然后将其分别写入DDB1和DDB2 。推荐业务使用方从DDB2上读取所需的推荐数据。

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

推荐阅读

上一篇：放荡的人生|中国芯片半导体的转机来啦

下一篇：五花肉|将它这么做特好吃，比肉都还香南瓜别只会蒸着吃了