RocksDB基础和入门

最新推荐文章于 2025-05-09 15:25:12 发布

huangwenhuan

最新推荐文章于 2025-05-09 15:25:12 发布

阅读量803

点赞数

分类专栏： rocksdb 文章标签： db

本文链接：https://blog.youkuaiyun.com/huangwenhuan/article/details/133930248

版权

rocksdb 专栏收录该内容

1 篇文章

订阅专栏

1、简介

RocksDB是FaceBook起初作为实验性质开发的一个高效数据库软件，旨在充分实现快存上存储数据的服务能力。RocksDB是一个c++库，可以用来存储keys和values，且keys和values可以是任意的字节流，支持原子的读和写。除此外，RocksDB深度支持各种配置，可以在不同的生产环境（纯内存、Flash、hard disks or HDFS）中调优，支持不同的数据压缩算法、和生产环境debug的完善工具。 RocksDB的主要设计点是在快存和高服务压力下性能表现优越，所以该db需要充分挖掘Flash和RAM的读写速率。RocksDB需要支持高效的point lookup和range scan操作，需要支持配置各种参数在高压力的随机读、随机写或者二者流量都很大时性能调优。

1.1 架构分析

首先，任何的写入都会先写到 WAL，然后在写入 Memory Table(Memtable)。当然为了性能，也可以不写入 WAL，但这样就可能面临崩溃丢失数据的风险。Memory Table 通常是一个能支持并发写入的 skiplist，但 RocksDB 同样也支持多种不同的 skiplist，用户可以根据实际的业务场景进行选择。

当一个 Memtable 写满了之后，就会变成 immutable 的 Memtable，RocksDB 在后台会通过一个 flush 线程将这个 Memtable flush 到磁盘，生成一个 Sorted String Table(SST) 文件，放在 Level 0 层。在此期间，若出现服务故障，重启系统会从 WAL 中将数据通过 Redo 的方式恢复到 Memtable。当 Level 0 层的 SST 文件个数超过阈值之后，就会通过 Compaction 策略将其放到 Level 1 层，以此类推。如图。
在这里插入图片描述

为了定期 compact （合并压缩）数据，将 Immutable Memtable 分为多个层次。Level 0 层允许数据重复，文件间无序，文件内部有序；Level 1 ~ Level N 没有数据重复，跨层可能有重复，文件间是有序的。数据逐层愈冷，压缩程度愈高。SST 文件为每一层的主要存储方式。在 L0 文件个数达到阈值后，合并到 L1 上并依次往下刷。RocksDB 中可以配置多个线程用于对每层数据文件进行 compaction。

读取数据时，先读内存 Memtable；若不存在，则基于 SST 文件元数据查找是否缓存在 Block Cache 中；若没有被缓存，则读磁盘的 SST 文件，找到后并加载到 Block Cache 中。

整个系统的设计思路很好理解，这种设计的优势很明显，主要有以下几点:

所有的刷盘操作都采用append方式，这种方式对磁盘和SSD是相当有诱惑力的；
写操作写完WAL和Memtable就立即返回，写效率非常高。
由于最终的数据是存储在离散的SST中，SST文件的大小可以根据kv的大小自由配置，因此很适合做变长存储。

但是这种设计也带来了很多其他的问题：

为了支持批量和事务以及上电恢复操作，WAL是多个CF共享的，导致了WAL的单线程写模式，不能充分发挥高速设备的性能优势（这是相对介质讲，相对B树等其他结构还是有优势）。
读写操作都需要对Memtable进行互斥访问，在多线程并发写及读写混合的场景下容易形成瓶颈。
由于Level0层的文件是按照时间顺序刷盘的，而不是根据key的范围做划分，所以导致各个文件之间范围有重叠，再加上文件自上向下的合并，读的时候有可能需要查找level0层的多个文件及其他层的文件，这也造成了很大的读放大。尤其是当纯随机写入后，读几乎是要查询level0层的所有文件，导致了读操作的低效。
针对第三点问题，Rocksdb中依据level0层文件的个数来做前台写流控及后台合并触发，以此来平衡读写的性能。这又导致了性能抖动及不能发挥高速介质性能的问题。
合并流程难以控制，容易造成性能抖动及写放大。尤其是写放大问题，在笔者的使用过程中实际测试的写放大经常达到二十倍左右。这是不可接受的，当前我们也没有找到合适的解决办法，只是暂时采用大value分离存储的方式来将写放大尽量控制在小数据。

1.2 适用场景

对写性能要求很高，同时有较大内存来缓存SST块以提供快速读的场景；
SSD等对写放大比较敏感以及磁盘等对随机写比较敏感的场景；
需要变长kv存储的场景；
小规模元数据的存取；

1.3 不适用场景

大value的场景，需要做kv分离；
大规模数据的存取

2、High Level Architecture

RocksDB是一个嵌入式的K-V（任意字节流）存储。所有的数据在引擎中是有序存储，可以支持Get(key)、Put（Key）、Delete（Key）和NewIterator()。RocksDB的基本组成是memtable、sstfile和logfile。memtable是一种内存数据结构，写请求会先将数据写到memtable中，然后可选地写入logfile。logfile是一个顺序写的文件。当内存表溢出的时候，数据会flush到sstfile中，然后这个memtable对应的logfile也会安全地被删除。sstfile中的数据也是有序存储以方便查找。

2.1 WAL

WAL, Write Ahead Log。RocksDB 中的 DML 操作同时写入内存 Memtable 和磁盘 WAL 日志文件。当系统崩溃时，WAL 日志可以完整恢复 Memtable 中的数据，以保 WAL中的数据通过 redo 的方式恢复到 Memtable。

重要参数

 # WAL 文件的最大大小
 DBOptions::max_total_wal_size
 # WAL 文件的删除时间
 DBOptions::WAL_ttl_seconds

2.2 SST

SST, Sorted String Table，有序键值对集合，是 LSM - Tree 在磁盘中的数据结构。与 B+ Tree 就地更新不同（找到元数据所在页并修改值），LSM-Tree 直接 append 写到磁盘，再同通过合并的方式取出冗余数据。

为了加快 key 的查询速度

建立索引
布隆过滤器（Bloom Filter）：判断某个字符串一定不在该集合，若该字符串存在，可能有误差。
- 原理：位图 + N 个哈希算法。key 经过 N 个哈希后，若对应的位图是 0，则 key 不存在
- 场景限制：不支持删除 key，而 SST 本身不会被修改，所以可以使用。

SST 文件格式

Footer：程序启动位置，存储 IndexBlock 和 MetaIndexBlock 的位置
IndexBlock：存储 DataBlock 的位置
MetaIndexBlock：存储了过滤元数据、属性信息、压缩字典索引的位置
DataBlock：存储有序的数据记录

2.3 BlockCache

背景：内核 page cache 不可定制。因此，用户可以在内存中指定 RocksDB 缓存块，传一个 Cache 对象给 RocksDB 实例。一个缓存对象可以在同一个进程的多个 RocksDB 实例之间共享。块缓存存储未压缩过的块，也可以设置块缓存去存储压缩后的块。

RocksDB 两种类型的缓存都通过分片来减轻锁冲突，容量被平均分配到每个分片，分片间不共享空间。默认情况下，每个缓存会被分成 64 个分片，每个分片至少 512 B。

默认情况下，索引和过滤块都在 BlockCache 外面存储，用户可以选择将它们缓存在 BlockCache 中；

LRUCache：基于 LRU 算法，lru 列表 + 哈希表。
ClockCache：基于 Clock 算法，clock 指针 + 环形列表 + 哈希表。

与 LRU 缓存比较，Clock 缓存有更好的锁粒度。LRU 缓存读取数据时，需要对所有分片加互斥锁，因为需要更新的 LRU 列表；而在 Clock 缓存上读取数据时，不需要申请该分片的互斥锁，只需要搜索并行的哈希表。只有在插入的时候需要每个分片的锁，锁粒度更小。因此，一定环境下，Clock 缓存性能更好。

3、Features

Column Families

RocksDB支持将一个数据库实例分片为多个列族。每个DB新建时默认带一个名为"default"的列族，如果一个操作没有携带列族信息，则默认使用这个列族。如果WAL开启，当实例crash再恢复时，RocksDB可以保证用户一个一致性的视图。通过WriteBatch API，可以实现跨列族操作的原子性。

Updates

Put 接口可以把一对k-v数据写入DB，如果k已经存在的话，则已有的v会被新的v覆盖。Write接口可以实现将多个k-v对写入DB，RockdDB可以保证要么所有的k-v对都写入DB，要么一个都不写入。同理，不管哪个k在DB中已经存在，旧值都会被覆盖。

Gets、Iterators、Snapshots

RocksDB中的key和value完全是byte stream，key和value的大小没有任何限制。Get接口提供用户一种从DB中查询key对应value的方法，MultiGet提供批量查询功能。DB中的所有数据都是按照key有序存储，其中key的compare方法可以用户自定义。Iterator方法提供用户RangeScan功能，首先seek到一个特定的key，然后从这个点开始遍历。Iterator也可以实现RangeScan的逆序遍历，当执行Iterator时，用户看到的是一个时间点的一致性视图。Snapshot接口可以创建数据库在某一个时间点的快照。Get和Iterator接口也可以执行在某一个Snapshot上。某种意义上，Iterator和Snapshot提供了DB在某个时间点的一个一致性视图，但是其实现原理却不一样。快速短期/前台的scan操作比较适合用Iterator，长期/后台操作适合用Snapshot。当使用Iterator时，会对数据库相应时间点的所有底层文件增加引用计数，直到Iterator结束或者释放了引用计数后，这些文件才允许被删除。Snapshot不关注数据文件是否被删除的问题，Compation进程会感知Snapshot的存在，会保证对应视图的数据不会被删除。当实例重启时，Snapshot会丢失，这是因为RocksDB不会持久化Snapshot相关数据。

Transations

RocksDB提供了多个操作的事务性，支持悲观和乐观模式。

Prefix Iterator

大部分的LSM引擎都不支持高效的RangeScan操作，这是由于执行RangeScan操作时都要访问所有的数据文件导致。但是大部分用户并不仅仅是完全scan所有的数据，相反，很多情况下仅仅需要按照key的前缀字符串区遍历。RocksDB根据这些应用场景，优化了对应的底层实现。用户可以prefix_extractor来声明一个key_prefix，然后RocksDB为每一个key_prefix存储相应的blooms。配置了key_prefix的Iterator操作可以通过对应的bloom bits来避免检索不含有特定key prefix的数据文件，依次可以提高Iterator性能。

Persistence

RocksDB有事物日志，所有的写操作首先写入内存表内，然后可选地写入到事物日志中。当DB重启时会重新执行事物日志中的所有操作，然后恢复到特定的数据状态。事物日志数据可以与DB数据文件配置成不同的目录下，这种情况适用于将数据文件写到一致性、性能高的快存中，同时可以将事物日志保存在读写性能相对比较慢的持久化存储上来保证数据的安全性。当写数据时可以配置WriteOption,来支持是否将写操作记录在事物日志中或者当用户执行commit时是否需要执行事物日志记录的sync操作。

Fault Torlerance

RocksDB通过checksum来检测磁盘数据损坏。每个sst file的数据块（4k-128k）都有相应的checksum值。写入存储的数据块内容不允许被修改。

Multi-Threaded Compactions

当用户重复写入一个key时，在DB中会存在这个key的多个value，compaction操作就是来删除这个key的冗余数据。当一个key被删除时，compation也可以用来真正执行这个底层数据的删除工作，如果用户配置合适的话，compation操作可以多线程执行。DB的数据都存储在sstfile中，当内存表的数据满的时候，会将内存数据（去重、删除无效数据后）写入到L0 文件中。每隔一段时间小文件中的数据会重新merge到更大的文件中，这就是compation。LSM引擎的写吞吐直接依赖于compation的性能，特别是数据存储在SSD或者RAM的情况。RocksDB也支持多线程并行compaction。

Avoiding Stalls

后台的compaction线程用来将内存数据flush到存储，当所有的后台线程都正在执行compaction时，瞬时大量写操作会很快将内存表写满，这就会引起写停顿。可以配置少一些的线程用于执行数据flush操作，

Full Backups, Incremental Backups and Replication

RocksDB支持增量备份，增量复制需要能够查找到所有的DB修改记录。GetUpdatesSince接口可以提供tail DB transction log的功能。RocksDB的tranction log记录在数据库目录中，当日志文件不再需要时就会move到归档目录。归档目录之所以存在是因为数据复制流比较落后时有可能需要检索过去某一个时间点的日志。GetSortedWalFiles可以返回所有的transction log文件列表。

Block Cache – Compressed and Uncompressed Data

RocksDB使用LRU cache提供block的读服务。block cache partition为两个独立的cache，其中一块可以cache未压缩RAM数据，另一块cache 压缩RAM数据。如果压缩cache配置打开的话，用户一般会开启direct io，以避免OS的也缓存重新cache相同的压缩数据。