我不认为PG的Double Buffering是更优秀的解决方案

网友投稿 1157 2023-04-17

我不认为PG的Double Buffering是更优秀的解决方案

我不认为PG的Double Buffering是更优秀的解决方案

​关于PG在Shared buffers上的DOUBLE BUFFERING设计,一直是争议极多的。有一些搞PG的朋友认为这是PG充分利用OS CACHE的一种特殊设计,是PG数据库设计中比较优秀的地方。还有一些朋友则认为这是一种过时的设计,与当前数据库技术的发展潮流所相违背的。前些天有几个朋友谈到这个问题,希望我写篇位置表达下我的观点。

以我这些年做数据库优化的经验来看,DOUBLE BUFFERING的设计如果算是一种技术上的进步,在这一点上我一直是不太认同的。众所周知,现在几乎所有的现代数据库产品都是用AIO/DIO等方式来访问底层存储系统,只有PG目前还通过BUFFER/CACHE来读取物理文件。随着现代硬件的发展,BUFFERED IO的劣势越来越显现出来了。如果我们采用直接IO,绕过文件缓冲,那么就可以绕过BUFFER CACHE这一层,让数据从文件到内存更为直接,这会大幅提升OS到数据库缓冲的数据交换的吞吐能力,同时,因为DMA等技术的使用,可以让文件IO消耗的CPU资源更少,让系统更为高效。这对于大型数据库系统来说绝对是十分必要的。PG数据库越来越被用于大型OLTP系统,直接IO替代BUFFERED IO肯定可以有效增加大型系统的并发IO能力。

另外一个方面,操作系统是无法充分理解数据库的PAGE访问逻辑的,因此操作系统缓冲的效率比较shared buffers而言,要低的多。两个分别由RDBMS和OS管理的分离的缓冲的效率肯定没有一个独立的数据库缓冲高,这个应该也是广大研发人员的共识。不过这句话成立的前提是数据库缓冲区被设计的十分高效,其LRU算法也被设计的十分合理。通过分析*** DB CACHE的算法的改进,我们也了解到为什么***的DB CACHE能够保持那么高的DB CACHE命中率了。

既然使用统一缓冲,消除DOUBLE BUFFERING那么重要,那么为什么PG还在坚持使用DOUBLE BUFFERING呢?这个原因十分复杂,实际上最近这些年里,PG社区也在这方面做着不断的努力。通过利用OS的AIO来替代当前bufmgr.c中的BUFFERD IO操作,不过PG的IO堆栈太长了,在大量的代码中都存在和buffered io相关的内容,再加上PG的文件结构导致的预读、连续块访问的IO合并等问题,要解决这个问题并不容易。在IO路径上,不仅仅需要修改bufmgr.c,在smgr.c,xlog.c,到底层的md.c,fd.c,甚至backend等模块中都有大量IO相关的代码需要修改。这些修改不仅仅是在调用文件IO时的函数调用的修改,还涉及到异步IO模式的修改,以及IO优化、预读等一系列的问题。因此这部分的修改中左虽然已经进行了数年,但是要出现在正是发布的版本中,依然还需要一定的时间。这也成为PG代码中的XID64之外的又一个老大难的问题。

除此之外,在shared buffers的管理上,也需要做相应的优化,否则哪怕底层IO改为了AIO,buffer contention冲突也会让一个大型的统一的数据库缓冲的性能出现问题。比如在***上遇到的buffer busy waits等待,可能会在PG上放大,从而在高并发访问时引发严重的性能问题。

举个最简单的场景,那就是当多个backend需要访问相同的一组PAGE的时候,PG目前的管理算法上海经常会出现lwlock等待方面的超时等问题。而***从9i开始已经优化了这方面的算法,当多个并发的会话访问相同的block的时候,首先为这个BLOCK申请db cache的会话会PIN住这个BUFFER HEADER,然后开始加载这个block(当然也包含IO合并以及预读,多块读方面的算法优化),其他并发访问相同数据的会话就会等待“read by another session”,这个等待事件是*** 10g才开始引入的,在9i中等待的依然是buffer busy waits,不过reason code(P3)参数是特殊的,从reason code可以缺别处这种特殊的热块冲突类型。当PG在这方面算法没有做优化之前,就无法区分这种情况,也就无法与AIO配合,达到最低成本的开销。

PG消除DOUBLE BUFFERING,在技术发展上来说,是必须要做的事情,只不过因为历史欠债还是较多,这方面的改造工作量很大,需要一些时间来完成。一旦PG完成这个改造,将可以充分利用AIO的能力,大幅提升PG数据库读写的能力,从而让PG数据库真正向大型关系型数据库迈出一大步。目前我们有很多数据库企业都是基于PG生态在做研发,我也希望我们的数据库厂商能够在这方面多投入一些研发,为PG社区解决这个难题提供一些中国方案。​

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:千万级数据查询:CK、ES、RediSearch 谁才是王炸?
下一篇:分库分表,可能真的要退出历史舞台了!
相关文章