一 前言
最近一两年,数据库技术尤其是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),消除冗余数据,减少文件数量。
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 【推荐】