tkv写放大

[watermelon_cn]

• 监控上显示的 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 日志吗?

[xfworld (魔幻之翼)]

level0 的容量如果是512MB，那么 level0 就是指的 memtable (其中一个概念是level，可以简单理解成越老的数据在越高的level 【也就是数据最初写入到最低的level】)

Level 0 到 level 1 的 compaction 是一个单线程的，也就意味着这个操作其实并不快，RocksDB 后续引入了一个 max_subcompactions，解决了 level 0 到 level 1 的 compaction 多线程问题。通常，为了加速 level 0 到 level 1 的 compaction，我们会尽量保证level 0 和 level 1 有相同的 size。

当决定了 level 1 的大概 size，我们就需要决定 level multiplier。假设 level 1 的 size 是 512MB，level multiplier 是 10，整个 DB 的 size 是 500GB。Level 2 的 size 是 5GB，level 3 是 51GB，level 4 是 512GB，level 5 以及更上层的 level 就是空的。

这个假设应该可以帮助你理解空间上的描述， 后面的那 1G 指的是level 层面的空间了，

WAL 是 日志信息，会单独存放的，基本上logger 写满 memtable 就刷入数据层了，然后WAL就会被清理掉

这个是链接，可以参考学习下

看图了解RocksDB