关于空间放大的咨询

watermelon_cn · 2021 年8 月 28 日 02:58

监控上显示的 Number files at each levels 是什么含义？如果用户向 TiDB 中写入了 10G 数据，那么实际占用的物理空间是多大？

TiKV 采用 LSM-Tree 架构的 RocksDB 作为底层存储引擎，最新写入的数据会在最上层，最老的数据在最底层。如果用户只执行过 INSERT 而没有 UPDATE 和 DELETE 的话，那么按照默认配置 max-bytes-for-level-multiplier ，每一层的大小是上一层的十倍。 RocksDB 相同层不会有重复的数据，再乘以三个副本，因此 10GB 数据最多占据 (512MB + 1GB + 10GB) * 3 的物理空间，由于 RocksDB 还采取了针对对 key 的前缀压缩，以及针对 block 的 LZ4 或 ZSTD 压缩，因此最终占用的磁盘空间肯定小于 33.5GB. (512MB 为L0 的 SST 文件大小。这里没有考虑索引的大小)

请问如何理解:10GB 数据最多占据 (512MB + 1GB + 10GB)
512M我的理解是level0 的容量。那后面的1G是指wal + rocksdb 内raftlog 日志吗?

hecomlilong · 2021 年8 月 29 日 05:29

首先你先要了解一下LSM-Tree的原理，是一个多层结构，就像一个树一样，上小下大，C0层在内存中，C1到Ck层在磁盘中，每一层都是一个在 key 上有序的结构，当Ci层的大小达到阈值之后，会和Ci+1层做合并，类似归并排序，这个过程就是Compaction（合并）。这就是LSM-Tree的基本原理。
那么具体到TiKV使用的RocksDB是怎么存储数据的。

根据配置，你可以大概算出10GB需要占用多少空间。
由max-bytes-for-level-base决定第一层默认最大存储512MB，第二层最大存储512MB×10，第三层最大存储512MB×10×10
因此全量的10GB会存储到第三层，根据10:1的分布规则，第二层存储了1GB，第一层为默认的512MB

`max-bytes-for-level-base`

base level (L1) 最大字节数，一般设置为 memtable 大小 4 倍。
defaultcf 默认值： "512MB"
writecf 默认值： "512MB"
lockcf 默认值： "128MB"
最小值：0
单位：KB|MB|GB

`num-levels`

RocksDB 文件最大层数。
默认值：7

`max-bytes-for-level-multiplier`

每一层的默认放大倍数。
默认值：10

以上有问题请联系。

watermelon_cn · 2021 年8 月 29 日 06:00

因此全量的10GB会存储到第三层，根据10:1的分布规则，第二层存储了1GB，第一层为默认的512MB? 这里有个疑问，如果10G数据下下来，第一层保持512M数据，第二层保存512M × 10 的数据。第三层保存应该是剩余的数据：10G-512M-512M ×10 的数据，为啥第三层会是全量10G数据

hecomlilong · 2021 年8 月 29 日 06:14

因为Ci+1层的数据是Ci层和Ci+1层合并后的结果，最后一层不一定是全量，但肯定是一个量级的，是否是全量就看是否执行了Compaction
当Ci层的大小达到阈值之后，会和Ci+1层做合并，类似归并排序，这个过程就是Compaction（合并）

watermelon_cn · 2021 年8 月 29 日 06:58

根据上面描述：写入的数据，按照层级compaction 也没造成数据放大。反而ci和ci+1合并后数据会变小

hecomlilong · 2021 年8 月 29 日 09:08

第一层包含A
第二层包含A,B
第三层包含A,B,C
对于A来说这就是写放大

watermelon_cn · 2021 年8 月 29 日 23:14

1）当第一层包含A之后compaction 后 A应该就合并到第二层，这个时候第一层的A应该没有了吧？
2）如何按照上述描述10G数据分布应该是：第一层512M，第二层5G,第三层是10G，一共占用10G+5G+512M吧？

hecomlilong · 2021 年8 月 30 日 01:36

1、先看看LSM-Tree的原理，每一层都是有重复数据的。
2、每一层和下一层会按照1:10的比例存数据。

justdoit · 2021 年12 月 27 日 09:24

请教一个比较低级的问题，使用TiKV存储，每个tikv-server应该预留多少空间用于compact，我理解全量compact的话需要50%的额外空间用于生成新的sst？

neolithic · 2021 年12 月 28 日 01:49

学习了，，好回答

watermelon_cn · 2022 年1 月 2 日 08:41

系统部署后会在tikv节点有一个临时文件，这个临时文件就是解决应急情况下tikv空间不够情况下的应急处理。

变又未变 · 2022 年2 月 14 日 02:35

你好，打扰一下，请教一下，
假设此时三层的数据，
第一层包含A
第二层包含A,B
第三层包含A,B,C
对于A来说在3层中都有了，A数据块向第二层合并时，第一层还存在的A数据块会进行压缩嘛？

watermelon_cn · 2022 年2 月 19 日 08:48

我的理解向第二层合并后第一层就没有a了

TiDBer_L3dm6WTj · 2022 年2 月 19 日 10:01

合并后第一层应该还是有a的

TiDBer_4oMELAVl · 2022 年2 月 19 日 12:23

介绍LSM Tree的资料还是很多的，比如https://zhuanlan.zhihu.com/p/98751989

变又未变 · 2022 年2 月 21 日 01:48

好的，谢谢，那段时间看了一下，向下压缩，好像主要有3种方式：
1、 size-tiered compaction，到达阈值后，将某一层的数据合并成为一个sst文件，然后放到下一层
2、 leveled compaction：选择某一层中的至少一个SST，将其数据合并到下一层与其key有交集的那些文件中
3、将上述两种的混合

system · 2022 年10 月 31 日 19:10

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。