BR备份数据的压缩算法是怎样的？

🪐 TiDB 技术问题 备份&数据迁移
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】
【遇到的问题：问题现象及影响】
https://docs.pingcap.com/zh/tidb/stable/manage-cluster-faq#如何预估-tidb-中一张表的大小

通过SQL预估的表大小Disk_Size 大小，kv是3副本

T1表预估的Approximate_Size 是1.728 TB，BR备份日志显示total-kv-size=1.626TB，备份文件实际大小是 354G，压缩比 1.57：1

[2024/05/22 21:14:36.798 +08:00] [INFO] [collector.go:68] ["Table backup success summary"] [total-ranges=54741] [ranges-succeed=54741]
[ranges-failed=0] [backup-checksum=3h16m45.789969052s] [backup-fast-checksum=10.348692ms] [backup-total-ranges=2] [backup-total-regions
=29040] [total-take=6h0m15.779606885s] [BackupTS=449934016151814145] [total-kv=5960762744] [total-kv-size=1.626TB] [average-speed=75.23
MB/s] [backup-data-size(after-compressed)=379.2GB] [Size=379162607724]

T2表预估的Approximate_Size 是3.421 TB，BR备份日志显示total-kv-size=895.9GB，备份文件实际大小是 56G，压缩比 5.33：1

[2024/05/23 14:27:35.566 +08:00] [INFO] [collector.go:68] ["Table backup success summary"] [total-ranges=24922] [ranges-succeed=24922]
[ranges-failed=0] [backup-checksum=3h21m58.473698844s] [backup-fast-checksum=4.196718ms] [backup-total-regions=49603] [backup-total-ran
ges=3] [total-take=5h2m40.229112126s] [BackupTS=449951169439596551] [total-kv=9834368130] [total-kv-size=895.9GB] [average-speed=49.33M
B/s] [backup-data-size(after-compressed)=59.02GB] [Size=59023982230]

1、从表T2看出，通过SQL预估表大小有时候差好几倍的数据量，便于做存储规划，请问有没有更准确的估算表大小的方法？

2、看两个表的备份压缩比也有几倍的差异，请问BR备份的压缩率跟什么有关系的？

2

两个表基本都是 varchar 字段，没有大对象字段类型

3

Brotli压缩算法。这个压缩和样本值有关，应该是相似度高压缩率就高

4

猜测，和本地的文本压缩一个道理

5

有文档吗？

6

备份出来的sst 文件，
可以看这个sst 文件的介绍，应该是使用rocksdb 常用压缩

https://docs.pingcap.com/zh/tidb/stable/br-snapshot-architecture

1 个赞
7

备份出来的是sst文件，最后一层应该是sztd算法
image

2 个赞
8 
更准确的估算表大小的方法： TiDB 提供的 INFORMATION_SCHEMA.TABLES 视图中的 DATA_LENGTH, INDEX_LENGTH, 和 DATA_FREE 字段可以用来估算表的大小。但是，这些值是基于 TiDB 中的逻辑数据结构计算的，并不反映实际在存储引擎层面的数据大小。实际数据大小可能会因为存储引擎的压缩算法、索引结构、碎片化等因素而有所不同。

为了更准确地估算表大小，您可以考虑以下方法：
    使用 tidb_analyze_version=2 进行表分析，这会更新统计信息，包括表和索引的行数和大小，提供更准确的数据。
    使用 EXPLAIN 或 EXPLAIN ANALYZE 查看查询的执行计划，这可以帮助您了解表的实际数据分布。
    对于 BR 备份，您可以直接查看备份日志中的 total-kv-size，这是备份过程中实际读取的数据大小，更接近于实际存储使用量。
    如果您使用的是 TiDB Enterprise Edition，可以考虑使用 TiDB Dashboard 中的 Performance Monitoring 功能来监控集群的存储使用情况。

BR备份的压缩率与什么有关： BR（Backup & Restore）备份的压缩率受到多种因素的影响，包括：
    数据类型：不同类型的数据可能具有不同的压缩特性。例如，文本数据通常比二进制数据更容易压缩。
    数据重复度：高重复度的数据（如大量重复的字符串或相同的数值）更容易被压缩。
    数据模式：数据的组织方式也会影响压缩率。例如，有序的数据可能比无序的数据更容易压缩。
    压缩算法：BR 使用的压缩算法也会影响最终的压缩率。TiDB 默认使用的是 lz4 压缩算法，它提供了较好的压缩速度和适中的压缩率。
    备份选项：BR 的备份选项，如是否启用压缩，也会直接影响最终的备份文件大小。
9

br restore 后直接进压缩率最高的最底层，能看出表大小（压缩后）

10

我猜压缩率这个一般是和数据重复关系最大，你表里面的每一行数据都很相似那就压缩率很高，如果都不太相似压缩率就底，这个你可以同一个表不同数据测试下

11

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。