前沿追踪|网易云背后的数据库：Facebook开源，完全兼容MySQL( 二 ) MyRocks是完全兼容MySQL的一个关系型数

由于引入RocksDB ， MyRocks具备比MySQL（相比基于B+树的InnoDB）更多优点，如更快的写入速度，更小的存储空间，更高的压缩效率等；这是MyRocks的核心竞争力，下面简单对比说明。

存储效率高，写性能好

InnoDB是典型的B/B+树存取方式，即使是顺序插入场景，也会在一个page还未完全填满时触发分裂，变为2个半空的page ，也就是说InnoDB的page一定存在页内碎片。而RocksDB由于是追加（Append）方式，所以都是文件顺序写行为；MemTable从内存 Flush到磁盘后成为独立的sst文件，不同的sst文件间的Merge操作也是顺序读写，整个过程均不会产生内部碎片。

存储空间小

即使在非压缩模式下， RocksDB记录也进行了前缀压缩/编码，默认每16条记录才有一条是完整的，节省了后续15条记录的共同前缀所需的存储空间。此外， RocksDB每个索引占用7+1 bytes（seq id + flag）的元数据开销，而InnoDB每记录6+7 bytes （trx_id + undo ptr）空间开销，似乎在多个索引的场景下RocksDB更加费空间，但Ln SST文件seq id可置0 ，经过压缩等操作后绝大部分元数据开销是可节省的，只需占用1byte ，因此RocksDB的元数据开销也比InnoDB更省。

压缩效率高

在压缩效率方面，也是RocksDB更占据优势。 InnoDB压缩以page/block为单位来独立保持压缩后的数据，而文件系统是需要块对齐的，一般都是4KB ，这就意味着一个16KB的页，即使压缩为5KB ，也需要使用2个文件block ，即8K保存。其中的3KB空间填空。
RocksDB很好得解决了这个问题。每个block压缩后，先组合成一个SST文件，保存时只需要SST文件对齐到4KB即可。
不足
在性能上， MyRocks相比InnoDB不足之处在于查询性能（主要是范围查询），在这方面， MyRocks通过使用布隆过滤器（Bloom Filter）进行了查询优化。
相对来说， MyRocks作为一个年轻的开源项目，相比MySQL/InnoDB在成熟度上和功能完整度上有所欠缺，包括XA事务支持度不够、在线DDL性能不足且内存消耗过大、支持的索引类型偏少（无地理位置索引、全文索引等）等。此外， Bug数也更多。
【使用场景和实际效果】由于MyRocks完全兼容MySQL ，因此，对于一般的，比如读写压力都不大、只需关系型数据库基本功能的业务场景下， MyRocks是完全可以替代MySQL的，但这不是MyRocks项目的存在意义，因为带来不了多少价值。
MyRocks应该用在相比现有方案能够明显产生更多价值的场景，下面列举MyRocks典型的应用场景，并介绍在部分场景上的使用效果。
大数据量场景这类场景典型的特点是数据量大，此外可能数据增长也很快，也可能有过期删除的需求等，这类场景包括用户行为，动态等。我们曾与DBA对云音乐和考拉等业务的MySQL实例进行应用场景分析，发现这类场景的MySQL实例占有不小的比率。
MyRocks由于具备更高地压缩比，可以极大缩小数据的存储空间。降低这部分业务的存储开销。而且MyRocks支持数据TTL（Time To Live）特性，可以设定数据过期时间，更加方便进行数据生命周期管理。
目前云音乐有多个这类业务场景使用了MyRocks ，这里拿云音乐的用户历史听歌记录为例。