建站
咨詢
售后
建站咨詢
新聞中心
關于PG在Shared buffers上的DOUBLE BUFFERING設計，一直是爭議極多的。有一些搞PG的朋友認為這是PG充分利用OS CACHE的一種特殊設計，是PG數(shù)據(jù)庫設計中比較優(yōu)秀的地方。還有一些朋友則認為這是一種過時的設計，與當前數(shù)據(jù)庫技術的發(fā)展潮流所相違背的。前些天有幾個朋友談到這個問題，希望我寫篇位置表達下我的觀點。
成都創(chuàng)新互聯(lián)公司是一家朝氣蓬勃的網(wǎng)站建設公司。公司專注于為企業(yè)提供信息化建設解決方案。從事網(wǎng)站開發(fā)，網(wǎng)站制作，網(wǎng)站設計，網(wǎng)站模板，微信公眾號開發(fā)，軟件開發(fā)，微信平臺小程序開發(fā)，10年建站對成都航空箱等多個領域，擁有多年的網(wǎng)站維護經(jīng)驗。
以我這些年做數(shù)據(jù)庫優(yōu)化的經(jīng)驗來看，DOUBLE BUFFERING的設計如果算是一種技術上的進步，在這一點上我一直是不太認同的。眾所周知，現(xiàn)在幾乎所有的現(xiàn)代數(shù)據(jù)庫產(chǎn)品都是用AIO/DIO等方式來訪問底層存儲系統(tǒng)，只有PG目前還通過BUFFER/CACHE來讀取物理文件。隨著現(xiàn)代硬件的發(fā)展，BUFFERED IO的劣勢越來越顯現(xiàn)出來了。如果我們采用直接IO，繞過文件緩沖，那么就可以繞過BUFFER CACHE這一層，讓數(shù)據(jù)從文件到內(nèi)存更為直接，這會大幅提升OS到數(shù)據(jù)庫緩沖的數(shù)據(jù)交換的吞吐能力，同時，因為DMA等技術的使用，可以讓文件IO消耗的CPU資源更少，讓系統(tǒng)更為高效。這對于大型數(shù)據(jù)庫系統(tǒng)來說絕對是十分必要的。PG數(shù)據(jù)庫越來越被用于大型OLTP系統(tǒng)，直接IO替代BUFFERED IO肯定可以有效增加大型系統(tǒng)的并發(fā)IO能力。
另外一個方面，操作系統(tǒng)是無法充分理解數(shù)據(jù)庫的PAGE訪問邏輯的，因此操作系統(tǒng)緩沖的效率比較shared buffers而言，要低的多。兩個分別由RDBMS和OS管理的分離的緩沖的效率肯定沒有一個獨立的數(shù)據(jù)庫緩沖高，這個應該也是廣大研發(fā)人員的共識。不過這句話成立的前提是數(shù)據(jù)庫緩沖區(qū)被設計的十分高效，其LRU算法也被設計的十分合理。通過分析Oracle DB CACHE的算法的改進，我們也了解到為什么Oracle的DB CACHE能夠保持那么高的DB CACHE命中率了。
既然使用統(tǒng)一緩沖，消除DOUBLE BUFFERING那么重要，那么為什么PG還在堅持使用DOUBLE BUFFERING呢？這個原因十分復雜，實際上最近這些年里，PG社區(qū)也在這方面做著不斷的努力。通過利用OS的AIO來替代當前bufmgr.c中的BUFFERD IO操作，不過PG的IO堆棧太長了，在大量的代碼中都存在和buffered io相關的內(nèi)容，再加上PG的文件結構導致的預讀、連續(xù)塊訪問的IO合并等問題，要解決這個問題并不容易。在IO路徑上，不僅僅需要修改bufmgr.c，在smgr.c，xlog.c，到底層的md.c,fd.c，甚至backend等模塊中都有大量IO相關的代碼需要修改。這些修改不僅僅是在調(diào)用文件IO時的函數(shù)調(diào)用的修改，還涉及到異步IO模式的修改，以及IO優(yōu)化、預讀等一系列的問題。因此這部分的修改中左雖然已經(jīng)進行了數(shù)年，但是要出現(xiàn)在正是發(fā)布的版本中，依然還需要一定的時間。這也成為PG代碼中的XID64之外的又一個老大難的問題。
除此之外，在shared buffers的管理上，也需要做相應的優(yōu)化，否則哪怕底層IO改為了AIO，buffer contention沖突也會讓一個大型的統(tǒng)一的數(shù)據(jù)庫緩沖的性能出現(xiàn)問題。比如在Oracle上遇到的buffer busy waits等待，可能會在PG上放大，從而在高并發(fā)訪問時引發(fā)嚴重的性能問題。
舉個最簡單的場景，那就是當多個backend需要訪問相同的一組PAGE的時候，PG目前的管理算法上海經(jīng)常會出現(xiàn)lwlock等待方面的超時等問題。而Oracle從9i開始已經(jīng)優(yōu)化了這方面的算法，當多個并發(fā)的會話訪問相同的block的時候，首先為這個BLOCK申請db cache的會話會PIN住這個BUFFER HEADER，然后開始加載這個block（當然也包含IO合并以及預讀，多塊讀方面的算法優(yōu)化），其他并發(fā)訪問相同數(shù)據(jù)的會話就會等待“read by another session”，這個等待事件是Oracle 10g才開始引入的，在9i中等待的依然是buffer busy waits，不過reason code（P3）參數(shù)是特殊的，從reason code可以缺別處這種特殊的熱塊沖突類型。當PG在這方面算法沒有做優(yōu)化之前，就無法區(qū)分這種情況，也就無法與AIO配合，達到最低成本的開銷。
PG消除DOUBLE BUFFERING，在技術發(fā)展上來說，是必須要做的事情，只不過因為歷史欠債還是較多，這方面的改造工作量很大，需要一些時間來完成。一旦PG完成這個改造，將可以充分利用AIO的能力，大幅提升PG數(shù)據(jù)庫讀寫的能力，從而讓PG數(shù)據(jù)庫真正向大型關系型數(shù)據(jù)庫邁出一大步。目前我們有很多數(shù)據(jù)庫企業(yè)都是基于PG生態(tài)在做研發(fā)，我也希望我們的數(shù)據(jù)庫廠商能夠在這方面多投入一些研發(fā)，為PG社區(qū)解決這個難題提供一些中國方案。
網(wǎng)站標題：我不認為PG的DoubleBuffering是更優(yōu)秀的解決方案
分享URL：http://m.5511xx.com/article/coegejc.html
