这个 PostgreSQL 让我有资本找老板要 鸡腿 鸭腿 !!

正文

PostgreSQL 最大的问题之一,磁盘的消耗。这主要产生于三个我们熟悉的方面。

1 PostgreSQL本身的表膨胀的问题，这个问题我们可以通过即时的调整autovacuum的参数，或者类似我们公司，专门开发一套VACUUM自动识别和管理的系统，来在autovacuum不给力的时候，我们自己智能进行整理，避开业务高峰。

2 WAL的FPW，full page write,在多份专业的文档都有提到，我之前也做过相关的测试，真实的POSTGRESQL本身的日志在整体日志文件中的占比不会超过40%大部分在30%，也就是说70%的数据都是fpw，full page write,这个部分对于数据库的性能的有害性应该是人尽皆知。

3 数据压缩的不彻底，虽然我们都知道PG本身有数据压缩，但他是对大型字段的toast的文件进行压缩，通过我们熟悉LZ4 ,ZSTD等压缩方法，但如果我们的数据库没有特别多的大字段，或者这些压缩要消耗我的CPU呢？那么数据库这个层次也无能为力。

所以，所以，所以，使用POSTGRESQL数据库的单位都在找一个方案来对POSTGRESQL瘦身，我们应该怎么办？

我们没有光在PostgreSQL本身进行探索，因为我们要更大的经济效益，为了证实我们的选择是正确的，我们使用了PostgreSQL 对比 PolarDB for PostgreSQL 进行了不能说一模一样，只能说完全clone的方式来进行比对。

测试的数据库

1 POSTGRESQL 13.9 8C 32G 9T的磁盘，实际使用磁盘量为8.28T，这还是我们一个比较一般的库，算中上的大小。

生产CLONE PG

生产CLONE PG

PostgreSQL 原生磁盘使用量

PostgreSQL 原生磁盘使用量

2 PolarDB for PostgreSQL 14

8C 32G 实际占用磁盘2.4T

测试数据压缩方案效率

测试数据压缩方案效率

PolarDB for PostgreSQL

PolarDB for PostgreSQL

通过这个部分我们可以证明两点

1 PostgreSQL的表膨胀的问题，是一个严重的问题，通过数据传输后，我们实际8.28T的数据，本身在6.03T。 8.28 -6.03 = 2.25 T ，我们有2.25T是表膨胀后的结果。也就是差不多有27%空间是表膨胀的空间，曾经承载死元组的空间，现在在等待新的数据填满。

2 PolarDB for PG开启了硬件压缩后的2.4T的数据实际的存储量是6.03T。

6.03 -2.4约为 3.63TB，也就是说把我的实际数据量降低到40%，60%的数据已经被压缩掉了。

同时需要说明的是这是我们在开启了toast压缩的基础上的结果，在开启toast数据库本身压缩后，PolarDB for PostgreSQL还能把整体数据库在压缩60%的数据。

最后呢，成本直线下降，如果我们更换了这个数据库后，我们的成本会通过切换+硬件压缩后，将9T的磁盘压缩到2.4TB左右，我们可以释放6T多的磁盘，且不花这个钱了，如果我们N多个库都这么干。

黄金万两，我就想问问，老板能不能给我中午加个鸡腿，没事鸡腿没有，鸭腿也行。

写到最后，DBA干到最后比拼的是什么，在大部分企业里面，成本的节省是证明一个甲方DBA，或数据库架构选择数据库成功的证明，在保证业务稳定，数据库稳定的基础上，向更先进的数据库进行发展和迁移是当代DBA的重要工作，历史创造机遇这恰恰是属于中国DBA的特殊历史时期。