PG15传闻中的超级精彩功能大多被错过。年初的时候，我也写过一篇PG15新特性略过的文章。PG15BETA已经发布几个月了，PG15似乎并没有太多令人兴奋的功能，但从一长串的新功能中，我还是可以从中学到很多东西。数据库的发展与现代硬件技术的发展密切相关，数据库在某一方面的突破可以为应用提供更大的舞台，使应用更加适应某些特定的场景。事实上，在经历了几次重要的功能反弹后，我对PG15的期望主要集中在FULLPAGEWRITE的优化上。之前也写过很多篇文章，研究PG的WAL生成和CHECKPOINT对高负载应用写性能的影响。事实上，这些性能影响大部分来自FULLPAGEWRITE。因为在CHECKPOINT完成后第一次写入脏块时，需要做一次FULLPAGEWRITE，避免数据库需要恢复时出现blockbreak。当大规模产生FULLPAGEWRITE时，由于WAL写入量大幅增加，对于高并发写入应用会造成性能问题。其实我们在做pg_basebackup等在线备份操作的时候，也会触发大量的FULLPAGEWRITE。缓解这个问题的方法是增加CHECKPOINT的延迟，让两个checkpoint之间的间隔变长，这样会大大减少FULLPAGEWRITE。增加CHEKPOINT的延迟也是一把双刃剑，因为它会让数据库在恢复的时候需要RECOVER更多的pages，同时在一次CHECKPOINT的时候会密集写入大量的数据块。瞬时对IO影响较大。在PG中关闭FULLPAGEWRITE也是一个选项，但是需要找到支持PG的文件系统或者存储系统来关闭FULLPAGEWRITE。我们之前试过在ZFS上关闭FULLPAGEWRITE，效果还是不错的。只是ZFS在我们大部分的PG运行环境中都没有用到，所以还是很期待PG15在FULLPAGEWRITE上的优化。我也考虑过使用WAL压缩来缓解FULLPAGEWRITE的问题。我们在PG12上做了测试，开启了WAL压缩。只是开启WAL压缩后，PG数据块的高并发写入性能并没有提升，反而略有下降。在非常有限的情况下，可以从以前的PG12WAL压缩中获得性能提升。PG15的WAL压缩有一个非常令人兴奋的改进。WAL压缩除了支持PGLZ外，还支持LZ4和ZSTANDARD两种压缩算法。从官方对比来看，ZSTD是一种优秀的压缩算法，能够平衡压缩和解压的吞吐量和压缩比。LZ虽然在压缩率上不如ZSTD，但是在压缩吞吐量上有特别好的表现。这两种压缩算法的引入，必将大大提升WAL压缩的性能。由于时间关系，我们还没有全面启动PG15测试。我觉得还是等正式版出来再做完整的测试比较好。不过从目前一些国外友人对PG15的测试来看，还是很让人期待的。我们来看看基于MarkCallaghan的测试用例的效果。正如我们所料，使用之前的pglz对PK-only场景影响不大。对于PG来说，第一次写入数据是创建一个新的block，不同算法之间的影响并不大。这个太大了。但对其他场景的影响更大。使用LZ4的效果非常好，加载性能有了明显的提升。当有多个索引时，zstd显示出更好的数据加载性能。不过从上面的测试来看，还是比较简单的，所以这个测试结果页并没有说明太多的问题。但有一点是可以肯定的，那就是LZ4和ZSTD的引入，将大大优化WAL压缩的性能，从而缓解FULLPAGEWRITE的问题，也可以大大减少DBA优化CHECKPOINT的工作量。在大多数场景下，CHECKPOINT的优化可能会变得更简单。我们只需要根据自己的场景需求选择设置WAL压缩参数即可。巧合的是，在PG15中，新增了一个权限：pg_checkpointer。过去，checkpint命令只能由超级用户执行。在PG15中，只要用户被授予这个权限，他就可以在自己的应用中执行checkpoint命令。下放checkpoint命令的权限是PG15细粒度权限控制优化的一部分。但是既然你敢下放权限，那就意味着checkpoint的副作用已经是可控的。随着现代硬件的发展，IO问题得到了极大的缓解。同时，因为WAL压缩的优化，也为checkpoint权限的去中心化提供了强有力的支持。但是业务场景非常复杂，这个权限最好不要随便授予，因为目前我还没有搞清楚这个权限委托的真正好处在哪里，在什么场景下应用需要控制权限检查站本身。如果有一天，DBA发现一个令人头疼的IO性能问题是由于应用系统频繁执行checkpoints导致的，那可就麻烦大了。对于开发人员来说，尽快将每条记录写入磁盘绝对是一件幸福的事情，但是对于DBA来说，可能就是一场灾难。
