分布式数据库 30 讲
王磊
光大银行首席数据架构师
29144 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 34 讲
结束语 (1讲)
分布式数据库 30 讲
15
15
1.0x
00:00/00:00
登录|注册

22|RUM猜想:想要读写快还是存储省?又是三选二

Delta Tree
轮转合并
宏块与微块
Pebble
TiTan
RocksDB
Leveled策略
Tiered策略
Compact操作
写操作优化
填充因子优化
写放大问题
读操作优化
加速Scan操作
Bloom Filter
TiFlash
OceanBase
TiDB和CockroachDB
LSM-Tree
B+Tree
空间负载
写负载
读负载
思考题
分布式数据库的实现
存储结构
RUM猜想
存储引擎和RUM猜想

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

你好,我是王磊。
从第 18 讲,我们开始介绍查询过程中全部重要节点的相关技术,从并行框架到查询执行引擎,再从关联运算符到行式和列式存储。今天这一讲我们面临最后的一个步骤,直接和磁盘打交道,实现最终的数据存储,这就是存储引擎。

RUM 猜想

说到数据存储,我相信很多人都有一种直觉,那就是读写两种操作的优化在很多时候是互斥的。
我们可以想一下,数据以什么形式存储,可以实现最快的写入速度?答案肯定是按照顺序写入,每次新增数据都追加在文件尾部,因为这样物理磁盘的磁头移动距离最小。
但这种方式对于读取显然是不友好的,因为没有任何有意义的数据结构做辅助,读操作必须从头到尾扫描文件。反过来,如果要实现更高效的读取,就要设计更复杂的数据结构,那么写入的速度当然就降低了,同时在存储空间上也会有额外的要求。
2016 年的一篇论文将我们这种朴素的理解提升到理论层面,这就是 RUM 猜想。RUM 猜想来自论文“Designing Access Methods: The RUM Conjecture”(Manos Athanassoulis et al.(2016)),同时被 SIGMOD 和 EDBT 收录。它说的是,对任何数据结构来说,在 Read Overhead(读)、Update Overhead(写) 和 Memory or Storage Overhead(存储) 中,同时优化两项时,需要以另一项劣化作为代价。论文用一幅图展示了常见数据结构在这三个优化方向中的位置,这里我摘录下来便于你理解。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文深入探讨了数据存储优化的相关观点,重点分析了B+Tree和LSM-Tree两种存储结构在读写存储方面的优劣。文章指出B+Tree适合读操作优化,但在面对大量随机写时会导致存储碎片化和写放大;而LSM-Tree通过将随机写转换为顺序写,提升了写入性能,但却带来了更多的写放大和空间放大。此外,文章还介绍了Leveled策略在LSM-Tree中的应用,以及分布式数据库中的存储结构实现。另外,文章还提到了OceanBase和WiscKey等存储优化的方法。最后,文章还介绍了TiDB和CockroachDB分别推出的自己的单机存储引擎TiTan和Pebble。整体来看,本文通过对比分析不同存储结构在读写存储方面的特点和适用场景,为读者提供了深入了解数据存储优化的视角。文章内容丰富,涉及了存储引擎的工程原因、存储模型的选择、以及存储优化的方法,对于对存储引擎和数据存储优化感兴趣的读者具有很高的参考价值。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式数据库 30 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(13)

  • 最新
  • 精选
  • 扩散性百万咸面包
    思考题: 使用Bloom Filter的改造版,现在不用来判断某个key是否不存在,而判断某个key的前缀是否不存在。比如说我要查300-000 到 300-999的区间,那么他们拥有共同前缀300,我只要判断这个前缀是不是在当前SSTable里即可。

    作者回复: 说的全中,点赞。

    2020-09-28
    11
  • Jxin
    课后题: 这样问,那就一定是可以了。但很遗憾,能力有限想不到。scan了的话,如果是常规的行式存储,bf起不到作用,毕竟边界不存在不等于边界内部不存在。 22讲下来的感觉: 有种搭建空中楼阁的感觉,费力还容易忘。这篇专栏前边,其实最好有篇实战做铺垫,比如tidb。两相验证虚实结合才能学得扎实。

    作者回复: 嗯,谢谢,你的建议很中肯。因为这个专栏是中立视角,希望跳出某个具体的产品,讲一些共性的、原理层面的研究进展,然后选择有代表性的产品做一些映射。这样一来,所有的内容就不能与某一款产品完全匹配,会有些抽象,但我相信后面一定会有更多分布式数据库的课程作为补充,做到虚实结合。

    2020-09-28
    2
    3
  • James
    想问下老师,就是我查一个键值对的时候,对于L1 往后的层级我是怎么找到对应的key的,我看图中画的是很多个区间,是去顺序遍历一遍这些区间,然后去对应的区间找元素吗(在区间内是通过调表算法来找元素的),还是说用二分法这类的算法来找到是哪个区间呢。PS:这个区间是可以不连续的吧(只要不重合就行),比如[a,b) [e,f]

    作者回复: 从L1开始,每层的SSTable的Key值范围是不重叠的。所以简单来说,我们会每次通过文件的区间信息锁定一个文件,也就是当前Key所在的区间,然后在文件内部查找,如果没有对应的数据则继续向L2层查找,如此逐层向下,最终找到Key的对应键值对,或者确定不存在对应数据。

    2021-01-25
    2
    2
  • kylexy_0817
    NewSQL的存储数据结构和策略和ES的十分相似。ES确实不是数据库,它不具备数据库应有的特性,例如事务等。之前的留言不严谨😄

    作者回复: :)

    2020-11-11
    1
  • licl1008
    想问一下 写放大和空间放大具体有啥区别 写得多了不是磁盘空间就占用更多了吗?

    作者回复: 写入同样数据,空间占用也会有区别。这主要和增量数据的存储模式有关,比如直接update空间就小些,而转换为delete加insert空间就大些。

    2020-09-28
    1
  • piboye
    即使不是前缀相同,范围查询也可以一个一个key去尝试,bf是内存操作,还是比磁盘快吧

    作者回复: 首先范围查询可能是无法穷举的,例如对浮点数的范围查询。另外即使可以穷举,每个都查的时间复杂度就是O(N)了,而磁盘文件是有序的,加上磁盘会做预取,可能还是磁盘快些。

    2020-09-28
    1
  • sanstyle
    L0 中的 key 是交叉的,所以读取 L0 的所有 SSTable 写入 L1,来保证 L1 开始的 SSTable 都是 key 不重叠的。 在 L1 划分边界的时候,[e, k) 里面是有交叉 key 的,重新划分为 [e, f), [f, k),怎么保证这两个 SSTable 不交叉?

    作者回复: 就是在数据誊写(也就是compact)的过程中,控制每个文件写入的数据与边界相符。

    2021-05-12
  • Jackson
    CockroachDB 也推出了自己的存储引擎 Pebble,主要目的是解决工程问题,包括解决 CGo barrier 问题和避免 Rust 功能膨胀带来的变更风险。—— Rust应该是Rocksdb吧?笔误?

    作者回复: 应该是Rocksdb,看得很仔细

    2021-04-24
  • 可怜大灰狼
    数据块里是按照顺序存储了很多条数据。我想对数据块建立一级布隆过滤器实例,这样scan定位起始和终止对应的数据块,应该能提速不少。 如果把数据块按照大小分级,类似LSM的level层那样。是不是会更快些?

    作者回复: 说的很好,点赞。

    2020-09-28
  • 有铭
    为什么RUM是个猜想而不是个定论呢?这东西第一眼看上去好像CAP理论,不过CAP已经被证明了
    2020-09-28
    4
收起评论
显示
设置
留言
13
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部