数据压缩60%让“PostgreSQL” SQL运行更快,这不科学呀?

开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9)(1 2 3 4 5 6 7群均已爆满,开8群近400 9群 200+,开10群PolarDB专业学习群100+)

在PolarDB 的非官方的数据库课程中,其中有一节提到了PolarDB for PostgreSQL 可以进行数据压缩,压缩比率非常高100%的数据经过压缩后,只剩下40%。在文章的评论区,我记得有一个同志问,这个会不会影响PostgreSQL的运行效率。

是的,其实不光他担心,传统DBA也担心这个问题,在POSTGRESQL中我们可以通过很多的方法对数据进行压缩,但这些方法都有一个问题,对CPU的消耗。所以提出这个问题的同志的担心是有必要的,但这里需要说明PolarDB for PostgreSQL的压缩是硬件压缩,也就是磁盘本身有压缩的功能,基于存算分离的设计和特性,这里磁盘的压缩和计算CPU是无关的。

但我们必须要经过测试才能证明这点,这里我们准备了两个数据库都是PolarDB for PostgreSQL 14,其中一个我们开启压缩,一个不开启压缩,其他的配置和功能完全一致。

主机是个人账号购买,消费

压测很简单还是通过撰写一个测试的脚本来完成。

-- 清理旧表
DROP TABLE IF EXISTS table3;
DROP TABLE IF EXISTS table2;
DROP TABLE IF EXISTS table1;

-- 创建表结构
CREATE TABLE table1 (
    id SERIAL PRIMARY KEY,
    name TEXT,
    value INT
);

CREATE TABLE table2 (
    id SERIAL PRIMARY KEY,
    table1_id INT REFERENCES table1(id),
    description TEXT
);

CREATE TABLE table3 (
    id SERIAL PRIMARY KEY,
    table2_id INT REFERENCES table2(id),
    tag TEXT
);
DO $$
DECLARE
    i INT := 1;
    start_time TIMESTAMP;
    end_time TIMESTAMP;
BEGIN
    RAISE NOTICE '开始插入 table1';
    start_time := clock_timestamp();
    WHILE i <= 1000000 LOOP
        INSERT INTO table1(name, value) VALUES ('name_' || i, i);
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table1 插入耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);

    i := 1;
    RAISE NOTICE '开始插入 table2';
    start_time := clock_timestamp();
    WHILE i <= 1000000 LOOP
        INSERT INTO table2(table1_id, description) VALUES ((random()*999999 + 1)::INT, 'desc_' || i);
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table2 插入耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);

    i := 1;
    RAISE NOTICE '开始插入 table3';
    start_time := clock_timestamp();
    WHILE i <= 1000000 LOOP
        INSERT INTO table3(table2_id, tag) VALUES ((random()*999999 + 1)::INT, 'tag_' || i);
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table3 插入耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);
END
$$;
DO $$
DECLARE
    i INT := 1;
    start_time TIMESTAMP;
    end_time TIMESTAMP;
BEGIN
    RAISE NOTICE '开始更新 table1';
    start_time := clock_timestamp();
    WHILE i <= 100000 LOOP
        UPDATE table1 SET value = value + 1 WHERE id = (random()*999999 + 1)::INT;
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table1 更新耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);

    i := 1;
    RAISE NOTICE '开始更新 table2';
    start_time := clock_timestamp();
    WHILE i <= 100000 LOOP
        UPDATE table2 SET description = description || '_u' WHERE id = (random()*999999 + 1)::INT;
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table2 更新耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);

    i := 1;
    RAISE NOTICE '开始更新 table3';
    start_time := clock_timestamp();
    WHILE i <= 100000 LOOP
        UPDATE table3 SET tag = tag || '_v' WHERE id = (random()*999999 + 1)::INT;
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table3 更新耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);
END
$$;
DO $$
DECLARE
    i INT := 1;
    start_time TIMESTAMP;
    end_time TIMESTAMP;
    dummy TEXT;
BEGIN
    RAISE NOTICE '开始单表查询 table1';
    start_time := clock_timestamp();
    WHILE i <= 10000 LOOP
        SELECT name INTO dummy FROM table1 WHERE id = (random()*999999 + 1)::INT;
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table1 单表查询耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);

    i := 1;
    RAISE NOTICE '开始单表查询 table2';
    start_time := clock_timestamp();
    WHILE i <= 10000 LOOP
        SELECT description INTO dummy FROM table2 WHERE id = (random()*999999 + 1)::INT;
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table2 单表查询耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);

    i := 1;
    RAISE NOTICE '开始单表查询 table3';
    start_time := clock_timestamp();
    WHILE i <= 10000 LOOP
        SELECT tag INTO dummy FROM table3 WHERE id = (random()*999999 + 1)::INT;
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE 'table3 单表查询耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);

    i := 1;
    RAISE NOTICE '开始多表联查';
    start_time := clock_timestamp();
    WHILE i <= 10000 LOOP
        SELECT t1.name, t2.description, t3.tag
        INTO dummy, dummy, dummy
        FROM table1 t1
        JOIN table2 t2 ON t1.id = t2.table1_id
        JOIN table3 t3 ON t2.id = t3.table2_id
        WHERE t1.id = (random()*999999 + 1)::INT
        LIMIT 1;
        i := i + 1;
    END LOOP;
    end_time := clock_timestamp();
    RAISE NOTICE '多表联查耗时: % 秒', EXTRACT(SECOND FROM end_time - start_time);
END
$$;

下面我将执行的结果进行截图,方便大家比对

1 打开压缩的

PLS4打开压缩
PLS4打开压缩

2 关闭压缩的

PLS4关闭压缩
PLS4关闭压缩

表名

压缩 (s)

不压缩 (s)

差异 (s)

说明

table1

5.172172

5.529172

+0.357

微小浮动

table2

30.73330

30.63361

-0.100

稳定

table3

30.28279

31.89955

+1.617

有波动

压测的数据库性能
压测的数据库性能
不压测的数据库性能
不压测的数据库性能

数据插入,在数据插入的结果中明显开启压缩的情况CPU消耗要更平稳,而不开启压缩的PolarDB for PostgreSQL CPU突发的消耗会更多。

第二个测试,用大量的UPDATE对两个数据库进行同样的压力测试。

同样的代码
同样的代码

在测试中出现了一个与大部分人想法相反的情况,压缩的PolarDB for PostgreSQL 要比不压缩的IOPS低,也就是执行同样的指令尤其在数据UPDATE的操作中,压缩的PolarDB for PostgreSQL IOPS要更低。

不压缩的 polardb for PG
不压缩的 polardb for PG
压缩的polardb for postgresql
压缩的polardb for postgresql

3 最后我们通过多表的查询来对此次的测试压缩和不压缩的性能差别进行一个总结,我们执行同样的查询压测脚本在两个服务器上,同样的数据,同样的查询我们看看相关得到的结果

查询脚本
查询脚本
不压缩查询的速度
不压缩查询的速度
压缩查询的速度
压缩查询的速度

📊 PostgreSQL 查询耗时对比(单位:秒)

查询类型

表名

压缩后耗时

未压缩耗时

单表查询

table1

12.307233

20.791665

单表查询

table2

37.118749

44.701972

单表查询

table3

37.540800

50.294852

压缩的测试性能图
压缩的测试性能图
不压缩测试性能图
不压缩测试性能图

所以那个问PolarDB for PostgreSQL压缩后会性能变差吗,NO NO NO ,经过上面的测试给出的结果是,一定要压缩,压缩后系统又稳定,SQL运行又快,So good ! 

置顶

未知黑客通过SQL SERVER 窃取企业SAP核心数据,影响企业运营

那个MySQL大事务比你稳定,主从延迟低,为什么? Look my eyes! 因为宋利兵宋老师

非“厂商广告”的PolarDB课程:用户共创的新式学习范本--7位同学获奖PolarDB学习之星

      说我PG Freezing Boom 讲的一般的那个同学,专帖给你,看看这次可满意

     短评 国产数据库营销市场 “问题”

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

     DBA被瞧不起 你有什么建议? Drive Fast !

OceanBase Hybrid search 能力测试,平换MySQL的好选择

HyBrid Search 实现价值落地,从真实企业的需求角度分析 !不只谈技术!

一个IP地址访问两个PG实例,上演“一女嫁二夫”的戏码

OceanBase 光速快递 OB Cloud “MySQL” 给我,Thanks a lot

从“小偷”开始,不会从“强盗”结束 -- IvorySQL 2025 PostgreSQL 生态大会

被骂后的文字--技术人不脱离思维困局,终局是个 “死” ? ! ......

9

个群2025上半年总结,OB、PolarDB, DBdoctor、爱可生、pigsty、osyun、工作岗位等

卷呀卷,Hybrid 混合查询学习--哪个库是小趴菜

从MySQL不行了,到乙方DBA 给狗,狗都不干? 我干呀!

DBA 干不好容易蹲牢房--这事你知道吗?

SQL SERVER 2025发布了, China幸亏有信创!

MongoDB 麻烦专业点,不懂可以问,别这么用行吗 ! --TTL

P-MySQL SQL优化案例,反观MySQL不死没有天理

MySQL 条件下推与排序优化实例--MySQL8.035

云数据库厂商除了卷技术,下一个阶段还可以卷什么?

PostgreSQL 新版本就一定好--由培训现象让我做的实验

某数据库下的一手好棋!共享存储落子了!

删除数据“八扇屏” 之 锦门英豪  --我去-BigData!

PostgreSQL “乱弹” 从索引性能到开发优化

写了3750万字的我,在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究》

SQLSHIFT 是爱可生对OB的雪中送炭!

青春的记忆,MySQL 30年感谢有你,再见!(译)

老实人做的数据库产品,好像也不“老实” !

疯狂老DBA 和 年轻“网红” 程序员 --火星撞地球-- 谁也不是怂货  

哈呀站,OB广州开发者大会 之 “五” 眼联盟

和架构师沟通那种“一坨”的系统,推荐只能是OceanBase,Why ?

OceanBase 相关文章

某数据库下的一手好棋!共享存储落子了!

写了3750万字的我,在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究》

     哈呀站,OB广州开发者大会 之 “五” 眼联盟

OceanBase 单机版可以大批量快速部署吗? YES

OceanBase 6大学习法--OBCA视频学习总结第六章

OceanBase 6大学习法--OBCA视频学习总结第五章--索引与表设计

OceanBase 6大学习法--OBCA视频学习总结第五章--开发与库表设计

OceanBase 6大学习法--OBCA视频学习总结第四章 --数据库安装

OceanBase 6大学习法--OBCA视频学习总结第三章--数据库引擎

OceanBase 架构学习--OB上手视频学习总结第二章 (OBCA)

OceanBase 6大学习法--OB上手视频学习总结第一章

没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛

OceanBase  送祝福活动,礼物和幸运带给您

跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)

跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)

跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)

跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)

聚焦SaaS类企业数据库选型(技术、成本、合规、地缘政治)

OceanBase 学习记录-- 建立MySQL租户,像用MySQL一样使用OB
         MongoDB 相关文章

MongoDB “升级项目” 大型连续剧(4)-- 与开发和架构沟通与扫尾

MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项

MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"

MongoDB “升级项目”  大型连续剧(1)-- 可“生”可不升

MongoDB  大俗大雅,上来问分片真三俗 -- 4 分什么分

MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法

MongoDB 学习建模与设计思路--统计数据更新案例

MongoDB  大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用

MongoDB  大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模

MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通

MongoDB 年底活动,免费考试名额 7个公众号获得

MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)

MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模

MongoDB  双机热备那篇文章是  “毒”

MongoDB   会丢数据吗?在次补刀MongoDB  双机热备

MONGODB  ---- Austindatabases  历年文章合集

PolarDB 已经开放的课程

PolarDB 非官方课程第八节--数据库弹性弹出一片未来--结课

PolarDB 非官方课程第七节--数据备份还原瞬间完成是怎么做到的--答题领奖品

PolarDB 非官方课程第六节--数据库归档还能这么玩--答题领奖品

PolarDB 非官方课程第五节--PolarDB代理很重要吗?--答题领奖品

PolarDB 非官方课程第四节--PG实时物化视图与行列数据整合处理--答题领奖品

PolarDB 非官方课程第三节--MySQL+IMCI=性能怪兽--答题领奖品

PolarDB 非官方课程第二节--云原生架构与特有功能---答题领奖品

PolarDB 非官方课程第一节-- 用户角度怎么看PolarDB --答题领奖品

免费PolarDB云原生课程,听课“争”礼品,重塑云上知识,提高专业能力

PolarDB 相关文章

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

用MySQL 分区表脑子有水!从实例,业务,开发角度分析 PolarDB 使用不会像MySQL那么Low

P-MySQL SQL优化案例,反观MySQL不死没有天理

MySQL 和 PostgreSQL 可以一起快速发展,提供更多的功能?

这个MySQL说“云上自建的MySQL”都是”小垃圾“

        PolarDB MySQL 加索引卡主的整体解决方案

“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!

PostgreSQL 的搅局者问世了,杀过来了!

在被厂商围剿的DBA 求生之路 --我是老油条

POLARDB  添加字段 “卡” 住---这锅Polar不背

PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)

在被厂商围剿的DBA 求生之路 --我是老油条

PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)

PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火

PostgreSQL 相关文章

说我PG Freezing Boom 讲的一般的那个同学专帖给你看这次可满意

一个IP地址访问两个PG实例,上演“一女嫁二夫”的戏码

PostgreSQL  Hybrid能力岂非“小趴菜”数据库可比 ?

PostgreSQL 新版本就一定好--由培训现象让我做的实验

PostgreSQL “乱弹” 从索引性能到开发优化

PostgreSQL  无服务 Neon and Aurora 新技术下的新经济模式 (翻译)

PostgreSQL的"犄角旮旯"的参数捋一捋

PostgreSQL逻辑复制槽功能

PostgreSQL 扫盲贴 常用的监控分析脚本

“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!

PostgreSQL  添加索引导致崩溃,参数调整需谨慎--文档未必完全覆盖场景

PostgreSQL 的搅局者问世了,杀过来了!

PostgreSQL SQL优化用兵法,优化后提高 140倍速度

PostgreSQL 运维的难与“难”  --上海PG大会主题记录

PostgreSQL 什么都能存,什么都能塞 --- 你能成熟一点吗?

PostgreSQL 迁移用户很简单 ---  我看你的好戏

PostgreSQL 用户胡作非为只能受着 --- 警告他

全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁

PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!

病毒攻击PostgreSQL暴力破解系统,防范加固系统方案(内附分析日志脚本)

PostgreSQL 远程管理越来越简单,6个自动化脚本开胃菜

PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆

PostgreSQL 如何通过工具来分析PG 内存泄露

PostgreSQL  分组查询可以不进行全表扫描吗?速度提高上千倍?

POSTGRESQL --Austindatabaes 历年文章整理

PostgreSQL  查询语句开发写不好是必然,不是PG的锅

PostgreSQL  字符集乌龙导致数据查询排序的问题,与 MySQL 稳定 "PG不稳定"

PostgreSQL  Patroni 3.0 新功能规划 2023年 纽约PG 大会 (音译)

PostgreSQL   玩PG我们是认真的,vacuum 稳定性平台我们有了

PostgreSQL DBA硬扛 垃圾 “开发”,“架构师”,滥用PG 你们滚出 !(附送定期清理连接脚本)

DBA 失职导致 PostgreSQL 日志疯涨

MySQL相关文章

MySQL 条件下推与排序优化实例--MySQL8.035

青春的记忆,MySQL 30年感谢有你,再见!(译)

MySQL 8 SQL 优化两则 ---常见问题

MySQL SQL优化快速定位案例 与 优化思维导图

"DBA 是个der" 吵出MySQL主键问题多种解决方案

MySQL 怎么让自己更高级---从内存表说到了开发方式

MySQL timeout 参数可以让事务不完全回滚

MySQL 让你还用5.7 出事了吧,用着用着5.7崩了

MySQL 的SQL引擎很差吗?由一个同学提出问题引出的实验

用MySql不是MySQL, 不用MySQL都是MySQL 横批 哼哼哈哈啊啊

MYSQL  --Austindatabases 历年文章合集

临时工访谈系列

没有谁是垮掉的一代--记 第四届 OceanBase 数据库大赛

ETL 行业也够卷,云化ETL,ETL 软件不过了

SQL SERVER 系列

SQL SERVER维保AI化,从一段小故事开始

SQL SERVER 如何实现UNDO REDO 和PostgreSQL 有近亲关系吗

SQL SERVER 危险中,标题不让发,进入看详情(译)

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值