后端存储实战课
李玥
美团高级技术专家
44005 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语 (1讲)
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

24 | RocksDB:不丢数据的高性能KV存储

查找过程
写入过程
分层合并机制
SSTable
Immutable MemTable
MemTable
WAL
LSM-Tree删除数据的过程
在线交易类场景
数据删除过程
读写性能
结构
写入性能优化
内存和磁盘混合存储
数据持久化
写入性能对比
不同用途
被新生代数据库广泛采用
高性能持久化KV存储
思考题
适用场景
LSM-Tree
存储结构
与Redis的比较
概述
RocksDB

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
上节课我们在讲解 CockroachDB 的时候提到过,CockroachDB 的存储引擎是一个分布式的 KV 存储集群,它用了一系列成熟的技术来解决集群问题,但是在集群的每个节点上,还需要一个单机的 KV 存储来保存数据,这个地方 CockroachDB 直接使用 RocksDB 作为它的 KV 存储引擎。
RocksDB是 Facebook 开源的一个高性能持久化 KV 存储。目前,你可能很少见到过哪个项目会直接使用 RocksDB 来保存数据,在未来,RocksDB 大概率也不会像 Redis 那样被业务系统直接使用。那我们为什么要关注它呢?
因为越来越多的新生代数据库,都不约而同地选择 RocksDB 作为它们的存储引擎。在将来,很有可能出现什么样的情况呢?我们使用的很多不同的数据库,它们背后采用的存储引擎都是 RocksDB。
我来给你举几个例子。我们上节课讲到的 CockroachDB 用到了 RocksDB 作为它的存储引擎。再说几个比较有名的,MyRocks这个开源项目,你看它这个名字就知道它是干什么的了。它在用 RocksDB 给 MySQL 做存储引擎,目的是取代现有的 InnoDB 存储引擎。并且,MySQL 的亲兄弟 MariaDB 已经接纳了 MyRocks,作为它的一个可选的存储引擎。还有大家都经常用的实时计算引擎Flink,用过的同学都知道,Flink 的 State 就是一个 KV 的存储,它使用的也是 RocksDB。还有包括 MongoDB、Cassandra 等等很多的数据库,都在开发基于 RocksDB 的存储引擎。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

RocksDB:高性能KV存储引擎 RocksDB是一种高性能的持久化KV存储引擎,被越来越多的新生代数据库采用。相较于Redis,虽然其随机读写性能略逊,但作为持久化存储引擎,RocksDB能够保证数据安全地写入磁盘,展现出与内存数据库相近的性能水平。其存储结构采用了内存和磁盘混合存储方式,利用内存提升读写性能,同时保证数据持久化。RocksDB采用LSM-Tree数据结构,使得绝大多数写入磁盘的操作都是顺序写,从而实现高性能写入。这使得RocksDB成为未来数据库存储引擎的热门选择,被诸如CockroachDB、Flink、MongoDB等知名数据库采用。 LSM-Tree如何兼顾读写性能? LSM-Tree采用了复合数据结构,包含WAL、跳表和分层有序表(SSTable)。在写入数据时,LSM-Tree首先将操作命令写入磁盘的WAL日志,然后将数据写入内存中的MemTable,最终转换成Immutable MemTable并写入磁盘文件SSTable。通过分层合并机制解决乱序问题,LSM-Tree实现了高效的数据查找。总体而言,RocksDB通过LSM-Tree数据结构实现了高性能的写入和相对不错的综合查找性能。 思考题 LSM-Tree的数据删除过程并未在文章中提及,读者可进一步了解RocksDB或LevelDB相关文档,总结LSM-Tree删除数据的过程。 RocksDB是一个高性能持久化的KV存储,通过LSM-Tree数据结构实现了高效的写入和相对不错的综合查找性能,适用于在线交易类场景。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端存储实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(22)

  • 最新
  • 精选
  • 李玥
    置顶
    Hi,我是李玥。 这里回顾一下上节课的思考题: 课后请你去看一下Raft一致性协议,然后简单总结一下,CockroachDB 是如何利用 Raft 协议实现 Range 高可用、高可靠和强一致的。 这里简单说一下Raft协议,Raft是一个分布式一致性协议,在很多分布式系统中,都使用它来保证数据强一致性。它利用复制状态机来解决多个副本数据一致的问题,保证日志复制到半数以上节点才给客户端返回成功。并且,引入了主从心跳机制,当主节点故障时,其它节点能主动发起选举,选出新的主节点。通过复制状态机、心跳和选举机制,来保证集群数据的高可用、高可靠和强一致。
    2020-04-21
    44
  • myrfy
    应该是标记删除,有墓碑的概念,被删除的条目,如果在memtable里,可以直接通过墓碑标记为删除,如果不在memtable里就插入一条新的删除记录,这两种情况都会在层级合并的时候真正发挥作用,同时WAL里通过一条额外的log记录这个删除操作。 另外感觉WAL里存储的其实就是操作指令流,和raft里面的日志完全一个概念,所以raft协议和leveldb/rocksdb的组合简直是绝配

    作者回复: 👍👍👍

    2020-04-21
    40
  • suke
    老师这个rocksdb的更新机制和mysql的innodb也差不多呀,mysql也是先写redo-log,类似于wal顺序写日志,然后更新内存,然后有另外的线程刷脏页数据,为啥rocksdb性能就这么高

    作者回复: MySQL的binlog、undolog、redolog目的都不是为了提升写入性能,而是用于支撑事务的持久性。它在写完这些log之后,还是要去磁盘上随机写来更新存储引擎中的数据。这些log并没有起到提升写入性能的作用。

    2020-05-09
    3
    17
  • seg-上海
    老师,“越是被经常读写的热数据,它在这个分层结构中就越靠上,对这样的 Key 查找就越快“,这个是怎么保证的呢,上一层满了不就自动合并并排序写到下一层了,热点数据是怎么还留在上层的呢?

    作者回复: 1. 对于经常更新的Key,它大概率在内存中,这个不用多说; 2. 对于经常读的Key,内存中也会进行缓存。

    2020-04-29
    4
    13
  • LSM-Tree 删除数据:在每条数据上增加一个删除的标志位,查询的时候判断是否已经删除,落盘的时候根据删除标志位合并数据,但是这样会浪费一些空间资源

    作者回复: 是的,基于LSM-Tree的存储系统都难免会遇到写放大的问题。

    2020-04-21
    9
  • 丁小明
    不知道我理解的对不对,也就是说key在存储里面是有可能有多份的?查询的过程是按照顺序从一个一个table中去查询,先查内存后查磁盘,但是level0不是无序的么,怎么确定查找顺序呢

    作者回复: 是的,Level 0 是无序的,所以一般Level只保存很少的几个文件。Level 0的查找顺序就是按照文件的创建顺序倒序查找,也就是从最新的向最旧的查找。

    2020-04-21
    6
  • zhang
    老师,之前研究一些用B+数进行元数据的存储系统时有这样一个疑惑。 PS我是搞CDN的,存储系统的磁盘容量比较大,大约是60T以上。 假设一个对象的平均大小是100K, 小的10几k,大的通常不超过1M (超过会分片处理),也就意味着元信息总个数是10x60M个,每个元信息大约是64个字节。已就意味着这颗B+树最小也的30G的内存。 维护一颗元数据的B+树就需要30G的内存,这个开销实在太大了。 请问在实际的数据库中是否也是将整颗B+树维护在内存中吗? 如果不是,那么它是怎么修改的呢?

    作者回复: 如果对象太多,通常的做法是,定义若干分片,把所有的对象按照一定的规则放到到分片(这个分片是数据复制的基本单位,也可以理解为存放一堆对象的容器)中。 像Redis就是把所有的Key哈希到16384个槽中,元数据只记录每个槽的信息,这样无论存放多少个Key,元数据都只有8KB。 你也可以参考一下《18 | 分布式存储:你知道对象存储是如何保存图片文件的吗?》中我们讲的“对象是如何拆分和保存的?”这一节的内容。原理是一样的。

    2020-06-26
    4
    5
  • yhh
    wal,除非每写一次操作日志都刷盘,不然应该也是会存在丢数据的可能性吧?

    作者回复: 是这样的。

    2020-05-26
    5
  • Dylan
    这篇文章才收获最多的一篇文章之一~老师应该再多加几篇类似的文章的,还没看够~

    作者回复: 希望你能有所收获

    2020-06-21
  • icyricky
    应该是和TiKV类似,删除的数据增加一个新的删除版本,等真正不用的时候 ,合并SST删除吧。。

    作者回复: 是这样的

    2020-04-21
    2
收起评论
显示
设置
留言
22
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部