查看原文
其他

这么哇塞的 MySQL 功能,你确定不用么?

破产码农 InsideMySQL 2022-10-13

        

破产码农

IT圈最会讲故事的网红 · 南山彭于晏

大家好,今天我们来聊聊 MySQL 数据库中的压缩功能。

先问一个问题,压缩会导致性能下降么?

通过压缩页会减少存储空间的开销,但是会有额外 CPU 的开销,因此性能会有影响。

想必大部分同学都是类似如上的回复。

然而,答案却是:以上全错。

这好比你买了套 500 万的房子,贷款 350W。30 年等额本息还款,算上 30 年的利息,实际你要还 700W。

所以你说,买房肯定是亏的。

很显然,这个推理是不对的。

因为 30 年后,随着物价的上涨,你所持有的房子大概率至少涨了 1 倍。

因此你的房子市值将会是 1000W,除去 700W 的连本带利的还款,实际你还赚了 150 万。

有同学肯定会说,万一 30 年没有涨 1 倍呢?

是的,如果你不小心脑残地入手了三亚、丽江、鹤岗等地的房产,入手了号称租售比 10%的沿街商铺,那么的确存在 30 年涨不到 1 倍的风险可能(其实也很小)。

所以,房产取决于你购买标的的选择。

对于数据库的压缩,是否性能下降取决于压缩功能的实现。

的确,MySQL 5.7 版本之前的压缩功能设计存在缺陷,压缩可能会导致性能严重的下降。

但 MySQL 5.7 版本开始 InnoDB 存储引擎提供了一种新的压缩功能,称为透明页压缩(Transparent Page Compression,下简称 TPC )。

下面我们就来讲讲这种对性能几乎没有影响的压缩功能。




旧的 InnoDB 页压缩功能


我们先来看看旧的 InnoDB 页压缩功能。

旧的 InnoDB 页压缩是指在建表或者修改表时加上如下的 KEY_BLOCK_SIZE 选项:

CREATE TABLE `t` ( `a` int NOT NULL, `b` varchar(128) DEFAULT NULL, `c` datetime(6) DEFAULT NULL, PRIMARY KEY (`a`)) ENGINE=InnoDB KEY_BLOCK_SIZE = 8

KEY_BLOCK_SIZE 可以是 1、2、4、8、16,表示启用页压缩,然后按照 1K、2K、4K、8K、16K 的页大小存储数据。

压缩算法使用常见的 zlib。

由于 InnoDB 页的大小是 16K,zlib 的压缩比通常在 50%左右,因此一般 KEY_BLOCK_SIZE 设置为 8 比较常见。

设置得再小,压缩比例也不一定会提高。

因为其本质是将 16K 的页压缩后,根据 KEY_BLOCK_SIZE 大小存储。

假设页 16K,压缩后的大小是 7K,则设置 KEY_BLOCK_SIZE 为 8,一个 8K 压缩页存储即可。

若 KEY_BLOCK_SIZE 为 4,则拆分成 2 个 4K 页存储。占用存储空间不会有太大的变化。

前面姜老师谈到,旧的 InnoDB 页压缩功能设计存在缺陷,启用压缩功能后,性能下降比较明显。

然而,它的实现思想初衷是提升性能,甚至借用了其他数据库的一些理念:日志即数据

什么意思呢?也就是对于压缩页的数据修改,他首先并不会修改页本身,而是将日志存储在这个页中。

所以压缩页的格式大致如下所示:

的确,这样的实现对于页的变更比较好,无需每次插入记录进行压缩。

但是除了数据库除了写入操作,库还有大量的读取操作。

显然,对于压缩的数据,是无法直接读取的。

因此,旧的 InnoDB 页压缩算法还会在内存中有一个解压后 16K 的页,以供数据的读取,如:

这时你会发现一个页在缓冲池存在两个版本,压缩的版本和非压缩的版本

这样会导致一个非常严重的问题,即缓冲池中能缓存页的数量大大减少

数据库的性能随之就会有极大的下降。

接着,我们来看下 MySQL 5.7 版本后新的 TPC 压缩是如何实现的,他又是如何保证性能尽可能保持原有水平呢?




新的 InnoDB TPC 页压缩


MySQL 5.7 版本推出的 TPC 页压缩是一种极其高效的压缩算法,其使用相当简单,只要在建表的时候添加压缩选项即可,如:

CREATE TABLE `t` ( `a` int NOT NULL, `b` varchar(128) DEFAULT NULL, `c` datetime(6) DEFAULT NULL, PRIMARY KEY (`a`)) ENGINE=InnoDB COMPRESSION='zlib'

除了 zlib 压缩,TPC 还可以选择 lz4 压缩算法。

我们来看下 TPC 的具体实现过程:

可以看到 TPC 压缩下,一个压缩页在缓冲池中都是一个 16K 的非压缩页。

只有在刷新到磁盘的时候,会进行一次压缩,对于压缩后剩余的空间,页中都填写 0x00。

最后写入到磁盘后,调用文件系统空洞(Hole Punch)特性对文件进行“裁剪”,释放 0x00 占用的稀疏空间。

当前 Linux 内核以及绝大部分的文件系统,如 XFS、EXT4、ZFS、btrfs、NTFS 等,都支持空洞特性,具体内核版本已经文件系统可见官方文档的具体说明。

TPC 虽然好,但是他依赖的 Hole Punch 有一个限制,即原始文件裁剪后的大小是根据文件系统块大小对齐的,也就是 4K 对齐。

对于上图的例子,压缩后页的大小是 9K,那么实际占用的空间是 12K

可以通过下面的命令查看表空间占用的实际磁盘空间:

SELECT SPACE, NAME, FS_BLOCK_SIZE, FILE_SIZE, ALLOCATED_SIZE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME='sbtest/sbtest1';

下面是姜老师写的一段 C 代码,用于描述透明页压缩在内核层的实现。

看懂这几行,你也就弄明白 MySQL InnoDB 中代码的实现本质:

图 - 函数 hole_punch_compress

上面的代码和我们之前介绍的 O_DIRECT 写入方式基本一样。不同点在于:

  1. 使用 zlib 的 compress 函数对 16K 的页进行压缩(第 16 行);

  2. 对于压缩后的页剩余部分用 0x00 进行填充(第 19 行);

  3. 调用函数 pwrite 进行原子写入后,再调用函数 fallocate 对文件进行空洞压缩(第 29 行);

好吧,既然姜老师把 TPC 压缩说的这么好,怎么能少得了最具实战意义的测试呢?

接下去,Let's go ~~~




TPC 性能测试


这里我们选择 sysbench 工具进行性能测试。

测试的表是一张有 3200W 行记录的表,数据量 7G,压缩后表的大小分别为:

从压缩比例来看,旧的 InnoDB 压缩算法有着更好的压缩比例,但是实际数据导入时间却是 TPC 压缩算法的数倍。

此外,真实的生产环境下,TPC 的压缩比例和旧的压缩算法其实差不多,都能在 40% ~ 50%之间。

下图就是最为关键的性能测试结果,这里选取了主键读取测试:

可以看到由于 sysbench 测试中有热点,BP 为 8G、4G 基本都能缓存住热点数据,因此两者性能几乎没有区别,都能跑到 100W QPS。

但是老的压缩算法即便在 8G 的缓冲池大小下,性能也有较为明显的下降。

所以说,这么香的 TPC 压缩功能,你确定不在生产环境中使用么?




总结


今天姜老师带大家深入浅出了 InnoDB TPC 页压缩的实现,总结来说:

  • TPC 压缩不占用额外的缓冲池空间,所有压缩页在缓冲池中都是 16K;
  • 页的压缩仅在写入磁盘时进行,不会在缓冲池中对一个页进行反复的压缩尝试;
  • 使用文件系统空洞特性进行压缩,释放磁盘空间;
  • 对比旧的压缩算法,性能及其优秀。

最后,老规矩,留几道思考题。

以供小伙伴们茶余饭后约上三五知己,讨论一下:

  1. 如何不压缩表,预估出启用 TPC 压缩后,表的压缩比例大概有多少?please show me your code

  2. 对于图中函数 hole_punch_compress,尝试编写单元测试,验证函数的正确性。please show me your code


直播预告


每周五、六,不定期直播,分享技术干货


IMG群是码农的交流社区,IMG微信群交流内容包括但不限于技术、经济、军事、八卦等话题。欢迎有态度的码农们加入IMG大家庭。
IMG目前有少林群、武当群、峨眉群、华山群、M悦会(高端VIP群)
仅限码农入群,猎头或其他行业勿加,入群请加姜老师个人微信 82946772,并备注:码农入IMG群
-----------------------
公众号:InsideMySQL
视频号:破产码农
抖音号:破产码农
B站号:姜老师带你飞
长按下图二维码关注,将感受到一个有趣的灵魂,每篇文章都会有新惊喜。

          

往期推荐

作为新生代农民工,码农30岁存款应该有多少?


关于 O_DIRECT 的正确答案!


PostgreSQL 不支持的 O_DIRECT,MySQL 和 Oracle 都有


一个参数,MySQL 8.0 性能飙升180%!!!


全网首测,MySQL Router来了,不容错过!!!


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存