InnoDB 数据表压缩原理与限制
压缩理念
通过提高CPU利用率和节约成本,降低数据库容量及I/O负载,从而使数据吞吐率得到显著提高。
压缩原理
压缩表减少了磁盘上数据库的大小,使得用户不必频繁地操作写入和读取便可以访问数据。对于 InnoDB的工作量以及传统的用户表而言(特别是在某些读取密集型的应用中,内存有足够的空间存储常用数据),数据压缩不仅大大减少了数据库所需的存储空间,而且还减少了 I/O的工作量,提高了数据吞吐率,从而节约开销处理成本。节省存储成本固然重要,但是减少 I/O成本更为关键。
在InnoDB中,是以16K的页(Page)为基本的存储单位的。我们知道,InnoDB是的数据是在Clustered index中存储的,在Secondary index中仅存储对应数据的PK。Clustered index和Secondary index都是B-Tree结构的,所以对InnoDB数据页和索引页的压缩很大程度上就是对B-Tree节点页的压缩。
在InnoDB中,除了B-Tree节点页,还有一类数据页(Page),称为“overflow page”。当需要存储Long column时,如果当前页能够完全存储全部字段时,则存储在当前页中;如果当前页不足以存储全部,则InnoDB选择最长的字段,将其存储到一个单独的页中,我们称这样的页为“overflow page”,而原数据页仅仅需存储一个20Bytes的指针。参考下图:
压缩使用的是zlib library中的LZ77算法。
压缩限制
为了保持数据库文件的向下兼容性,只有在使用innodb_file_format配置参数来启动“Barracuda”数据库文件格式时,压缩才能被指定。在 InnoDB系统表空间压缩表也是不可行的。系统表空间(space 0, the ibdata* 文件)不仅包含用户数据,还包含InnoDB内部系统信息,永远不能被压缩。因此,压缩只适用于存储在表空间的表(以及索引)。
什么时候使用压缩
通常情况下,对于字符串数量适中的表来说,读取数据比写入数据速度更快,压缩性能最佳。压缩时应努力减少数据文件的大小,影响其压缩效率的决定性因素就是数据本身。在一组数据中识别重复的字符串可以撤消压缩。完全随机的数据是最糟糕的。传统的数据往往有重复的值,压缩起来也相对有效。字符串也往往很容易压缩,不管它是定义在CHAR, VARCHAR, TEXT上还是BLOB列上。另一方面,某些表包含了大部分的二进制数据(整数或浮点数)或者之前被压缩的数据(例如JPEG或PNG图像),压缩起来通常比较困难。
除了考虑选择哪些表进行压缩(以及页面大小如何设置),工作量是衡量性能的另一个关键因素。InnoDB为压缩的数据设置了修改日志,如果应用程序以读取为主而不是以更新为主,那么,在索引页占用完每一页“修改日志”的空间之后,只有少数的页面需要进行重组和重新压缩。如果更新主要改变的是非索引列或者一些包含了碰巧被存储为“off-page”的BLOBs及大的字符串的列,压缩的开销是可以接受的。如果表中唯一更改的是使用单递增主键的INSERTs语句,并且不存过太多非聚集索引,那么,便没必要重组或重新压缩索引页。由于InnoDB能够在压缩页面“标记删除”以及删除记录,并以此来“替代”修改未压缩的数据,因此,在表中进行DELETE操作是相对有效的。
对于某些环境,加载数据所耗费的时间与运行检索所需的时间同样意义重大。特别是在数据仓库环境下,很多表的属性为只读或者以读取为主。在这种情况下,除非在更少的磁盘读取中或存储成本上造成的节约效果是显著的,否则,从增加的加载时间角度出发,压缩付出的代价实在不能令人接受。
从根本上说,当CPU时间可用于压缩及解压数据时,压缩效果最佳。因此,如果工作量是由I/O引起的,而不是由CPU引起,压缩便能够提高整体性能。所以,在使用不同的压缩配置测试应用程序时,你应该在一个类似于产品系统计划配置的平台上进行测试。
压缩过程
当使用压缩存储的页面,当Buffer Pool载入后,会将其解压。这时,该页面在Buffer Pool中同时存在“压缩版”和“解压版”。当Buffer Pool需要驱逐这些页的时候,有两种情况会发生:如果InnoDB认为当前应用是IO-Bound,相比CPU还有额外能力来做解压操作,则InnoDB选择仅驱逐页面的“解压版”;否则InnoDB会将页面的两个版本同时驱逐出去。也就是说Buffer Pool会是下图的状态:
![](http://liuxin1982.blog.chinaunix.net/attachment/201303/19/24485075_1363675786flSa.png)