后端存储实战课
李玥
京东零售计算存储平台部资深架构师
立即订阅
3637 人已学习
课程目录
已更新 26 讲 / 共 27 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (2讲)
开篇词 | 从今天起,换种方式学存储
免费
课前加餐 | 电商系统是如何设计的?
创业篇 (7讲)
01 | 创建和更新订单时,如何保证数据准确无误?
02 | 流量大、数据多的商品详情页系统该如何设计?
03 | 复杂而又重要的购物车系统,应该如何设计?
04 | 事务:账户余额总是对不上账,怎么办?
05 | 分布式事务:如何保证多个系统间的数据是一致的?
06 | 如何用Elasticsearch构建商品搜索系统?
07|MySQL HA:如何将“删库跑路”的损失降到最低?
高速增长篇 (7讲)
08 | 一个几乎每个系统必踩的坑儿:访问数据库超时
09 | 怎么能避免写出慢SQL?
10 | 走进黑盒:SQL是如何在数据库中执行的?
11 | MySQL如何应对高并发(一):使用缓存保护MySQL
12 | MySQL如何应对高并发(二):读写分离
13 | MySQL主从数据库同步是如何实现的?
14 | 订单数据越来越多,数据库越来越慢该怎么办?
海量数据篇 (10讲)
15 | MySQL存储海量数据的最后一招:分库分表
16 | 用Redis构建缓存集群的最佳实践有哪些?
17 | 大厂都是怎么做MySQL to Redis同步的?
18 | 分布式存储:你知道对象存储是如何保存图片文件的吗?
19 | 跨系统实时同步数据,分布式事务是唯一的解决方案吗?
20 | 如何在不停机的情况下,安全地更换数据库?
21 | 类似“点击流”这样的海量数据应该如何存储?
22 | 面对海量数据,如何才能查得更快?
23 | MySQL经常遇到的高可用、分片问题,NewSQL是如何解决的?
24 | RocksDB:不丢数据的高性能KV存储
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

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

李玥 2020-04-21
你好,我是李玥。
上节课我们在讲解 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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《后端存储实战课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 李玥 置顶
    Hi,我是李玥。

    这里回顾一下上节课的思考题:

    课后请你去看一下Raft一致性协议,然后简单总结一下,CockroachDB 是如何利用 Raft 协议实现 Range 高可用、高可靠和强一致的。

    这里简单说一下Raft协议,Raft是一个分布式一致性协议,在很多分布式系统中,都使用它来保证数据强一致性。它利用复制状态机来解决多个副本数据一致的问题,保证日志复制到半数以上节点才给客户端返回成功。并且,引入了主从心跳机制,当主节点故障时,其它节点能主动发起选举,选出新的主节点。通过复制状态机、心跳和选举机制,来保证集群数据的高可用、高可靠和强一致。
    2020-04-21
  • 丁小明
    不知道我理解的对不对,也就是说key在存储里面是有可能有多份的?查询的过程是按照顺序从一个一个table中去查询,先查内存后查磁盘,但是level0不是无序的么,怎么确定查找顺序呢
    2020-04-21
  • myrfy
    应该是标记删除,有墓碑的概念,被删除的条目,如果在memtable里,可以直接通过墓碑标记为删除,如果不在memtable里就插入一条新的删除记录,这两种情况都会在层级合并的时候真正发挥作用,同时WAL里通过一条额外的log记录这个删除操作。

    另外感觉WAL里存储的其实就是操作指令流,和raft里面的日志完全一个概念,所以raft协议和leveldb/rocksdb的组合简直是绝配
    2020-04-21
  • haijian.yang
    NewSQL 已来
    2020-04-21
  • 一步
    LSM-Tree 删除数据:在每条数据上增加一个删除的标志位,查询的时候判断是否已经删除,落盘的时候根据删除标志位合并数据,但是这样会浪费一些空间资源
    2020-04-21
  • 此方彼方Francis
    LSM的用处真广 感觉哪儿哪儿都用它的影子
    2020-04-21
  • icyricky
    应该是和TiKV类似,删除的数据增加一个新的删除版本,等真正不用的时候 ,合并SST删除吧。。
    2020-04-21
    1
  • leslie
    RMDB的瓶颈其实引发了越来越的关于数据系统的研究,老牌RMDB数据库之外现在是百花齐放,许多时候在选型方面看似简单其实已经越来越难以精准定位去选择。
    合理的选择才能真正的发挥DB的作用,这种合理性确实越来越难以轻易实现;有时觉得这个和私有云/公有云架构一样,上云看似容易,可是如何合理的选择各种相应的组件却并非易事。
    关于RockDB的删除操作其实根据老师说其写入机制时就已经说出了答案,写和删是一对逆操作;其真正的创新还是基于LSM-Tree,思路方面融合了MQ的思想-确实不一样。
    谢谢老师今天的分享,期待后续的课程。
    2020-04-20
收起评论
8
返回
顶部