前言

最开始接触MyRocks，还是因为内容处理业务线所遇到的RDS数据库存储瓶颈，RDS规格已不能支持将近2T数据的存储，我们开始寻求解决办法，最初准备迁移至物理机MySQL集群来解决所面临的问题，但考虑到数据仍在增加，处于长远角度，即使我们可以保证数据量维持在一定的水位，仍然避免不了由于大量增删改所产生的碎片所造成的大表表空间释放的问题，所以仅仅迁至物理机也并不是一个一劳永逸的选择，此时MyRocks走进了我的视野，通过与数科团队伙伴进行交流，逐步开启了传媒业务的MyRocks使用之旅。

自2019年10月开始推进MyRocks数据库在传媒后台业务推荐及落地工作，目前已经在内容处理、网易号、网易视频及新闻头条推荐几个业务线进行了部署上线，目前线上环境均已稳定运行，下面向大家介绍一下，MyRocks数据库的特性，在传媒的使用情况，以及使用MyRocks的一些限制。

2

MyRocks简介

RocksDB是FaceBook基于Google开源的LevelDB实现的一款可嵌入式的持久化键值（Key-Value）存储数据库，使用LSM（Log-Structure Merge）树来存储数据。Facebook对RocksDB进行了大量的开发，使其符合MySQL的插件式存储引擎框架的要求，移植到了MySQL上，并称之为MyRocks。MyRocks支持基于SQL的数据读写、锁机制、MVCC、事务、主从复制等MySQL绝大部分功能特性。从使用习惯考虑，使用MyRocks还是使用MySQL/Innodb并没有多大区别。

3

MyRocks适用场景

  • 写密集型业务

MyRocks采用追加的方式记录DML操作，将随机写变为顺序写，非常适合用在有批量插入和更新频繁的业务场景，上图为阿里云发布的批量插入场景下的性能对比图，相比基于InnoDB的AliSQL，MyRocks获得了近一倍的性能提升。。有不弱于KV存储系统的写入性能外，在读性能上还占据了一定的优势。

MyRocks优秀的写性能与RocksDB存储引擎的LSM-Tree(Log-Structured-MergeTree)数据存储结构是分不开的，LSM-Tree写入数据的过程，是当收到请求，先把数据记录在WAL log，保证数据存储的安全性，接着把数据写入到内存中的MemTable，此时的MemTable称之为active MemTable，当active MemTable超过一定的大小后（大小可配置），会在内存中冻结，但是可以提供读服务，此时变为immutable MemTable，也就是静态MemTable，同时为了不阻塞操作，会生成一个新的active MemTable继续提供服务， immutable MemTable数据是不会变化的，最终会刷入level0的sst文件中。

下图为RocksDB 完整的LSM-Tree图示：

  • 大数据量业务

相比Innodb，RocksDB占用更少的存储空间，还具备更高的压缩效率，非常适合大数据量的业务。

下图为网上的RocksDB和Innodb、TokuDB压缩对比数据:

说到RocksDB优秀的压缩比，对于磁盘空间贡献较大的还有它的Compaction机制，Compaction对于我们后续的MyRocks使用及运维中也充当着很重要的角色。

Compaction主要包括两类：将内存中Immutable 转储到磁盘上SST的过程称之为Flush或者Minor Compaction；磁盘上的SST文件从低层向高层转储的过程称之为Compaction或者是Major Compaction。通过Minor Compaction，内存中的数据不断地写入的磁盘，保证有足够的内存来应对新的写入；而通过Major Compaction，多层之间的SST文件的重复数据和无用的数据可以迅速减少，进而减少sst文件占用的磁盘空间。Minor Compaction类型属于Level Compaction，在Rocksdb中还有一类Compaction，称之为Univeral Compaction。Univeral Compaction由于每一次合并的文件较多，相对于Level Compaction的多层合并，写放大较小，付出的代价是空间放大较大。

Minor Compaction（Flush）、Major Compaction分别对应一组线程，在运维过程中也发现，后台的Flush、数据库重启，以及手动触发对于列族的Compaction操作，这三种操作行为在磁盘空间释放层面都有着不同程度的表现，当然，这与他们对应以上所介绍的不同Compaction方式息息相关，这里就暂不展开说明了。

  • 缓存持久化方案

由于MyRocks具有高效的空间利用率，相比Innodb，同样大小的内存可缓存更多的数据量；相比Pika等Redis替代方案，具有成熟的故障恢复机制和主从复制架构；此外其更低的复制延迟有利进行读能力扩展。因此，MyRocks也是较合适的Redis缓存替代方案。

4

MyRocks在传媒的实践

  • 内容处理业务

内容处理业务是传媒最先使用MyRocks的业务线，业务中之前使用RDS，当时的瓶颈是因为其库中大表存有longtext类型的字段且数据量较大，RDS最大规格为2T，按数据增长量，已不能满足需求，当时可供于选择的有两种解决方案，分别为MyRocks和DDB，由于内容处理业务数据库使用场景多为等值查询，最终考虑资源及DDB业务还需要在一定程度上变更使用姿势，处于符合MyRocks大数据量高压缩比及优秀的读性能，最终选择了MyRocks。

2019年10月将数据迁至MyRocks后：

  • 磁盘空间使用降低60%，目前运行1年，数据分区磁盘保持在600G，按压缩比估算，此次迁移除数据库性能有一定提升之外，磁盘空间总计节省SSD 6T。

  • 切换一个月后平均RT由0.96ms降至0.53ms

使用中也暴露出了MyRocks关于范围查询场景的一些缺陷，复杂查询的性能消耗与时效性与Innodb差距不是很大。Rocksdb 基于LSM架构的存储引擎，需要Memtable和SST内部遍历并做Merge操作 ,效率没有基于B+树的Innodb 高，涉及到执行计划代价估算问题，在某些场景下，可以通过改写SQL也会有性能的提高，比如给定范围查询的上下界，类似于oltp_read_only 场景，还需要结合具体线上业务场景以及表结构来调优。

  • 例如SQL：

Select docid,doctype,modifyTime from table where modifyTime? Limit 100;

（耗时 2.004s）

这种句式在迁移后出现性能问题，此SQL就是Range（区间）查询场景，modifyTime是有索引的，之前需要2.004s，通过更改句式优化后只需 0.051s，变更后语句为：

Select docid,doctype,modifyTime from table where modifyTime? order by modifyTime desc Limit 100;

（耗时 0.051s）

  • 网易号业务

网易号由今年7月初，业务其中某一RDS发现磁盘已接近90%，且实例规格为2T已无法扩容，综合业务特性，为网易号的报表数据库，考虑其大部分时间QPS很低，除每日OLAP类需求外，基本都是等值查询，且每日上午需要在一段时间内高速写入操作大量数据的特点，搭建MyRocks测试库，同步全量数据与开发、测试同学进行了测试工作，测试结果符合预期，后生产环境迁至MyRocks云主机集群。

7月15日迁移至MyRocks后收益：

  • 实例磁盘空间占用降低 68%，原RDS为MGR架构（三副本），节省SSD约3.5T

  • 虽说有一定的OLAP场景，但平均RT仍然由原来的2.29ms降低到2.10ms

  • 每日一次的定时任务，执行时间由100分钟降低到45分钟。通过调整并发与每个Batch操作数据的数量，充分发挥MyRocks集中写入优势，应用服务器已达到高负载的情况。


  • 网易视频业务

网易视频的需求较为简单，其数据库使用中某一RDS由于生产库表数据量较大，大部分行数上亿，而生产环境所需数据库表内数据仅为三~六月不等，由于数据量大，可能会造成平时个别SQL查询缓慢，且占用大量的磁盘空间。与业务沟通后，决定搭建MyRocks数据库作为网易视频历史库，所保留数据以备于不时的查询需求。每周一定时任务将历史数据统一由历史表归档到历史库，进行冷热数据的分离。

8月27日开始归档数据，数据迁移至MyRocks收益：

  • 生产库历史表归档之后进行了表碎片整理，RDS数据目录磁盘占用降低60%，节约磁盘成本将近1T。


  • 新闻头条推荐

推荐业务当时提出新的业务需求，基本是key-value类似的等值查询，高QPS（最终预计40-50万），低响应耗时。

有两套方案可选：

  • Redis集群

  • DDB+MyRocks

Redis集群大家并不陌生了，主要说下DDB+MyRocks方案，选用DDB主要是为了多QS（Query Server）分担高QPS压力，且可动态扩容。MyRocks主要考虑其优秀的写性能及高效的等值查询，同时也支持TTL。经过测试可以满足需求，架构如下：

2020年6月集群投入使用，目前接入业务有跟帖召回及部分文章特征:

  • RT可以满足业务需求

  • 召回及特种存储业务应用平均RT为0.65ms

  • QPS目前为4-5K，业务还在持续接入

  • 单实例磁盘使用量180G，相对比Innodb或Redis，节省了很大的硬件成本

5

使用MyRocks的一些限制

  1. 不支持分区表，Online ddl,外键，全文索引，空间索引，表空间transport

  2. gap lock支持不健全(仅primary key上支持), 使用statement方式复制会导致不一致

  3. 不支持select … in sharemode

  4. 大小写敏感，不支持*_bin collation

  5. 不支持savepoint

  6. order by比较慢

  7. 不支持MRR（Multi-Range ReadOptimization）

  8. 暂不支持O_DIRECT

  9. Innodb和RocksDB混合使用还不稳定

6

总结

相比Innodb，MyRocks占用更少的存储空间，可大大降低业务的成本，提高热点缓存效率； 具备更小的写放大比，能够更高效利用存储IO带宽； 将随机写变为顺序写，提高了写入性能，延长SSD使用寿命； 通过参数优化降低了主从复制延迟。 因此，在数据量大、写密集型等业务场景下非常适用。 此外，作为同样的MySQL写和空间优化方案，MyRocks具有更好的社区生态，适合用于替换TokuDB实例。 MyRocks高效的缓存利用率，成熟的故障恢复和主从复制机制，当然，也可以作为Redis的持久化方案。

下 图RocksDB（MyRocks）与Innodb一个比较直观的差异展示：

所以MyRocks并不是增强版的MySQL，在不同的层面表现上与Innodb以及其他数据库类型也是各有千秋，只是在不同的业务场景上，对于数据库选型为我们提供了更多的选择，各种数据库都各有特点，有它所存在的意义，没有最好的数据库，只有最适合的数据库，这就需要我们深入业务，了解业务特性，在能满足业务需求的情况下，对于性能和资源利用，找到更优的平衡点，这也正是我们所寻求的从1到1.1的宝贵变化。

- End -

作者简介

宋鹏 网易资深数据库工程师，2018年加入网易，专注于网易传媒业务相关的关系型数据库运维及优化工作。

参考文献

http://mysql.taobao.org/monthly/2017/07/05/

https://zhuanlan.zhihu.com/p/45652076

http://rocksdb.org/blog/2015/07/23/dynamic-level.html

http://rocksdb.org/blog/2016/01/29/compaction_pri.html

https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide

https://zhuanlan.zhihu.com/p/162821374

在传媒MyRocks技术实践过程中，特别感谢一下杭研数据科学内核团队技术专家温正湖，以及王刚、冯森在技术上所给予的大力支持。也特别感谢网易传媒技术部各开发团队的高度信任与精诚协作。