Tag: 压缩
MySQL InnoDB透明页压缩的简单分析
从MySQL 5.7版本开始，MySQL不仅支持原有的压缩表格式(Table Compression)，还支持一种称为透明页压缩的特性(Transparent Page Compression)。通过阅资料和源码，我对这个特性有了一定的了解。以下我将从它的使用方法、实现原理等方面对它进行简单分析，并同压缩表格式进行一些对比。 1. 开启方法 官方文档对于透明页压缩的特性的说明仅仅一页，主要说明了它的使用方法，我也对这页官方文档进行过翻译，详见：InnoDB Page Compression MySQL文档翻译：InnoDB透明页压缩 对于透明页压缩的使用方法，和压缩表格式相同的是，都是通过CREATE TABLE或者ALTER TABLE语法对于一个表使用的。不同点是压缩表格式使用ROW_FORMAT=COMPRESSED这个字段，而透明页压缩使用COMPRESSION=”zlib”、COMPRESSION=”lz4″或者COMPRESSION=”None”这种字段。分别用两种压缩形式创建一个表的例子： ## 创建一个表，启用压缩表格式，块的大小为8K CREATE TABLE t1(c1 INT) ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; # 创建一个表，启用透明页压缩，压缩算法为LZ4 CREATE TABLE t1(c1 INT) COMPRESSION=”zlib”(“lz4”…); 另外要注意：开启透明页压缩需要文件系统和操作系统支持 Sparse File 和 Hole Punching 特性，并且需要开启InnoDB的file-per-table选项。更详细的使用方法见上边的那篇翻译。 2. 原理简述 2.1. 先说说以前压缩表格式
Table Compression for OLTP Workloads MySQL文档翻译：OLTP工作负载中应用表压缩
原文： [MySQL 5.7 Manual 15.9.1.6 Compression for OLTP Workloads] https://dev.mysql.com/doc/refman/5.7/en/innodb-performance-compression-oltp.html 传统上，InnoDB压缩功能主要用于只读或大部分读取的工作负载，例如在数据仓库配置中。快速但相对较小和昂贵的SSD存储设备的兴起使得压缩对于OLTP工作负载也越发具有吸引力的：高流量的交互式网站可以通过使用压缩表同时使用具有执行频繁INSERT，UPDATE和DELETE操作的应用程序来减少其存储需求和每秒I/O操作数(IOPS)。 MySQL 5.6中引入的配置选项可让您调节压缩对特定MySQL实例的工作参数，其对于写入密集型操作的性能和可扩展性是很重要的： innodb_compression_level： 允许你向上或向下调整压缩程度，更高的值可以让你节省更多空间存储更多数据，同时在压缩时牺牲更多CPU周期，比较低的值可以让你在存储空间不重要时或者在数据不太适合被压缩时减小CPU开销。 innodb_compression_failure_threshold_pct： 指定了一个进行页压缩失败的百分比阈值，当它被超过时，MySQL开始在每个新的压缩页中增加一些额外的空闲的保留空间(padding)，动态的调整这个空余空间的大小，padding的上限是由innodb_compression_pad_pct_max指定的，它是页面大小的一个百分比。 innodb_compression_pad_pct_max：允许你调整每个页面中用于直接保存更改和插入数据的空闲保留空间(padding)的最大值(这样就无需每次更改和插入都再次压缩整个页面)。 值越高，就可以记录更多的更改(???)，而无需重新压缩页面。MySQL运行时,只有当需要昂贵分割操作的”压缩失败”达到上一个参数所指定的百分比时，才会为每个压缩表中的页面增加一个大小可变的空余空间(padding)。 innodb_log_compressed_pages：默认情况下，此选项被启用，以防止在恢复期间使用不同版本的zlib压缩算法时可能会发生损坏。 如果你确定zlib版本不会更改，请禁用innodb_log_compressed_pages以减少为修改压缩数据而生成的重做日志。 由于开启压缩时，内存中可能同时保留存在数据的压缩版本和未压缩版本，所以在OLTP工作负载下进行压缩时，innodb_buffer_pool_size配置选项的值可能会需要增加。
How Compression Works for InnoDB Tables MySQL文档翻译：InnoDB表压缩工作原理
原文： [MySQL 5.7 Manual 15.9.1.5 How Compression Works for InnoDB Tables] https://dev.mysql.com/doc/refman/5.7/en/innodb-compression-internals.html 本节介绍关于InnoDB表的压缩的一些内部实现细节。 这里介绍的信息可能有助于性能调优，但对压缩功能的基本使用并不必要。 压缩算法 某些操作系统在文件系统级别实现压缩。文件通常被分为固定大小的块，这些块被压缩后大小不固定，很容易导致碎片化。当块内的内容被修改时，在被写入磁盘之前，整个块都要被重新压缩。这些特性使得这种压缩技术不适合在update密集型当数据库系统中使用。 MySQL利用了广为人知的zlib库(基于LZ77压缩算法)来实现压缩功能。这种压缩算法在CPU利用率和减小数据大小方面都是成熟，稳健和高效的。该算法是“无损”的，从而可以始终从压缩形式重构原始的未压缩数据。 LZ77压缩通过查找要压缩的数据中重复的数据序列来实现压缩的目的。数据的具体形式决定了它的压缩程度，典型的用户数据通常会压缩50％或更多。 与一个应用程序执行的压缩或某些其他数据库管理系统的压缩功能不同，InnoDB压缩既适用于用户数据又适用于索引数据。在许多情况下，索引可以构成总数据库大小的40-50％以上，所以这带来的差异是显著的。当压缩对于某个数据集工作良好时，InnoDB数据文件（file-per-table的表空间或一般的表空间.idb文件）的大小是未压缩大小的25％到50％或更小。根据工作负载，压缩后的较小的数据库反过来很可能导致I/O数的减少，并以适度增加CPU占用率为成本增大了吞吐量。你可以通过修改innodb_compression_level配置选项来调整压缩级别和CPU开销之间的平衡。 InnoDB数据存储和压缩 InnoDB表中的所有用户数据都存储在包含B树索引（聚簇索引, clustered index）的页面中。 在其他一些数据库系统中，这种类型的索引称为“索引组织表”。 索引节点中的每一行都包含（用户指定的或系统生成的）主键和表的所有其他列的值。 InnoDB表中的辅助索引(secondary indexes)也是B树，包含键值对：索引键和指向聚簇索引中的某个行的指针。 指针实际上是表的主键的值，在需要除索引键和主键之外的列时，则需要查找到该值用来访问聚簇索引，进而访问到需要的列。 辅助索引记录必须始终可以放在单个B树页面。
InnoDB Page Compression MySQL文档翻译：InnoDB透明页压缩
原文： [MySQL 5.7 Reference Manual 15.9.2 InnoDB Page Compression] https://dev.mysql.com/doc/refman/5.7/en/innodb-page-compression.html InnoDB支持file-per-table表空间中的表的页级压缩。 此功能称为透明页压缩。 通过使用CREATE TABLE或ALTER TABLE指定”COMPRESSION”这个表属性来启用页面压缩。 支持的压缩算法包括Zlib和LZ4。 支持的平台 页面压缩需要稀疏文件(sparse file)和打洞(hole punching)支持。 页面压缩在使用NTFS的Windows上被支持，并且在以下MySQL支持的Linux平台发行版的内核级别提供了打孔支持： RHEL 7 and derived distributions that use kernel version 3.10.0-123 or higher OEL 5.10 (UEK2) kernel version 2.6.39 or higher OEL 6.5 (UEK3) kernel version 3.8.13 or higher OEL 7.0 kernel version 3.8.13 or […]
In-kernel memory compression 翻译:内核内实现的内存压缩
（发布于 April 3, 2013， 意译于12/9/2016） 原文链接 ：https://lwn.net/Articles/545244/ 另一个版本的翻译(有些句子没有翻): http://kernel.taobao.org/index.php?title=%E5%86%85%E6%A0%B8%E6%9C%88%E6%8A%A52013-04#In-kernel_memory_compression 吐槽 : 我的天呐！！翻译完我才发现有人翻译过了，早知道我就不自己翻译了，痛苦死我了。。 PS :内容我还没有完全理解，仅供参考，以原文为准。 阿姆达尔定律告诉我们一个计算机系统肯定存在一个瓶颈。历史上，对于很多工作负载这个瓶颈都是cpu，所以人们在不断提升cpu性能。所以现在，渐渐地，ram成为了瓶颈。有时当数据在ram和disk之间来回传递时，cpu就在一边干瞪眼呢。增大ram有时并不是一个好的或者经济的做法，更快的I/O或者ssd可以缓解问题，但是不能消除这个瓶颈。 如果可以增大ram中数据的有效容量，不是很好吗？既然cpu闲置，也许我们可以拿闲置的cpu周期来专注这件事。这就是内核内压缩的目标：用闲置的cpu周期来做ram中的压缩和解压缩。 算上刚刚发布的zswap，现在有3个内核内实现的压缩方法在被建议merge到内核的内存管理(memory management, MM) 子系统：zram, zcache和zswap。乍一看可能会让人觉得一个就够了吧，但是他们三个却有很大的不同，可能面向着不同的用户群。所以就像现在内核中存在很多文件系统一样，有一天内核中也会存在多种压缩方案吧，不过这还得李纳斯大神和主要的内核开发者说了算。。。为了方便说明，本文把这些方案统称“zproject”，并对比了这些方案。我们先说明一些关键原则和压缩遇到的挑战。然后我们会从三个层次说明并详细地阐释这些zprojects设计上的不同选择，之后我们还讨论zprojects怎么和内核其他部分交互，最后给出结论。 压缩基础 要让压缩在内核中工作，内核必须把字节序列放入内存中再压缩，之后内存中也应保有压缩后的版本，以备这些数据被再次使用。压缩状态下的数据不能被读写，所以对压缩版本的数据再进行解压缩后才能继续读写这些数据。 字节序列压缩多少都可以，但还是以一个固定大小的单元压缩较方便。贯穿整个内核的一种基本的存储单元是page，一个page由PAGE_SIZE个字节组成，通常的linux支持的架构中，page的大小是4KB。如果这个page对准了PIGE_SIZE的地址分界，那么它就被称为page frame。对于每个page frame，内核在ram中都有相应的struct page结构。所有这三个zprojects都用page作为压缩的单元，并且通过开辟和管理page frames来存储压缩页。 有很多可用的压缩算法，但总的来说，高压缩比意味着高cpu周期，运行的快的算法一般压缩比较低。在时间效率和压缩率之间做出权衡很重要。这三种zprojects，默认都使用内核lib/文件夹中的LZO(1X)算法，这种算法做出了很好的权衡。然而，算法的选择还是很灵活的，也许cpu运行的算法还会被一些特殊架构的硬件压缩引擎取代呢。 一般，存在一些数据一会儿压缩一会儿解压缩的循环，数据序列大概和序列中的字节数成正比。因为页比较大，页压缩和解压缩都是很昂贵的操作，所以我们希望限制这些操作的数量。因此我们必须谨慎的选择哪些页要被压缩，尽可能找到那些可能会被再次用到同时最近不会用的页，以免把cpu时间浪费在重复的压缩然后立刻又解压缩上。因为压缩页不能直接访存某个字节，我们必须要保证内核清楚地辨识出哪个是压缩页，避免对压缩页中的字节尝试cpu的线性地址操作，同时保证压缩页可以被找到并可以在被访问时解压缩。