PG 15传闻中的超级令人激动的功能大多数跳票了，年初我也写过一个关于PG15新功能跳票的文章。PG 15 BETA已经发出几个月了，似乎PG 15里令人激动人心的功能不多，不过从长长的新功能列表里，我还是能够从中学到不少东西。数据库的发展是和现代硬件技术的发展密切相关的，而数据库在某一个方面的突破，可以为应用提供更大的舞台，让应用能够更加适应某些特定场景实际上经过几个重要特性的跳票之后，我对PG 15的期待主要集中在FULL PAGE WRITE的优化上了。以前我也多次写文章研究过PG的WAL产生以及CHECKPOINT对高负载应用写入性能的影响。其实这些性能影响大部分来自于FULL PAGE WRITE。因为当某个脏块在CHECKPOINT完成后的次被写入的时候，都需要做一次FULL PAGE WRITE，以避免数据库需要恢复时出现块断裂的情况。而FULL PAGE WRITE大规模产生的时候，因为WAL的写入量大大增加，就会导致高并发写应用的性能问题。实际上，当我们在做pg_basebackup等在线备份操作时，也是会引发大量的FULL PAGE WRITE的。缓解这个问题的方法是加大CHECKPOINT的延时，让两次CHECPOINT的间隔更长一些，这样就会大量减少FULL PAGE WRITE。加大CHEKPOINT的延时也是一个双刃剑，因为这会让数据库在恢复时需要RECOVER更多的页，同时也会在一个CHECKPOINT时集中写入大量的数据块。在瞬时对IO产生更大的影响。在PG中关闭FULL PAGE WRITE也是一个选项，只不过需要找到支持PG关闭FULL PAGE WRITE的文件系统或者存储系统。我们以前曾经在ZFS上尝试过关闭FULL PAGE WRITE，效果是相当不错的。只不过在我们的大多数PG运行环境中并没有使用ZFS，因此对于PG 15在FULL PAGE WRITE上的优化，我们还是很期待的。我曾经也考虑过通过WAL压缩来缓解FULL PAGE WRITE的问题，在PG 12上我们做过一个测试，打开WAL压缩。只不过打开WAL压缩后，PG数据块的高并发写入性能并未提升，反而略有下降。能够从以前的PG 12的WAL压缩中获得性能提升的场景十分有限。PG 15的WAL压缩有了一个十分令人兴奋的改进，除了支持PGLZ外，WAL压缩还支持LZ4和ZSTANDARD两种压缩算法。从官方的对比来看，ZSTD是一种平衡了压缩解压吞吐量与压缩比的十分的压缩算法，而LZ在压缩比上虽然不如ZSTD，但是在压缩吞吐量上有着特别的表现。这两种压缩算法的引入，必定会大大改善WAL压缩的性能。因为时间关系，我们目前还没有全面开展PG 15的测试，我想还是等正式版出来后再做完整的测试。不过从目前国外一些朋友对PG 15的测试来看，还是十分令人期待的。我们根据Mark Callaghan的测试用例来看一看效果吧。和我们的预期相同，使用以前的pglz，对于仅有PK的场景影响并不大，对于PG来说，次数据写入，都是创建的新块，不同的算法之间的影响还不算太大。但是对于其他场景影响较大。而使用LZ4的效果，装载性能有了明显的提升。zstd在有多个索引时的数据装载表现出了较好的性能。不过从上面的测试来看，还是比较简单的，因此这个测试结果页并不说明太多的问题。不过有一点是可以确定的，那就是LZ4和ZSTD的引入，会大大优化WAL 压缩的性能，从而缓解FULL PAGE WRITE的问题，也可以大大减轻DBA优化CHECKPOINT的工作。CHECKPOINT的优化可能会在大多数场景下变得更简单了，我们只要根据自己的场景需求，选择设置WAL压缩参数就可以了。挺巧的是，在PG 15里，增加了一个新的权限:pg_checkpointer。以往checkpint命令只能由超级用户来执行。而PG 15里，只要是授予这个权限的用户，都可以在自己的应用里执行checkpoint命令了。将checkpoint命令的权限下放，是PG 15细粒度权限控制优化的一部分。不过既然敢下放权限，那就说明checkpoint带来的副作用已经可控了。随着现代硬件的发展，IO问题已经得到了大大地缓解，同时因为WAL压缩的优化，也为checkpoint权限下放提供了有力的支撑。不过业务场景十分复杂，这个权限还是不要随便授予，因为目前来看，我还没有想清楚，这个权限下放的真实好处在什么地方，什么场景下，应用需要自己去控制checkpoint。如果有一天，DBA发现一个挠头的IO性能问题，是因为某个应用系统频繁执行checkpoint引发的，那就麻烦大了。对于开发人员来说，让每条记录尽快写盘肯定是件喜闻乐见的事情，而对于DBA来说，那可能是个灾难。
