PostgreSQL与透明压缩

PostgreSQL中文社区 2020-11-27

2715

作者简介

郑宁，ScaleFlux公司系统团队负责人。于2009年在浙江大学电子科学与技术专业获得学士学位，于2012年在浙江大学电路与系统专业获得硕士学位，于2015年在伦斯勒理工学院电子工程专业获得博士学位。2016年至今就职于ScaleFlux公司，主要工作方向为可计算存储在应用中的加速。

1. 数据库中的空间管理

数据库是现代信息管理系统的核心。它是由一批数据组成的有序集合，能有效地存储和查找数据，常见的操作包括增、删、改、查等等。

通常情况下，数据库中一般都使用了log机制来提升写入的效率。写入数据库的数据，先固化在log中，在之后的某个时间再搬移至真正有序存储数据的地方。每个数据库都有自己的存储数据的机制，常用的包括基于B+树的结构^【1】以及基于LSM（log structure merge）树的结构^【2】，如图1所示。

（a）B+树

（b）LSM树

图1. （a）B+树和（b）LSM树

B+树常见于关系型数据库中。对于应用B+树的关系型数据库，数据一般存储在树的叶子结点上，数据通常以页的形式组织起来，一个页面（常见的是8KB或16KB）内包含多条数据，页面之间数据有序排列。这里可能就会引入一个空间放大的问题，比如一个16KB的页面，可能只存储了一条100B的数据，但是在存储设备中，仍然占据了16KB的空间，而且在写入时也引入了写放大问题。LSM树常见于NoSQL数据库中，数据的存储分为多个层次，一般越往底层对应的存储空间越大，数据通过归并排序（merge sort）从上一层迁移到下一层。当相同的数据在不同的层次之间移动时，就会引入写放大问题。

此外，数据库在使用时，一般都是运行在文件系统之上，例如Ext4和XFS。在数据库频繁的写入场景中，不可避免地会引入文件系统级别的额外写入，比如文件系统日志的写入或者文件系统元数据的更新等等。这些额外的写入，在很多场景中（尤其是在数据安全性要求比较高的场合）会造成相当程度的写放大，再叠加上数据库本身存储数据时的写放大，会使得写放大问题更加严重。

本文中，我们以PostgreSQL为例，来说明数据库中的一些固有问题，以及如何利用透明压缩来解决这些问题。

2. PostgreSQL

PostgreSQL是目前世界上最先进的开源数据库^【3】，目前在DB-Engines Ranking榜单中稳定在第四位，而且得分还在持续上升^【4】（截止到2020年11月，DB ranking的排名如图2所示）。作为一个开源项目，PostgreSQL在使用时并不需要应用许可，并且提供了丰富的特性支持（例如表继承、定制数据类型、规则系统等等），因而正受到越来越广泛的关注。

图2. DB ranking（截止到2020年11月）

PostgreSQL中有一个区别于其它数据库的调优参数——填充因子（fillfactor）。该参数是一个介于10和100之间的百分数（默认值是100），用来表示数据页上有多少比例的空间可以用于插入操作，而剩余的空间则用于更新操作。因此，当填充因子较小时，每个页面上将预留更多的空间用于放置一个旧行的新版本，这比把新版本放置在其它页面上更有效，从而可以获得更高的性能。但是，较小的填充因子也意味着预留的那部分空间在开始时并不会填入有效的数据，因而在获得更高性能的同时，也浪费了不少的存储空间。所以这里存在着一个空间和性能上的取舍。这种取舍对于传统的块存储设备，是不可避免的。要降低这种取舍的程度，就需要在数据存储之前进行压缩，尽量减小写入存储设备的数据量，从而降低空间放大和写放大。

3. 软件压缩与透明压缩

虽然基于CPU的软件压缩有利于减小空间放大和写放大，但它也具有自身的一些限制：

· 需要应用程序自身集成压缩和解压缩的模块/算法。比如PostgreSQL中只实现了WAL层面的压缩，并没有实现主存储中数据页的压缩（而这些数据恰恰才是PostgreSQL中最核心且存储量最大的部分）。

· 通过软件进行压缩和解压缩，占用了系统中宝贵的CPU资源。对于稍微复杂的压缩算法来讲，由压缩/解压缩带来的CPU开销是无法接受的，而且这种方式的可扩展性也是一个问题。

· 对于某些应用来讲（尤其是关系型数据库），压缩所带来的收益还主要取决于数据的可压缩性。这是由于数据的写入要和存储设备的块边界对齐。比如，一个16KB的数据页，压缩后可能只有9KB，但是在存储时也要占用12KB的空间（保证4KB对齐），这样可以方便上层应用的管理。

由于当前我们面对的是互联网和数据中心大量的存量业务，以侵入性的改动赋予业务压缩和解压缩的能力，必然会面临诸多的挑战。而且，上述后两项的限制，也使得即使集成了软件的压缩和解压缩功能，获得的收益也有可能大打折扣。要从根本上扭转这种局面，就需要一种既不会侵入业务，也没有CPU开销，同时空间收益尽量大的压缩方案。这种方案，就是透明压缩。

在透明压缩中，对于写入块设备的数据，由块设备首先对其进行压缩，然后将压缩后的数据写入物理存储空间；对于数据的读取，块设备首先从物理存储空间读出压缩后的数据，经过解压缩后传给上层。当数据具有可压缩性时，实际写入物理存储空间的数据量，会小于逻辑的数据写入量，由此便产生了逻辑空间和物理空间的不对称，所以两种空间之间需要实现变长的映射，这是与传统块设备中逻辑空间和物理空间的定长映射最大的不同，如图3所示。在传统的块设备中，一个4KB的逻辑块地址（LBA），总是对应一个4KB的物理块地址（PBA），这种等长的映射，大大简化了设备驱动的设计，但是却可能引入空间放大和写放大问题。在透明压缩中，一个4KB的LBA经过压缩后，对应到物理空间上最多为4KB，更多时候会小于4KB（数据具有可压缩性）。由于逻辑空间和物理空间的映射是变长的，因此就需要设备的驱动去维护一张记录这种变长的映射表，所有的读写，不管是来自前台主机端的，还是后台设备端的，都需要去访问这张映射表，如何在驱动中高效地实现这种映射并保证读写性能基本不受影响，是一个巨大的挑战。但另一方面，一旦我们实现了透明压缩，它所带来的优势也是显而易见的：既节省了CPU的开销，又缓解了物理空间浪费和写放大的问题，还对现有软件栈完全透明，而且可以线性扩展。因此，透明压缩对于互联网和数据中心的多种业务，具有很强的适用性和很高的潜在使用价值。

（a）定长映射

（b）变长映射

图3. 逻辑地址和物理地址的（a）定长映射和（b）变长映射

对于PostgreSQL，其写入块设备的数据，经过透明压缩后，写入的实际数据量很大可能会小于原始的数据量。当设置更小的填充因子时，每个页面预留的逻辑空间会填充全0数据，这些全0数据具有高度的可压缩性，经过透明压缩后只占用很小的物理空间。这样在得到更高性能的前提下也没有浪费更多的物理空间，打破了传统块设备中性能和空间之间的取舍逻辑。此外，对于运行PostgreSQL所应用的文件系统而言，其写入的日志以及元数据往往也具有很高的可压缩性，这些数据经过透明压缩后，所写入的实际数据量和占用的实际空间也会大大减少（在数据安全性要求较高的场合运行数据库应用时，由文件系统日志和元数据引入的写入量是相当可观的）。

4. PostgreSQL在透明压缩上的收益

为量化PostgreSQL在透明压缩上的收益，我们选用了3.2TB ScaleFlux CSD 2000作为评估对象。CSD 2000是一款实现了透明压缩的NVMe SSD，其压缩以4KB为单位，压缩吞吐可以达到2GB/s以上，压缩能力与Gzip level 6基本相当。同时，我们选用3.2TB Intel P4610作为对比对象。测试中，我们以sysbench为基准来衡量和比较PostgreSQL在两种SSD下的各种表现，包括存储容量的节省，OLTP性能的提升以及写放大的减小等方面。Sysbench的测试配置参数为8张表和64个线程，每张表包含3亿条记录。硬件环境为Intel E5-2667 32 core@3.2GHz和256GB内存。

4.1 存储容量

Sysbench产生的数据具有可压缩性，因此我们首先关注在PostgreSQL中使用透明压缩后存储空间的节省情况。标1对比了在填充因子分别为100和75时P4610和CSD 2000的逻辑空间和物理空间的使用情况。

表1. PostgreSQL在不同条件下的逻辑空间使用量和物理空间使用量

从表中可以看到，在填充因子为100时，两种SSD下的逻辑空间使用量均为631GB，但是由于透明压缩的存在，CSD 2000的物理空间使用量只有234GB（没有透明压缩时物理空间使用量等同于逻辑空间使用量），相对于P4610，节省了63%左右的物理存储空间。而当填充因子为75时，P4610的逻辑/物理空间占用上升至830GB，而在CSD 2000中，虽然逻辑空间占用是830GB，但是物理空间占用只从234GB上升至248GB，这是因为在CSD 2000中，数据库页面中预留的用于更新操作的逻辑空间（全0数据）高度可压缩，并不占用大量的物理空间。这正是逻辑地址与物理地址的变长映射带来的优势。

4.2 性能

在更少的物理空间的占用下，我们接着对比PostgreSQL在两种SSD中OLTP的性能，如图4所示，图中各种测试场景下的性能均以P4610在100%的填充因子下的表现进行了归一化。可以看到，在所有测试场景中，CSD 2000的性能表现或者与P4610接近，或者更高。因此，有了透明压缩的加成，PostgreSQL不仅获得了物理空间的节省，也达到了相似甚至是更高的性能，实现了空间和性能上的双赢！