TiKV 空间占用的常见问题

TiKV 的空间放大

• 监控上显示的 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 文件大小。这里没有考虑索引的大小)

• TiDB 文档和配置中提到的 GC 是什么意思?

TiDB 采用 MVCC 事务模型，并且支持了 Snapshot Isolation 级别的事务隔离，因此为了保证正在进行中的事务能够读取到一致的数据，所有的 DELETE 以及 UPDATE 操作在 TiDB 中都不会立刻将原来的数据在物理上删除或者更改，而是为其新增一个版本，这样就保证了旧的版本仍然能被尚未结束的事务读取到。 每隔一段时间 TiDB 会确认某个时间点之前的事务已经全部结束了，那么所有的数据在该时间点之前的版本都可以只保留最新的那一个，于是 TiDB 会将这个 时间点通知给 TiKV，TiKV 则会发起清理旧版本数据以回收物理空间的操作，这个操作被称作 GC。

• 为什么我执行了 UPDATE SQL 之后，集群占用的空间在不停地增长？ UPDATE 的数据会占用额外的空间吗？

参见上一条，对于 UPDATE 的数据不会立刻覆盖其原有的数据，而是为其新增一个版本，因此会占用额外的物理空间。 TiDB 默认的 tikv_gc_life_ti