【MySQL】MyRocks 漫谈
一 前言
最近一两年，数据库技术尤其是MySQL方面的发展可谓百花齐放，TokuDB，MyRocks ，MySQL 5.7 GA,MySQL 8.0 doc release 其软件也在开发当中，ALiSQL 开源。其中有功能上的改进的，也有针对Innodb 本身缺陷(主要是存储空间方面的)做优化的，作为数据库技术方面的从业者多少有些应接不暇。结合今年ACMUG 技术大会上的技术分享，Percona官方对MyRocks的表态，阿里在技术上的研究，落地来看，可以明显感觉到Myrocks是一种发展趋势。本文将对MyRocks做一个简单的了解。
二 MyRocks 是什么
MyRocks是FB基于levelDB(使用LSM 组织数据结构)开发并且开源出来的数据库存储引擎，支持通用的MySQL 读写,锁机制,MVCC,事务(目前仅支持RR,RC)，主从复制。目前已经在FB的用户中心使用。
三 MyRocks 解决什么问题
这需要先从FB的业务模式来说，fb 作为全球最大的sns网站，其数据量巨大，需要存储数据的服务器想必也是数十万或者百万级别的，这些都是money。(同样也适用于阿里，腾讯这样体量的公司)为了应对未来存储空间的增长和节约服务器，fb开发了此款存储引擎。为啥Innodb 不满足需求呢? 熟悉Innodb存储引擎的朋友知道Innodb是基于B+Tree 实现的数据存储，其默认的数据块大小是16k，目前支持可调节的block_size. 但是依然存在如下问题：
1 写入放大.
B*tree要修改数据时，就需要将新入数据下面的数据重新排位，特别是当写入的数据排在较高的位置时，需要大量的移位操作才能完成写入。而且InnoDB 读写访问数据的最小逻辑单位是数据块,随机写的情况下，修改N行，可能要修改N个数据块。
MyRocks的写操作以append only的方式。根据LSM Tree的算法，其将随机写转化为顺序写，写操作只需更新内存，内存中的数据以块数据形式刷到磁盘，是顺序的IO操作，另外磁盘文件定期的合并操作，也将带来磁盘IO操作。
具体实现方式如下：
2 磁盘空间碎片
B*tree分裂导致page内有较多空闲空间，总体空间利用率不高。尽管Innodb提供压缩的方式，但是压缩以block为单位，也会造成浪费。比如总共16k的数据，压缩到5k 但是存储磁盘依然需要8k 的空间。
3 RocksDB对齐开销小:SST file (默认2MB)需要对齐，但远大于4k, RocksDB_block_size(默认4k) 不需要对齐,因此对齐浪费空间较少。
四 有哪些限制
1 MyRocks目前只支持两种隔离级别，RC和RR。
2 锁机制不健全 不支持gap lock
3 目前阶段Innodb和Myrocks 混用不稳定，Percona 在做合并的工作，ACMUG大会上的Percona工程师表示已经测试了80%的场景。
4 binlog与RocksDB之间没有xa，异常crash可能丢数据。所以，MyRocks一般开启semi-sync.
5 读性能上相对Inndb 比较弱，不支持MRR ，范围查询比较慢。
五 总结
目前而言公开在生产环境使用MyRocks存储引擎的只有FB和阿里和阿里云RDS在技术调研，相信其他同行也在做技术调研，期待未来有更多的生产实践。本文仅仅算是对Myrocks一个粗浅的认知，要掌握MyRocks，知其然，知其所以然。推荐大家去看看LSM Tree的算法
Log Structured Merge Trees(LSM) 原理 【推荐 其中的文档】
LSM Tree存储组织结构介绍
淘宝MySQL 月报 MyRocks简介
ACMUG大会MyRocks 介绍的PPT 【推荐】
最近一两年，数据库技术尤其是MySQL方面的发展可谓百花齐放，TokuDB，MyRocks ，MySQL 5.7 GA,MySQL 8.0 doc release 其软件也在开发当中，ALiSQL 开源。其中有功能上的改进的，也有针对Innodb 本身缺陷(主要是存储空间方面的)做优化的，作为数据库技术方面的从业者多少有些应接不暇。结合今年ACMUG 技术大会上的技术分享，Percona官方对MyRocks的表态，阿里在技术上的研究，落地来看，可以明显感觉到Myrocks是一种发展趋势。本文将对MyRocks做一个简单的了解。
二 MyRocks 是什么
MyRocks是FB基于levelDB(使用LSM 组织数据结构)开发并且开源出来的数据库存储引擎，支持通用的MySQL 读写,锁机制,MVCC,事务(目前仅支持RR,RC)，主从复制。目前已经在FB的用户中心使用。
三 MyRocks 解决什么问题
这需要先从FB的业务模式来说，fb 作为全球最大的sns网站，其数据量巨大，需要存储数据的服务器想必也是数十万或者百万级别的，这些都是money。(同样也适用于阿里，腾讯这样体量的公司)为了应对未来存储空间的增长和节约服务器，fb开发了此款存储引擎。为啥Innodb 不满足需求呢? 熟悉Innodb存储引擎的朋友知道Innodb是基于B+Tree 实现的数据存储，其默认的数据块大小是16k，目前支持可调节的block_size. 但是依然存在如下问题：
1 写入放大.
B*tree要修改数据时，就需要将新入数据下面的数据重新排位，特别是当写入的数据排在较高的位置时，需要大量的移位操作才能完成写入。而且InnoDB 读写访问数据的最小逻辑单位是数据块,随机写的情况下，修改N行，可能要修改N个数据块。
MyRocks的写操作以append only的方式。根据LSM Tree的算法，其将随机写转化为顺序写，写操作只需更新内存，内存中的数据以块数据形式刷到磁盘，是顺序的IO操作，另外磁盘文件定期的合并操作，也将带来磁盘IO操作。
具体实现方式如下：
- a 当有写操作(或update操作)时，写入位于内存的buffer，内存中通过某种数据结构(如skiplist)保持key有序。
- b 一般的实现也会将数据追加写到磁盘Log文件，以备必要时恢复。
- c 内存中的数据定时或按固定大小地刷到磁盘，更新操作只不断地写到内存，并不更新磁盘上已有文件。
- d 随着越来越多写操作，磁盘上积累的文件也越来越多，这些文件不可写且有序。
- e 定时对文件进行合并操作(compaction)，消除冗余数据，减少文件数量。
B*tree分裂导致page内有较多空闲空间，总体空间利用率不高。尽管Innodb提供压缩的方式，但是压缩以block为单位，也会造成浪费。比如总共16k的数据，压缩到5k 但是存储磁盘依然需要8k 的空间。
3 RocksDB对齐开销小:SST file (默认2MB)需要对齐，但远大于4k, RocksDB_block_size(默认4k) 不需要对齐,因此对齐浪费空间较少。
四 有哪些限制
1 MyRocks目前只支持两种隔离级别，RC和RR。
2 锁机制不健全 不支持gap lock
3 目前阶段Innodb和Myrocks 混用不稳定，Percona 在做合并的工作，ACMUG大会上的Percona工程师表示已经测试了80%的场景。
4 binlog与RocksDB之间没有xa，异常crash可能丢数据。所以，MyRocks一般开启semi-sync.
5 读性能上相对Inndb 比较弱，不支持MRR ，范围查询比较慢。
五 总结
目前而言公开在生产环境使用MyRocks存储引擎的只有FB和阿里和阿里云RDS在技术调研，相信其他同行也在做技术调研，期待未来有更多的生产实践。本文仅仅算是对Myrocks一个粗浅的认知，要掌握MyRocks，知其然，知其所以然。推荐大家去看看LSM Tree的算法
Log Structured Merge Trees(LSM) 原理 【推荐 其中的文档】
LSM Tree存储组织结构介绍
淘宝MySQL 月报 MyRocks简介
ACMUG大会MyRocks 介绍的PPT 【推荐】