24 | RocksDB:不丢数据的高性能KV存储
该思维导图由 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-2144
- myrfy应该是标记删除,有墓碑的概念,被删除的条目,如果在memtable里,可以直接通过墓碑标记为删除,如果不在memtable里就插入一条新的删除记录,这两种情况都会在层级合并的时候真正发挥作用,同时WAL里通过一条额外的log记录这个删除操作。 另外感觉WAL里存储的其实就是操作指令流,和raft里面的日志完全一个概念,所以raft协议和leveldb/rocksdb的组合简直是绝配
作者回复: 👍👍👍
2020-04-2140 - suke老师这个rocksdb的更新机制和mysql的innodb也差不多呀,mysql也是先写redo-log,类似于wal顺序写日志,然后更新内存,然后有另外的线程刷脏页数据,为啥rocksdb性能就这么高
作者回复: MySQL的binlog、undolog、redolog目的都不是为了提升写入性能,而是用于支撑事务的持久性。它在写完这些log之后,还是要去磁盘上随机写来更新存储引擎中的数据。这些log并没有起到提升写入性能的作用。
2020-05-09317 - seg-上海老师,“越是被经常读写的热数据,它在这个分层结构中就越靠上,对这样的 Key 查找就越快“,这个是怎么保证的呢,上一层满了不就自动合并并排序写到下一层了,热点数据是怎么还留在上层的呢?
作者回复: 1. 对于经常更新的Key,它大概率在内存中,这个不用多说; 2. 对于经常读的Key,内存中也会进行缓存。
2020-04-29413 - 奕LSM-Tree 删除数据:在每条数据上增加一个删除的标志位,查询的时候判断是否已经删除,落盘的时候根据删除标志位合并数据,但是这样会浪费一些空间资源
作者回复: 是的,基于LSM-Tree的存储系统都难免会遇到写放大的问题。
2020-04-219 - 丁小明不知道我理解的对不对,也就是说key在存储里面是有可能有多份的?查询的过程是按照顺序从一个一个table中去查询,先查内存后查磁盘,但是level0不是无序的么,怎么确定查找顺序呢
作者回复: 是的,Level 0 是无序的,所以一般Level只保存很少的几个文件。Level 0的查找顺序就是按照文件的创建顺序倒序查找,也就是从最新的向最旧的查找。
2020-04-216 - zhang老师,之前研究一些用B+数进行元数据的存储系统时有这样一个疑惑。 PS我是搞CDN的,存储系统的磁盘容量比较大,大约是60T以上。 假设一个对象的平均大小是100K, 小的10几k,大的通常不超过1M (超过会分片处理),也就意味着元信息总个数是10x60M个,每个元信息大约是64个字节。已就意味着这颗B+树最小也的30G的内存。 维护一颗元数据的B+树就需要30G的内存,这个开销实在太大了。 请问在实际的数据库中是否也是将整颗B+树维护在内存中吗? 如果不是,那么它是怎么修改的呢?
作者回复: 如果对象太多,通常的做法是,定义若干分片,把所有的对象按照一定的规则放到到分片(这个分片是数据复制的基本单位,也可以理解为存放一堆对象的容器)中。 像Redis就是把所有的Key哈希到16384个槽中,元数据只记录每个槽的信息,这样无论存放多少个Key,元数据都只有8KB。 你也可以参考一下《18 | 分布式存储:你知道对象存储是如何保存图片文件的吗?》中我们讲的“对象是如何拆分和保存的?”这一节的内容。原理是一样的。
2020-06-2645 - yhhwal,除非每写一次操作日志都刷盘,不然应该也是会存在丢数据的可能性吧?
作者回复: 是这样的。
2020-05-265 - Dylan这篇文章才收获最多的一篇文章之一~老师应该再多加几篇类似的文章的,还没看够~
作者回复: 希望你能有所收获
2020-06-21 - icyricky应该是和TiKV类似,删除的数据增加一个新的删除版本,等真正不用的时候 ,合并SST删除吧。。
作者回复: 是这样的
2020-04-212