【 TiDB 使用环境】生产环境
【 TiDB 版本】6.5
【遇到的问题：问题现象及影响】
使用DM组件进行数据同步后发现，同样的表以及同样的数据量，上游的MySQL的A表大小为900M，下游TiDB的A表为2G。 我的疑问的是TiDB的rockdb引擎不应该占用更小才对吗？整个实例的大小对比差距就更大了， 上游MySQL总共占1T，但是下游TiDB总共占2T。
是不是有什么参数需要优化的？
tidb 起码都三副本啊，占用空间肯定是更大的
2G怎么算出来的？
tidb gc设置了多久？
2G就是通过图形客户端连进去显式的。
GC是默认值，没有设置
不知道你用的什么客户端能直接显示表的大小
tidb表的大小计算，可以参考： TiDB 集群管理常见问题 | PingCAP 文档中心
如果觉得官方的不准，可以参考这个帖子： 统计表大小 - 
TiDB 技术问题 - TiDB 的问答社区 (asktug.com)
1 个赞
我是用这个方法统计的，这个SQL是不是在TiDB中不适用呢
SELECT
table_name AS ‘表名’,
table_comment AS ‘表说明’,
table_rows AS ‘记录数’,
TRUNCATE ( data_length / 1024 / 1024, 2 ) AS ‘数据容量(MB)’,
TRUNCATE ( index_length / 1024 / 1024, 2 ) AS ‘索引容量(MB)’
FROM
information_schema.TABLES
WHERE
table_schema = ‘xxx’
ORDER BY
data_length DESC,
index_length DESC;
1、从tikv_region_status里获取某个表的region 占整体region的比例
2、用这个比例和监控中的使用总大小相乘，然后在除以副本数，就是这个表占的空间大小
按照上面的方法，我是这样计算的
select count() from TIKV_REGION_STATUS where table_name=‘xxx’; // 结果:872
select count() from TIKV_REGION_STATUS; // 结果:73813
872除73813=0.01 //region占用比例
642G3=1926G //3个TiKV的总大小
19260.01 = 19.26 //3个副本的总大小
19.26除3 = 6 //就是该表单副本的大小
应该是这也理解吧？
mysql 单份数据没有高可用能力，你搭个主从那容量就 double 了
若不需要 TiDB 的三副本能力，可以把 replica 设成 1 （不建议
mysql是存了一份数据，tidb是存了三份数据
那这种方式查询出来是一份的数据量还是3份的数据量，如果平时需要统计数据量的话应该怎么统计？
做这个存储空间大小的对比测试意义是什么？tidb节点越多，单个节点上的存储空间越小。
其实这种方法也是估算，不是太准确，因为每个region的大小不一定都相等
像楼上说的，意义不大，有个大概的量就行，没有特别准确的
是想对比在TiDB在3副本的情况下，它的存储空间和MySQL的单表差距多大。 如果TiDB占用的空间大很多，那么存储成本就比较高了
三副本肯定比单副本存储空间用的多，这个应该不需要测试了。本来就是用空间换时间。
1 个赞
要达成 compaction ，启动 rocksdb 的层次压缩，是需要一堆条件的，比如数据量，版本量，配置参数等等
compaction 动作也是需要时间的，让子弹飞一会…
这样对比可能没法拿到你想要的结果，不如提出你需要的场景，让大家帮你参谋一下…
1 个赞
你这种方法是在mysql下的计算方法，既没有压缩也没有副本，tidb的话用下面这个
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
WHERE
db_name = ‘sbtest’
AND table_name IN (‘sbtest1’)
GROUP BY db_name , table_name , region_id) tabinfo
GROUP BY db_name , table_name;
-
store_size_amplification表示集群压缩比的平均值。除了使用SELECT * FROM METRICS_SCHEMA.store_size_amplification;语句进行查询以外，你还可以查看 Grafana 监控 PD - statistics balance 面板下各节点的Size amplification指标来获取该信息，集群压缩比的平均值即为所有节点的Size amplification平均值。 -
Approximate_Size表示压缩前表的单副本大小，该值为估算值，并非准确值。 -
Disk_Size表示压缩后表的大小，可根据Approximate_Size和store_size_amplification得出估算值。
我的测试是，1副本的大小和mysql上差距不大，三副本基本也就是mysql上的三倍大小。
tidb要的是横向扩展能力，肯定不会比单机mysql的存储更省空间，而是提升性能以及安全性。
1 个赞
感谢感谢。我用的那条SQL是在MySQL中统计，在TiDB中应该是不适用的。采用官方提供SQL后，统计后就小很多了。
Disk_Size值是单副本还是多副本的呢
单副本
