Rocksdb是一个kv引擎，由facebook团队基于levelDB改进而来，Rocksdb采用LSM-tree存储数据，良好的读写特性以及压缩特性使得其非常受欢迎。此外，Rocksdb引擎作为插件已经集成在facebook维护的MySQL分支，用户可以通过SQL来访问rocksDB。本文主要通过分析Rocksdb引擎的记录格式，并通过对比innodb，来让大家了解Rocksdb。Rocksdb作为一个kv引擎，用户通过put(key,value)来写入key，或者通过get(key)接口来获取value，对rocksdb本身而言，每条记录都是一个key-value。当Rocksdb作为一个存储引擎接入到MySQL时，key-value结构如何存储表中各个索引，以及如何记录中各个列的信息是本文要具体讨论的。rocksdb引擎与innodb引擎类似，也是采用索引组织表，无论是表(主键索引)还是二级索引都是以LSM tree方式组织，rocksdb记录主要包括三部分，key，value和meta三部分内容，具体见下表，然后我通过介绍一条具体记录在rocksdb引擎中的存储格式来说明问题。
rocksdb基本记录存储格式
key_size | key | value_size | value |
PK/SecKey | Columns data | SeqenceId,flag |
create table row_format(
id int not null,
c1 int,
c2 char(10) not null,
c3 char(10),
c4 varchar(10),
c5 varchar(10) not null,
c6 blob,
c7 binary(10) not null,
c8 varbinary(10)) engine=rocksdb;
insert into row_format(id,c2,c4,c5,c7) values(1,'abc','abc','efg','')
key部分：
Index_id | key |
4bytes | 8bytes |
0x7fdfa4278ea0: 0x00 0x00 0x01 0x7b 0x00 0x00 0x00 0x00
0x7fdfa4278ea8: 0x00 0x00 0x00 0x05
Index_id:索引的编号，全局唯一。
rowid:由于表没有主键，系统会产生一个bigint类型的rowid作为主键，占用8个字节，而innodb引擎的rowid占6个字节，需要注意的是rowid存储采用的大端的存储(高位存储低字节)，这里主要是为了memcompare。
Value部分：
Null-flag | ID | C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 | |
Length | 1B | 4B | ---- | 30B | ---- | 4B | 4B | ---- | 10B | ---- |
Value | 1 | abc0x20… | len+value | len+value | 1110x00… |
0x7fdfa4251e50: 0x1b 0x01 0x00 0x00 0x00 0x61 0x62 0x63
0x7fdfa4251e58: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
0x7fdfa4251e60: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
0x7fdfa4251e68: 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20
0x7fdfa4251e70: 0x20 0x20 0x20 0x03 0x61 0x62 0x63 0x03
0x7fdfa4251e78: 0x65 0x66 0x67 0x31 0x31 0x31 0x00 0x00
0x7fdfa4251e80: 0x00 0x00 0x00 0x00 0x00
说明：
- Value的最前面部分(0x1b)就是存放记录的null信息。根据记录中可以为null字段的个数，确认需要占用的字节数，如果小于8个，则只需要一个字节。例子中，c1,c3,c4,c6,c8均可以为null，因此需要5个bit，所以用1个byte表示Null-flag即可，由于插入记录中，c4不为null，则对应的bit为0，也就是0x00011011。
- 对于null，无论是定长还是非定长数据类型，都不占用真实的存储空间，只需要一个bit位来表示为null即可。
- 空串’’与null，上面提到了null需要占一个标记位，而对于’’，如果是变长字段仍然需要存储长度信息，对于定长字段，则会补全。
- 对于变长字段，比如varchar，0x03 0x61 0x62 0x63数据有len+data组成，如果数据长度小于256，len只需要占用一个byte；如果len大于255，且小于65536，则需要占用2个字节，对于longblob类型，则需要占4个字节。
- 对于定长字段，不需要存长度信息直接存储data，如果不足则补充。补充字符有点诧异，对于char类型，补充0x20，对于binary类型，补充0x00。
- 对于lob类型，比如tinyblob，blob，mediumblob，longblob，以及对应的text类型，处理策略与varchar类似，存储长度的字节数根据数据类型的范围确定，比如blob长度占用2个字节，而longblob的长度占4个字节。所以在rocksdb里面，没有innodb中所谓“溢出页”的概念。对于innodb引擎，如果blob字段内容超过768字节，多余的data存储在溢出页，页内通过20个字节指向溢出页，主要包括第一个blob页的space_id,page_no和起始偏移，如果存在多个blob页，则页与页之间通过类似的方式进行关联。具体可以参考btr0cur.h文件中关于BTR_EXTERN_xxx相关的宏定义，以及接口btr_copy_externally_stored_field_prefix_low。
- 有关value部分的存储实现可以参考rocksdb引擎接口convert_record_to_storage_format，convert_record_from_storage_format和innodb引擎接口row_mysql_store_col_in_innobase_format，row_sel_field_store_in_mysql_format。
Meta部分：
Meta部分主要是SequenceID，这个SequenceID在事务提交时产生，主要用于rocksDB实现MVCC，用于可见性判断，此外Meta中还包含flag信息，由于标示记录类型，put，delete，singleDelete等，具体而言Sequence占7个字节，flag占1个字节。
rocksdb索引格式
Rocksdb中，所有的数据都是通过索引来组织，与Innodb类似，也是索引组织表，每个索引有一个全局唯一的index_id。索引主要包括两类：主键索引和二级索引，前面介绍的记录格式，也就是主键索引的格式，包括key，value和meta三部分。二级索引也包含key，value和meta三部分，但是value中不包含任何数据，只是包含checksum信息。
主键索引
key | Value | Meta | |||
Index_id | PK | NULL标记位 | 列数据 | Checksum(可选) | SeqId,flag |
二级索引
key | Value | Meta | ||
Index_id | SecondaryKey | PK | Checksum(可选) | SeqId,flag |
对比innodb引擎(innodb_file_format=Barracuda，row_format=compact)
innodb记录格式
变长字段长度列表 | NULL标记位 | record_header | Trxid | Roll_ptr | 列数据 |
create table row_format(
id int not null,
c1 int,
c2 char(10) not null,
c3 char(10),
c4 varchar(10),
c5 varchar(10) not null,
c6 blob,
c7 binary(10) not null,
c8 varbinary(10)) engine=innodb;
insert into row_format(id,c2,c4,c5,c7) values(1,'','ab','efg','');
记录内容：
0000c0b0 00 00 03 02 0a 1b 00 00 18 ff b5 00 00 00 00 28 |...............(|
0000c0c0 00 00 00 00 01 01 03 83 00 00 01 36 01 10 80 00 |...........6....|
0000c0d0 00 01 31 32 33 34 20 20 20 20 20 20 61 62 65 66 |..1234 abef|
0000c0e0 67 31 31 31 00 00 00 00 00 00 00 00 00 00 00 00 |g111............|
说明：
1. 03 02 0a，这里存的是长度信息，所有非null的变长列信息都逆序存在一起，这里按先后顺序是c5,c4,c2,这里innodb将char(10)也当作变长字段处理了。
2. 1b存储的是null信息，与rocksdb对null处理一致。00 00 18 ff b5存储的是record-header。
3. 00 00 00 00 28 00 00 00 00 01 01 03 83 00 00 01 36 01 10， 这三部分别是rowid，trxid和roll_ptr,分别占6个字节，6个字节和7个字节。
4. 最后一部分是数据，null不占任何存储空间，与rocksdb处理类似。区别在于对于char类型的处理，innodb将字段c2类型char(10)补齐到10个字节，存储为31 32 33 34 20 20 20 20 20 20，将其作为varchar处理，记录了长度信息；而Rocksdb则是补齐到30个字节(utf8字符集)，作为char处理，不记录长度信息。
整体而言，innodb记录格式包含了record_header(记录头信息)，占5个字节，主要包括记录号(heap_no),列数目,下一条记录的位置以及是否删除等信息。rocksdb则相对简单，只有整体的value-size，以及通过Meta中flag标示记录的状态put 或者是delete。innodb将变长列长度信息集中存放在一起，使得查找任意列的代价都差不多，而rocksdb的变长列信息则是放在每列的前面，访问最后一列需要逐一计算前面的列，才能定位。此外，由于innodb引擎与rocksdb引擎由于实现MVCC的机制不同，导致innodb引擎和rocksdb引擎需要存储的额外信息也不同。Innodb实现MVCC依赖于回滚段信息，记录需要额外存储trxid和roll_ptr两个字段，分别是6个字节和7个字节(type,rsegid,pageNO,offset),其中type占一个bit位，标示insert 或者是update类型，rsegid回滚段id占7bit位，pageNo占4个字节，页内偏移占2个字节。Rocksdb实现MVCC则是依赖于SequenceID，通过SequenceID来判断记录的可见性，SequenceID占7个字节。
细节上来说，RocksDB引擎和innodb引擎在处理null，char和varchar的方式类似，但innodb对于char类型做了优化，统一作为varchar处理。另外rocksdb引擎没有对blob做特殊处理。你可能会有疑问，rocksdb不是也有block_size吗，如果设置为16k，blob数据超过16k怎么办？对于innodb而言，由于表实质是以一个个page通过B-tree组织起来的，每个page是固定大小，当记录非常大时，就需要借助溢出页，通过链接的方式关联起来。而rocksdb中block_size只是一个压缩单位，并没有严格约束，文件内容以block组织，由于文件中block可能是压缩过的，因此每个block的大小不固定，通过偏移来定位具体某个block的位置。如果遇到大的blob数据，则可能这个block比较大，记录所有数据存储在一起，不会跨block。
对于索引长度限制也有所不同，对于innodb引擎来说，索引中单列长度不能超过767个字节，而rocksdb引擎单列长度不超过2048个字节，具体可以参考max_supported_key_part_length各自的实现；整个索引的长度，rocksdb和innodb都限制在3072个字节，实际上是server层的限制，因为它们的各自限制的长度都比server层的大。具体可以参考各自max_supported_key_length的实现。
参考文档
http://dev.mysql.com/doc/refman/5.7/en/innodb-physical-record.html