我将对 PostgreSQL 15 中的一个新功能–服务器端备份压缩的性能进行深入研究。我在之前的测试中使用网络链接时很慢，并且会受到 VPN 链接和 SSH 隧道的影响。我使用可压缩pgbench 数据进行测试，在我进行这些测试时，我已经添加了对 LZ4 压缩的支持，但还没有添加对 Zstandard 压缩的支持。但是现在我们不仅可以选择 Zstandard，而且还可以使用该库的多线程功能。所以我想知道在更快的网络链接、更好的测试数据集以及我们现在可用的所有压缩算法上，这一项新功能能发挥多大的作用。
为了弄清楚这一点，我下载了https://wiki.postgresql.org/wiki/Sample_Databases 中提到的英国土地注册数据，并将其加载到 PostgreSQL 数据库中，该数据库是根据 master 分支的最近提交构建的，它将最终成为v15，生成的数据库为 3.8GB。然后我尝试在这台机器和位于同一 EDB 内部子网上的另一台机器之间进行一些备份，两台机器都报告有 10 Gb 以太网，iperf 报告机器之间的带宽为 8.73 GB/s。
我尝试使用——Ft（tar 格式）和——Fp（纯格式）进行备份，在每种情况下都测试了各种形式的服务器端压缩。当以 tar 格式进行备份时，pg_basebackup 基本上只是将服务器生成的文件写入磁盘。当它以纯格式获取时，pg_basebackup 解压缩并提取存档。结果如下：
| Compression | Size -Ft (GB) | Time -Ft | Time -Fp |
|---|---|---|---|
| none | 3.8 | 17.0 | 18.1 |
| gzip | 1.5 | 234.9 | 233.1 |
| lz4 | 2.0 | 31.5 | 35.1 |
| zstd | 1.3 | 56.1 | 59.1 |
| zstd:workers=2 | 1.3 | 26.4 | 29.5 |
| zstd:workers=4 | 1.3 | 15.0 | 21.8 |
| zstd:workers=6 | 1.3 | 11.5 | 23.0 |
| zstd:workers=8 | 1.3 | 9.9 | 22.9 |
| zstd:workers=12 | 1.3 | 10.3 | 20.3 |
| zstd:workers=16 | 1.3 | 10.0 | 20.5 |
| zstd:workers=20 | 1.3 | 10.2 | 20.3 |
| zstd:workers=24 | 1.3 | 10.1 | 21.0 |
在这里以及在我运行的所有其他测试中：
gzip 压缩——当前 PostgreSQL 版本支持的唯一类型，然后只在客户端时是会非常缓慢。其他的情况下运行速度比较快，具体视情况而定。 LZ4 的压缩不如 gzip，但它是最快的单线程算法。单线程 Zstandard 比 gzip 压缩得更好更快，但不如单线程 LZ4 快。如果你有空闲的 CPU 资源，你可以在 Zstandard 压缩下配置 8 个左右的内核，能获得更好的压缩比和最快的速度。事实上，当使用 tar 格式时，并行 Zstandard 压缩比不压缩备份快大约 40%。
如果这些机器之间的网络连接特别慢，那么执行备份所需要的时间将取决于备份大小，就像在我之前的文章中提到的一样，数据库压缩了大约 8.9 倍，而备份速度提高了大约 8.9倍。在这里使用更真实的数据集，即使使用 Zstandard，压缩率也只有大约 2.9 倍，因此如果网络速度慢到极致，我认为使用 Zstandard 会给我们带来大约 2.9 倍的性能提升。然而但压缩使用 tar 格式时，仍然可以带来大约 1.7 倍的加速。这是为什么？
基本上，这种速度的提升主要归因于 pg_basebackup 需要做的工作更少。当备份大小从 3.8GB 下降到 1.3GB 时，pg_basebackup 需要从网络接收的数据减少了 2.5 GB，需要写入磁盘的数据减少了 2.5 GB。如果网络足够快，传输 2.5 GB 数据的成本不是一个太大的问题，但内核仍然必须将从网络接收到的所有数据复制到 PostgreSQL 的地址空间，然后它必须继续从PostgreSQL 的地址空间进入内核缓冲区缓存，以便可以将其写入磁盘，最后必须将数据实际写入磁盘。额外的复制和实际的磁盘写入都是需要成本的。
在纯格式中，与未压缩的情况相比，我们没有看到任何性能提升。事实上，即使是并行 Zstandard 也显示出轻微的回归，而其他压缩方法则更差。因为我们现在必须解压缩并提取档案，pg_basebackup 最终不得不写入完整的 3.8GB数据。不管传输中的数据使用什么压缩方法，我们仍然得到了需要在服务器端向网络写入更少数据并在客户端从网络读取更少数据的好处，但是在快速的网络连接上，这并不足以支持在服务器端压缩整个输入，然后在客户端解压缩所有内容。
我认为用更大的数据集测试它是如何工作的会很有趣，这样我们就可以在更长的时间内使本地磁盘保持饱和状态，也许还可以使用高度不可压缩的数据集。关于如何提高 pg_basebackup 的效率，我也有一些想法。总的来说，这些最终的测试结果非常令人兴奋。我不认为用户在服务器上有足够的备用 CPU 容量来使用并行 Zstandard 压缩将是一个不常见的情况，如果数据集可合理压缩，这样做的好处可能非常显著。
