MySQL · 引擎特性 · InnoDB 大字段压缩

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云数据库 RDS SQL Server,基础系列 2核4GB
简介:

前言

当用户的数据量比较大时,通常需要对数据进行压缩,以减少磁盘占用。InnoDB目前有两种方式来实现这一目的。

第一种是传统的数据压缩,通过指定row_format及key_block_size,能够将用户表压缩到指定的page size并进行存储,默认使用zlib。这种压缩方式使用比较简单,但也是诟病较多的, 代码陈旧,相关代码基本上几个大版本都没发生过变化,一些优化点还是从facebook移植过来的(集中在在5.6版本中, 不过现在fb已经放弃优化InnoDB压缩了,转而聚集在自家压缩更好的myrock上)。InnoDB压缩表的性能瓶颈明显,尤其是在压缩page到指定size失败时触发索引分裂。

第二种是MySQL5.7引入的所谓transparent compression,通过文件系统punch hole和sparse file特性来实现的。具体的就是在将数据页进行压缩后,将留白的地方进行打洞,从而实现数据压缩的目的。这个实现的好处就是代码逻辑简单,整个feature的实现基本上没加多少代码,无需指定key_block_size(但依然需要根据文件系统block size对齐),并且也能更方便的支持多种压缩算法。但缺点也明显,例如可能会产生大量的文件碎片,底层的文件管理可能更复杂;也无法降低buffer pool的占用(传统的压缩方式可以只在buffer pool保存压缩页)

另外还有一种方式是通过MySQL函数compress/decompress,由应用端来决定存入的数据是否压缩,并控制解压操作。但这种方式不够灵活,需要应用来修改代码。

在AliSQL中我们提供了一种新的列压缩方式,用户在建表时可以将列属性column_format指定为compressed,那么服务器就会在存入/取出这个列的数据时,自动对其进行压缩和解压动作。这个方案不仅降低了磁盘数据大小,而且也能最大程度的保证性能,例如在查询不涉及到压缩列时无需执行解压动作。该特性尤其适用于诸如blob或者text这样的大列。

Percona Server也基于该补丁进行了功能扩展和优化。社区用户现在可以同时从AliSQL及Percona Server中获得该特性。

本文主要简单介绍下AliSQL如何实现的该特性,以及Percona的实现方案。

AliSQL实现

使用该特性非常简单,可以在建表时指定列属性,或者在ALTER TABLE来修改列属性。

mysql> CREATE TABLE t1 (a INT PRIMARY KEY,  b blob);
Query OK, 0 rows affected (0.00 sec)

mysql> ALTER TABLE t1 MODIFY COLUMN b BLOB COLUMN_FORMAT COMPRESSED;
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `a` int(11) NOT NULL,
  `b` blob /*!50616 COLUMN_FORMAT COMPRESSED */,
  PRIMARY KEY (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

目前仅支持对blob/text/varchar/varbinary这几种类型进行压缩,如果在其他类型列上定义compressed属性,会抛出一个warning,并忽略列属性:

mysql> CREATE TABLE t1 (a INT AUTO_INCREMENT PRIMARY KEY, b INT COLUMN_FORMAT COMPRESSED);
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> SHOW WARNINGS;
+---------+------+------------------------------------------------------------------------------------------+
| Level   | Code | Message                                                                                  |
+---------+------+------------------------------------------------------------------------------------------+
| Warning | 3002 | Can not define column 'b' in compressed format, silently change column_format to default |
+---------+------+------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

也不支持在压缩列上创建二级索引,因为压缩后的数据可能已经不具备顺序性,在其上创建索引没有意义,一个错误码会被抛出:

mysql> CREATE TABLE t1 (a INT AUTO_INCREMENT PRIMARY KEY, b BLOB COLUMN_FORMAT COMPRESSED, KEY (b(20)));
ERROR 3001 (HY000): Compressed BLOB/TEXT/VARCHAR/VARBINARY column 'b' used in key list is not allowed

由于大部分用户的引擎还是InnoDB,因此目前该特性仅支持InnoDB表(其实真实原因是笔者在写这个补丁时只对InnoDB比较了解.....),未来不排除这个特性实现到server层,这样就可以做到和引擎无关了。

代码的实现也比较简单,分为两部分

压缩

在InnoDB接受到行数据并进行任何处理之前,先将对应的列数据进行压缩.

入口函数:row_compress_column

压缩后的数据包含如下部分:

1. 一个字节的header:
- COLUMN_COMPRESS_FLAG (1bit), 数据是否进行过压缩
- COLUMN_COMPRESS_DATA_LEN(2bits), 原始列的长度
- COLUMN_COMPRESS_ALG(3bits), 压缩算法,目前值为0,表示只支持zlib
- COLUMN_COMPRESS_WRAP(1bit), 标示zlib是否计算了adler32值
- 保留1个bit

2. 数据压缩前的长度,占用的字节数存储在COLUMN_COMPRESS_DATA_LEN

3. 压缩后的数据

如果发现压缩后的数据比原始数据还大,则放弃压缩,但会额外浪费1个字节来进行标识

我们提供了一些参数来对压缩进行控制,包括

  1. innodb_rds_column_compression_level: zlib的压缩级别
  2. innodb_rds_column_zip_mem_use_heap: 压缩过程中的内存分配/释放的回调函数,是使用InnoDB自带的还是系统自带的
  3. innodb_rds_column_zip_threshold: 当数据长度超过这么大时,才去进行压缩; 这个参数需要根据数据特点来进行调整,否则如果对很小的字段进行压缩,没什么效果不说,反而还浪费cpu.
  4. innodb_rds_column_zlib_strategy:使用的zlib压缩策略:
  5. innodb_rds_column_zlib_wrap: 是否在压缩/解压时进行adler32校验

解压

在从InnoDB取到一条数据并返回到server层之前,对列进行解压

入口函数: row_decompress_column

解压也比较简单,首先根据Header中的信息判断是否进行了压缩;然后再读出原始数据的长度;找到压缩数据的起始位置并进行解压后,跟原始长度进行校验。

全局Status变量来监控压缩和解压的次数:

mysql> show status like '%column%compress%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Innodb_column_compressed   | 0     |
| Innodb_column_decompressed | 0     |
+----------------------------+-------+
2 rows in set (0.00 sec)

完整的补丁见commit

Percona实现

Percona Server的列压缩实现来自Pinterest的贡献,Pinterest以AliSQL的列压缩补丁作为基础,做了进一步的改进。他们写了一篇博客描述了整个开发过程,感兴趣的可以点开看看。

为了实现更好的压缩比,Percona 实现了一个称为 "predefined dictionary", 实际上这是引用了新版本的zlib的一个特性。在压缩初始化后(deflateInit2),可以去设置一个预定义的数据词典.

参阅函数row_compress_column

        err = deflateInit2(&c_stream, srv_compressed_columns_zip_level,
                Z_DEFLATED, window_bits, MAX_MEM_LEVEL,
                srv_compressed_columns_zlib_strategy);
        ut_a(err == Z_OK);

        if (dict_data != 0 && dict_data_len != 0) {
                err = deflateSetDictionary(&c_stream, dict_data,
                        dict_data_len);
                ut_a(err == Z_OK);
        }

Percona利用这个特性,并增加了一系列的接口来管理预定义词典。每个压缩列都可以通过显式的命名指向一个词典。

系统表

增加了一个新的系统表SYS_ZIP_DICT, 用于存储词典数据, 定义如下:

    CREATE TABLE SYS_ZIP_DICT(
      ID INT UNSIGNED NOT NULL,
      NAME CHAR(64) NOT NULL,
      DATA BLOB NOT NULL
    );
    
    CREATE UNIQUE CLUSTERED INDEX SYS_ZIP_DICT_ID
      ON SYS_ZIP_DICT (ID);
    CREATE UNIQUE INDEX SYS_ZIP_DICT_NAME
      ON SYS_ZIP_DICT (NAME);
      
    你可以从information_schema.xtradb_zip_dict获得字段信息
    

系统表SYS_ZIP_DICT_COLS,用于存储哪些使用预定义压缩词典的列信息,定义如下:

    CREATE TABLE SYS_ZIP_DICT_COLS(
      TABLE_ID INT UNSIGNED NOT NULL,
      COLUMN_POS INT UNSIGNED NOT NULL,
      DICT_ID INT UNSIGNED NOT NULL
    );
    
    CREATE UNIQUE CLUSTERED INDEX SYS_ZIP_DICT_COLS_COMPOSITE
      ON SYS_ZIP_DICT_COLS (TABLE_ID, COLUMN_POS);
    
    -- 建立在该表之上的视图:information_schema.xtradb_zip_dict_cols
    

创建词典

语法: CREATE COMPRESSION_DICTIONARY <dict>(...)

例如: 

mysql> CREATE COMPRESSION_DICTIONARY dt1('abcd');
Query OK, 0 rows affected (0.00 sec)

mysql> SELECT * FROM INFORMATION_SCHEMA.XTRADB_ZIP_DICT;
+----+------+----------+
| id | name | zip_dict |
+----+------+----------+
|  1 | dt1  | abcd     |
+----+------+----------+
1 row in set (0.00 sec)

入口函数: innobase_create_zip_dict

使用词典

mysql> CREATE TABLE t1 (a INT PRIMARY KEY, b BLOB COLUMN_FORMAT COMPRESSED WITH COMPRESSION_DICTIONARY dt1);
Query OK, 0 rows affected (0.01 sec)

mysql> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `a` int(11) NOT NULL,
  `b` blob /*!50633 COLUMN_FORMAT COMPRESSED WITH COMPRESSION_DICTIONARY `dt1` */,
  PRIMARY KEY (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> SELECT * FROM INFORMATION_SCHEMA.XTRADB_ZIP_DICT_COLS;
+----------+------------+---------+
| table_id | column_pos | dict_id |
+----------+------------+---------+
|       22 |          1 |       1 |
+----------+------------+---------+
1 row in set (0.00 sec)

可以看到该列使用的预定义词典序号为1,对应dt1

当表上有引用的词典时,在打开表时就要从系统表中去进行关联(ha_innobase::update_field_defs_with_zip_dict_info)

删除词典

语法: DROP COMPRESSION_DICTIONARY <dict>

# 很显然,当有列引用到这个词典时,是不可以删除的

mysql> DROP COMPRESSION_DICTIONARY dt1;
ERROR 1894 (HY000): Compression dictionary 'dt1' is in use
mysql> ALTER TABLE t1 MODIFY COLUMN b BLOB COLUMN_FORMAT COMPRESSED;
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> DROP COMPRESSION_DICTIONARY dt1;
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT * FROM INFORMATION_SCHEMA.XTRADB_ZIP_DICT_COLS;
Empty set (0.00 sec)

mysql> SELECT * FROM INFORMATION_SCHEMA.XTRADB_ZIP_DICT;
Empty set (0.00 sec

入口函数:innobase_drop_zip_dict

参考文档:

Percona Column compression 文档

How to find a good/optimal dictionary for zlib

代码实现

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
1月前
|
SQL 监控 关系型数据库
MySQL事务处理:ACID特性与实战应用
本文深入解析了MySQL事务处理机制及ACID特性,通过银行转账、批量操作等实际案例展示了事务的应用技巧,并提供了性能优化方案。内容涵盖事务操作、一致性保障、并发控制、持久性机制、分布式事务及最佳实践,助力开发者构建高可靠数据库系统。
|
21天前
|
存储 关系型数据库 MySQL
介绍MySQL的InnoDB引擎特性
总结而言 , Inno DB 引搞 是 MySQL 中 高 性 能 , 高 可靠 的 存 储选项 , 宽泛 应用于要求强 复杂交易处理场景 。
60 15
|
6月前
|
存储 网络协议 关系型数据库
MySQL8.4创建keyring给InnoDB表进行静态数据加密
MySQL8.4创建keyring给InnoDB表进行静态数据加密
149 1
|
15天前
|
关系型数据库 MySQL 数据库
MySql事务以及事务的四大特性
事务是数据库操作的基本单元,具有ACID四大特性:原子性、一致性、隔离性、持久性。它确保数据的正确性与完整性。并发事务可能引发脏读、不可重复读、幻读等问题,数据库通过不同隔离级别(如读未提交、读已提交、可重复读、串行化)加以解决。MySQL默认使用可重复读级别。高隔离级别虽能更好处理并发问题,但会降低性能。
|
4月前
|
关系型数据库 MySQL
MySQL数据表添加字段(三种方式)
本文解析了数据表的基本概念及字段添加方法。在数据表中,字段是纵向列结构,记录为横向行数据。MySQL通过`ALTER TABLE`指令支持三种字段添加方式:1) 末尾追加字段,直接使用`ADD`语句;2) 首列插入字段,通过`FIRST`关键字实现;3) 指定位置插入字段,利用`AFTER`指定目标字段。文内结合`student`表实例详细演示了每种方法的操作步骤与结构验证,便于理解与实践。
|
10月前
|
存储 缓存 关系型数据库
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
MySQL的存储引擎是其核心组件之一,负责数据的存储、索引和检索。不同的存储引擎具有不同的功能和特性,可以根据业务需求 选择合适的引擎。本文详细介绍了MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案。
1674 57
【MySQL进阶篇】存储引擎(MySQL体系结构、InnoDB、MyISAM、Memory区别及特点、存储引擎的选择方案)
|
10月前
|
SQL 安全 关系型数据库
【MySQL基础篇】事务(事务操作、事务四大特性、并发事务问题、事务隔离级别)
事务是MySQL中一组不可分割的操作集合,确保所有操作要么全部成功,要么全部失败。本文利用SQL演示并总结了事务操作、事务四大特性、并发事务问题、事务隔离级别。
4238 56
【MySQL基础篇】事务(事务操作、事务四大特性、并发事务问题、事务隔离级别)
|
6月前
|
SQL 缓存 关系型数据库
使用温InnoDB缓冲池启动MySQL测试
使用温InnoDB缓冲池启动MySQL测试
105 0
|
10月前
|
存储 关系型数据库 MySQL
MySQL存储引擎详述:InnoDB为何胜出?
MySQL 是最流行的开源关系型数据库之一,其存储引擎设计是其高效灵活的关键。InnoDB 作为默认存储引擎,支持事务、行级锁和外键约束,适用于高并发读写和数据完整性要求高的场景;而 MyISAM 不支持事务,适合读密集且对事务要求不高的应用。根据不同需求选择合适的存储引擎至关重要,官方推荐大多数场景使用 InnoDB。
227 7
|
10月前
|
存储 关系型数据库 MySQL
Mysql索引:深入理解InnoDb聚集索引与MyisAm非聚集索引
通过本文的介绍,希望您能深入理解InnoDB聚集索引与MyISAM非聚集索引的概念、结构和应用场景,从而在实际工作中灵活运用这些知识,优化数据库性能。
554 7

相关产品

  • 云数据库 RDS MySQL 版
  • 推荐镜像

    更多