认识达内从这里开始

数据库架构开发与应用是大多数软件编程开发程序员都需要熟练掌握的一个编程技术，而本文我们就通过案例分析来简单了解一下，数据库数据压缩应用分析。

1、传统关系数据库数据压缩实现

传统关系型数据库理论和架构在20世纪70，80年代被确定下来，直到2010年的移动互联网时代之前，其架构都没有大的改变。早期数据库系统，CPU算力较弱，而数据压缩是非常耗费CPU的操作，因此传统基于页面行存的关系数据库中一开始都没有为数据压缩进行顶层设计。到互联网时代面对海量数据，传统的关系型数据库也开始考虑增加压缩特性，降低用户的存储成本。

传统的关系型数据库的压缩，主要有两个方向，一个是针对OLTP，即事务处理的workload提供的方案。另外一种是针对OLAP，即数据分析型的workload提供的方案。

针对OLTP的workload提供的方案主要是基于页面的通用压缩。OLTP型的workload，通常需要对行内的数据进行更改，一般来说，采用行存储性能较好。这种负载下，一个页面内的行可能会被上层应用反复修改，因此行与行之间的数据压缩基本难以进行，主流厂商一般都是才用了基于页面的整体通用压缩。以MySQL的InnoDB引擎为例，一个页面未压缩前，在磁盘上占用16KB的空间，压缩后只有11KB，那么按照4KB进行IO对齐的话，压缩后的数据占用12KB的磁盘空间。InnoDB的这个页面在文件中仍然占用16KB的空间，但是利用操作系统的稀疏文件(SparseFile)特性，操作系统实际只为这个页面申请了12KB的磁盘空间，因此可以节约4KB的空间。

这种压缩方式也会带来很多问题：

如果一个页面被修改很频繁的话，反复的读出和写入数据的过程中需要进行压缩/解压，对CPU的开销也不可忽略。

如果页面被修改并压缩后，其大小比原来增加了，如原来压缩后是12KB，现在压缩后是13KB。操作系统需要为新增加的数据分配磁盘空间，此时分配的磁盘空间通常都不是和之前的12KB的空间连续的。这样对这个页面的读取，IO是不连续的，性能会变差。

总结起来就是，传统数据库的基于行存页面的压缩，通常情况下，只能帮助用户节约一部分存储空间，并不会带来性能的提升。如果运用不当，性能有可能还会下降。

OLAP型负载的数据压缩，通常数据都是只读的，没有了数据更新的限制，数据压缩做的非常激进。在页面内的数据可以不按行存，而是按照列存。相同列的数据放在一起，可以做非常多的压缩，如常量编码，字典编码，Delta编码，RLE编码等等。这些数据编码可以有效减少页面的存储空间，同时不会对数据查询有任何的影响。由于OB也采用了类似的压缩方案，因此这里的列存压缩方案，会放到OB的压缩实现中去讲。

传统的基于页面存储的关系数据库还有一个问题就是，OLAP和OLTP两种负载的不可调和性。要想OLAP处理能力强，数据一般都是行存的;要想OLTP处理能力强，数据需要是列存的。如果要想两者都要(小孩才做选择，成年人全都要)，那么必须要部署两套异构的存储(尽管数据库服务程序可能是一个/一套)，一套专门用于OLTP，一套用于OLAP，二者之间还需要通过数据链路进行同步。这无疑显著增加了硬件和运维管理的成本。

2、LSM树数据压缩优势综述

基于LSM的存储引擎，其在磁盘上的数据，在下一次合并之前，都是只读而不会被修改的。通过BigTable和LevelDB引入的SSTable，SSTable内部再分Block存储的概念目前已经是LSM树实现的标配。这些只读的Block，类比传统数据库的页的话，是非常好的压缩目标。相比OLTP数据库的页面，SSTable的Block压缩有以下几个优势：

数据只读，不会因为反复修改而带来反复的压缩/解压的CPU消耗，也不会因为反复修改带来的数据膨胀导致的IO不连续。

数据内聚，一个Block内通常有几十乃至更多的行，可以在Block写入的时候一次性的针对这些行做列式压缩，可以得到更好的压缩比，而且可以加速后续的查询。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。