RocksDB数据存储格式分析

存储
RocksDB本身只是一个KV存储,用户通过put(key,value)来写入key,或者通过get(key)接口来获取value,所以单从RocksDB而言,每条记录都是一个key-value。那么当RocksDB作为一个存储引擎接入到MySQL时,key-value结构如何存储表中各个索引,以及如何记录中各个列的信息是本文要具体讨论的。

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引擎中的存储格式再做详细说明。

我们创建表,并写入数据,如下:

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','111'
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.
  • 13.

 

Key部分

由于表没有主键,所以实质是rowid:

实际数据:

index_id:索引的编号,全局唯一。

rowid:由于表没有主键,系统会产生一个bigint类型的rowid作为主键,占用8个字节,而InnoDB引擎的rowid占6个字节,需要注意的是rowid存储采用的大端的存储(高位存储低字节),这里主要是为了memcompare。

Value部分

说明:

  • 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信息。

主键索引 

二级索引

对比InnoDB引擎(innodb_file_format=Barracuda,row_format=compact)

InnoDB记录格式

我们仍然以上面的表结构来看看InnoDB的存储格式。

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,'1234','ab','efg','111'); 
  • 1.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
  • 12.

记录内容

说明

  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处理类似。

整体而言,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层的大。

 

责任编辑:武晓燕 来源: 阿里巴巴数据库技术
相关推荐

2021-12-11 08:05:12

FlinkRocksDB数据

2023-09-06 15:00:35

Pandas存储格式

2018-07-04 09:30:55

列式存储格式

2011-12-29 09:33:38

云计算云存储

2022-06-08 07:34:02

持久化数据存储原理索引存储格式

2024-12-12 09:24:28

RocksDB服务器

2022-08-31 08:04:08

Ceph配置选项

2020-03-03 13:42:08

数据存储数据存储

2024-09-03 08:40:31

2009-09-21 18:00:49

Hibernate X

2012-08-17 10:35:17

云计算存储大数据

2019-11-26 09:56:48

Python数据存储

2016-12-01 14:47:20

2010-07-09 10:42:38

HART协议

2017-07-04 10:58:57

SAN存储网络存储系统架构

2019-05-28 10:32:29

TCPUDP SYN

2011-08-29 10:55:03

SQL Server分页存储过程优化效率分

2013-05-16 10:45:46

BI云存储成本混合云

2017-08-07 09:39:52

HBase大数据存储

2015-12-15 10:51:14

软件定义存储数据中心
点赞
收藏

51CTO技术栈公众号