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

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

你好,我是李玥。
上节课我们在讲解 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
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端存储实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(19)

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

    作者回复: 👍👍👍

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

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

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

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

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

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

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

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

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

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

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

    作者回复: 是这样的。

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

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

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

    作者回复: 是这样的

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