關於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演算法也被設計的十分合理。透過分析Oracle DB CACHE的演算法的改進，我們也瞭解到為什麼Oracle的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衝突也會讓一個大型的統一的資料庫緩衝的效能出現問題。比如在Oracle上遇到的buffer busy waits等待，可能會在PG上放大，從而在高併發訪問時引發嚴重的效能問題。

舉個最簡單的場景，那就是當多個backend需要訪問相同的一組PAGE的時候，PG目前的管理演算法上海經常會出現lwlock等待方面的超時等問題。而Oracle從9i開始已經最佳化了這方面的演算法，當多個併發的會話訪問相同的block的時候，首先為這個BLOCK申請db cache的會話會PIN住這個BUFFER HEADER，然後開始載入這個block（當然也包含IO合併以及預讀，多塊讀方面的演算法最佳化），其他併發訪問相同資料的會話就會等待“read by another session”，這個等待事件是Oracle 10g才開始引入的，在9i中等待的依然是buffer busy waits，不過reason code（P3）引數是特殊的，從reason code可以缺別處這種特殊的熱塊衝突型別。當PG在這方面演算法沒有做最佳化之前，就無法區分這種情況，也就無法與AIO配合，達到最低成本的開銷。

PG消除DOUBLE BUFFERING，在技術發展上來說，是必須要做的事情，只不過因為歷史欠債還是較多，這方面的改造工作量很大，需要一些時間來完成。一旦PG完成這個改造，將可以充分利用AIO的能力，大幅提升PG資料庫讀寫的能力，從而讓PG資料庫真正向大型關係型資料庫邁出一大步。目前我們有很多資料庫企業都是基於PG生態在做研發，我也希望我們的資料庫廠商能夠在這方面多投入一些研發，為PG社群解決這個難題提供一些中國方案。

我不認為PG的DOUBLE BUFFERING是更優秀的解決方案

相關文章