tikv实际使用量和通过SQL查询发现的所有库的实际大小相差甚多

ks_ops_ms · 2023 年11 月 21 日 11:01

【 TiDB 使用环境】生产环境
【 TiDB 版本】6.4.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
通过SQL查看所有数据库的大小：SELECT table_schema AS “Database”,
ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS “Size (GB)”
FROM information_schema.TABLES
GROUP BY table_schema;

每个tikv的监控情况

通过SQL查询库的大小为3.5T左右，通过tikv磁盘监控发现大概已经用了4.8T
进入tikv容器内部后发现存在db目录每个tikv大小为1.4T，其他rocksdb.info 文件每个tikv约140Gb
实际使用和当前存储相差太多

大飞哥Boil · 2023 年11 月 21 日 11:50

SQL查询所有库的大小时，得到的是数据的逻辑大小，其中包括索引、元数据和其他开销

大飞哥Boil · 2023 年11 月 21 日 11:52

TiKV的实际使用量考虑了数据占用的物理存储空间，由于压缩和其他优化，实际使用量会更小。
还会有raft 日志等信息

像风一样的男子 · 2023 年11 月 22 日 00:16

kv实际存储带压缩了，差不多三倍，加上数据存储是三副本的，就会造成就磁盘统计和sql统计差不多的情况

tidb菜鸟一只 · 2023 年11 月 22 日 00:30

SELECT
db_name,
table_name,
ROUND(SUM(total_size / cnt), 2) Approximate_Size,
ROUND(SUM(total_size / cnt / (SELECT
ROUND(AVG(VALUE), 2)
FROM
METRICS_SCHEMA.store_size_amplification
WHERE
VALUE > 0)),
2) Disk_Size
FROM
(SELECT
db_name,
table_name,
region_id,
SUM(Approximate_Size) total_size,
COUNT(*) cnt
FROM
information_schema.TIKV_REGION_STATUS
GROUP BY db_name , table_name , region_id) tabinfo
GROUP BY db_name , table_name;
这样看下

dba远航 · 2023 年11 月 22 日 00:51

TIKV的实际存储和实际数据量并不对应，包括tidb是使用空间换取写入的时间，任何DML都是以新写入数据的方式实现，再就是数据进入level 1后开始压缩。所有的这些都无法和真实数据对应起来

zhanggame1 · 2023 年11 月 22 日 01:52

tidb数据保存3个副本，并且是压缩存储，和 information_schema.TABLES看到的不同，那个是统计信息。
时间占用可以通过show table regions统计regions大小，然后按压缩比除一下

ks_ops_ms · 2023 年11 月 22 日 02:34

这个SQL看到的磁盘使用量单位并不是很清晰呀

tidb菜鸟一只 · 2023 年11 月 22 日 02:35

单位是M

ks_ops_ms · 2023 年11 月 22 日 02:42

也就是说，三个kv节点每个节点数据都是统一的，但是数据在每个kv里都是经过压缩处理的，所以比如我这边通过SQL看到的所有库的大小加一起一共3T多，但实际上经过压缩处理后只有约1.6T，体现在磁盘里

像风一样的男子 · 2023 年11 月 22 日 02:46

最准确的查询数据量的方法是通过dumpling逻辑导出数据成sql或者csv，这样没有多层级压缩也没有多副本；
其他的计算都是估算，都不是准确的。