# 存储空间评估方法

![`smart`](StorageSpaceAssessmentMethods_zh_001_20240314.png)

----------------------------------------------------
1. 单个集群数据限制
如果是 Share-Nothing 架构（例如：MySQL、TiDB），需要评估单实例（机器）使用的存储大小，MySQL 等传统关系型数据库，一般受限于单盘大小，但是也要根据Buffer Pool 命中率、热数据比例、性能要求、存储空间冗余比例、单块磁盘大小等综合评估使用的单实例存储容量。 TiDB 需要官方要求单个 TiKV 存储的大小在 3-6TB，同时也需要根据业务场景（存储 or 计算）、Region 大小、单实例 CPU、业务性能要求、存储空间冗余比例、单块磁盘大小等进行综合评估。
如果是 Share-Disk 架构（Aurora、PolarDB），使用的是共享云盘，一般数据库层面看只需要一副本的数据存储空间，并且可以做到按需使用，弹性秒级扩展，没有单实例存储大小的概念，但是还是需要根据数据量、热数据比例和内存大小从性能角度考虑单个集群的存储大小。

2. 压缩率
一般传统单机关系型数据库在线业务不会开启数据的压缩功能，只有在部分温冷数据存储场景才会开启来降低成本；分布式关系型数据库一般是基于 LSM-Tree 的结构，默认是会对数据进行压缩，压缩率大概在 0.1~0.75 左右，实际的压缩率在异构数据迁移时需要通过从源数据库导数据到目标数据库的方式来获取。

3. 索引占比
一般情况下，业务的索引少则 1-2 个，多则十几甚至几十个，索引需要占用存储空间和行记录对比大概在 5%-80%左右，极端情况下会更高。如果是在数据库异构迁移场景，可以基于源数据库的统计信息获取该值。

4. 碎片率
一般传统单机关系型数据库例如 MySQL（RDS MySQL、Aurora、PolarDB 等）数据存储是基于 B+ Tree 格式，碎片率（默认填充因子为 15/16，并且还会存放一些少量的其他字段比如 page level，index number 等等）默认最低为 1/16，如果是频繁更新、删除数据，可能会达到 1/2 甚至2/3（经验值）。如果是新的分布式关系型数据库例如 TiDB，一般没有碎片率的问题。

5. 空间冗余
如果是 Share-Nothing 架构（例如：MySQL、TiDB），每个存储数据库实例使用的本地存储，一般是无法做到按需扩展，所以为了保证业务未来一段时间（1 个月/季度/年等）的存储需求，需要冗余一部分的存储空间，尤其是像传统单机关系型数据库 MySQL/PostgreSQL 等无法做 Scale Out 横向扩展，需要根据业务数据增长速度和业务要求冗余较长时间的存储空间，例如需要确保存储空间占比不超过 60%/80%等，那存储空间冗余比例则为 40%/20%。如果是新型的分布式数据库如 TiDB、OceanBase 等，一般可以在小时/天级别完成完成的 Scale Out 流程，所以冗余比例一般不需要像 MySQL 那样高，一般冗余 20%左右存储空间即可。

另外，在某些数据库中，我们可能还要考虑到 UNDO 数据所占的存储空间大小。