tkv写放大

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

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就会被清理掉

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

2赞