PostgreSQL 英文原文：Running PostgreSQL on Compression-enabled ZFS

“PostgreSQL支持压缩吗？”这是我们从客户里得到最多的问题，也很容易明白他们要为什么这么问。他们大部分都会生成和收集大量的日志和事件流数据，同时把它们用文本格式保存，如JSON或CSV。通常这些文件会接着用像gzip的工具压缩，压缩率有3x-4x也并不少见。这个问题其实是你牺牲这些存储来保存那些你一加载就存到不支持压缩数据库的数据。

不幸的是，这个问题并不能明确地用“是”或“不是”来回答。如果在某些满足PostgreSQL的存储层的条件下使用某些机制可明显地压缩可变长度类型，如常见的超大属性存储技术，或TOAST。问题是TOAST的压缩不会生效，除非行的大小超过了TOAST_TUPLE_THRESHOLD的值（在大部分系统设置为2KB），同时即使是在发生的时候TOAST智慧压缩包含在行里的可变长度类型。TOAST在满足它的既定目标上做得很好，这通过压缩一个行来让它适合PostgreSQL的8KB高速缓存页来避免行链接的开销和复杂性，但它不是通用的压缩目的的替代品。

ZFS登场

在PostgreSQL数据库不支持通用压缩功能的情况下，我们想知道，是否可以利用文件系统的压缩功能，获得一些相同的裨益。在过去的十年中，已经有一些文件系统加入了透明的压缩功能。目前最成熟的选择是，Sun 公司最初设计的一个开源的文件系统 ZFS。除了压缩功能透明之外，内嵌的压缩功能还提供了几种压缩格式以供选择（gzip，LZJB 和 LZ4），ZFS 还支持一大堆其他强大的功能，包括软件RAID，虚拟存储池，快照，重复数据删除和加密。 ZFS 最大的局限性是它的 CDDL 许可证，导致它不能和Linux内核一起发行。最近，这种情况已显著改善，ZFS Linux 项目为许多主要的Linux发行版提供ZFS包。

在ZFS文件系统上运行CitusDB

为了验证我们的直觉：ZFS可以用来替换CitusDB数据库自身的压缩功能，我们决定测试运行在ZFS上的CitusDB性能和压缩功能，并且与默认使用ext3文件系统环境下的测试结果进行比较。

我们在两个使用c1.xlarge的实例的EC2上进行这个测试，并初始化安装为Ubuntu 12.04 LTS。我们在这两个节点上安装CitusDB2.0，然后以1:1管理者/工作者模式配置这两个节点。为了获得样本数据，我们从GithubArchive数据集提取了38GB的事件日志。我们使用了与GithubArchive项目里所提供的脚本相类似的脚本把样本数据从JSON格式转换为CSV格式，然后使用STAGE命令及GithubArchive模式把所

得结果装载到CitusDB数据库。在装载操作完成以后，我们通过工作者节点的数据目录的大小来计算压缩率。

结果表明ZFS在使用了默认的压缩编码LZJB后获得了1/2压缩率，而使用gzip压缩编码后压缩率可接近1/4。

     在被这些结果搞得我们晕头转向之前，我们需要量化压缩在性能方面的反作用。运行具有压缩功能的ZFS迫使文件系统在每次磁盘读写操作之上要做附加的工作。认为这对整体性能起到反作用是很有道理的，但我们真正需要回答的问题是是否这个性能的反作用是非常的巨大以致于它超过了获得的好处。  为了确定这个，我们设计了一个由七个查询语句组成的简单的基准测试，然后我们对前一步骤装载的38GB的数据集执行这个基准测试。注意到CitusDB工作者节点将并行处理表段是非常重要的，这隐含着我们也正在测试文件系统中或者内核中处理并发读请求的IO调度器。

至少可以这么说，这些结果令人吃惊。我们知道启用压缩功能使得CPU在每次读写之后还要做附加的工作，因此当底层数据使用gzip压缩时，查询1运行速度几乎快四倍，这怎么可能呢？对这个违反直觉的结果的解释取决于这样的事实：这些查询是受IO限制的。换句话说，限制这些查询性能的主要瓶颈不是CPU速度，而是数据从磁盘读取到内核缓冲区缓存的速率。在启动了压缩的情况下，这些操作花费了较少的时间，因为需要在磁盘和缓冲区缓存间传输的数据较少。另外，查找时间也降低了，因为压缩减少了磁盘上数据逻辑块之间的物理距离，并且由于磁盘缓冲区在同样大小的磁盘空间里存储更多的数据，其命中率也得到了提高（注意，我们正在讨论的是磁盘缓冲区-因此最后一个优点不适用于缓冲区缓存，因为ZFS在存储数据到缓冲区缓存之前要对这些数据块解压缩）。

当我们对这篇博客文章做背景研究的时候，我们也有机会研究ZFS与老的文件系统架构比如ext3之间除压缩之外的某些其他不同的特性。其中最大的一个不同是ZFS调度磁盘IO的方法。为了避免后续的请求对磁盘控制器请求队列的洪泛冲击，ZFS的磁盘调度使用了显式IO优先，IOP重新排序和时限调度。我们很想看看实际中这些技术是怎么良好运行的。为了明确这个问题，我们删除了旧的githubarchive表，并且装载新的拷贝，此时这个表被划分为23个表段而不是两个表段，每个查询所运行的总的目标数据量保持不变，不过现在CitusDB将把工作划分到23个进程上，而不是两个进程上。

我们需要说明的第一件事情是这个图表的水平轴比前一节的图表水平轴大两倍。值得一提的第二件事情是这个测试是以ext3为通道的。使用两个进程执行这些查询平均需要花费350秒，而当使用23个进程处理时，现在要花费大约两倍的时长。这样的结果令人失望，但对那些熟悉在常规文件系统上顺序读和随机读性能特征的人来说毫不奇怪。磁盘处理顺序读比处理随机读要快很多，因为前者不需要对磁盘的读头进行重定位。在这两个运行各自CitusDB工作者进程的测试里都采用了顺序读请求。然而，如果IO调度器仅仅按照IO请求到达的顺序进行排队的话，那么顺序读这个特性将不可用，一切开始要看随机读了。相比之下，ZFS的IO调度器重新对IO操作进行排序，试图限制从一块查找到下一块磁盘所花费的时间，不过，我们在这儿得到的结果支持了这个结论：ZFS调度方法确实起到了作用。 从这个实验中获得了什么呢？ 首先我们成功的证明了我们的假设： 在不降低CitusDB性能的情况下（并且通过对PostgreSQL的扩展），ZFS对事件流和日志数据集可能获得1/3-1/4的压缩率。实际上，我们展示了ZFS和压缩确实提高了受IO限制的查询的性能。最后，我们也下定决心让Linux上的ZFS快速成熟起来，并可能在不久的将来成为企业部署中切实可行的选项。

Carl感谢Metin Doslu对这篇文章里使用的背景研究和结果所做的贡献。 本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务