這個話題我一年半年前在《PG離企業核心應用數據庫還有多遠》一文中國也談到過，隨著對PG理解的越來越深入，我發現這個話題的內容也不斷在擴大。想做好一款能夠支撐關鍵業務的企業級數據庫產品并不是那么容易的事情。雖然我們有大量優秀的開源數據庫，但是把開源代碼改造為一個真正意義上的企業級數據庫并非易事。

PG是款不錯的數據庫，其功能相對來說比較完善，具備作為大型企業級數據庫的基本特征。但是作為一款企業級數據庫而言，還有很多不足的地方，必須加以改造才能夠勝任。很多國產數據庫也是基于PG的源代碼進行改造開發，如果要讓這些數據庫成為一款企業級數據庫產品，也必須要關注這些問題。

不知道國產數據庫廠商的產品經理有沒有意識到，其實PG數據庫作為一款企業級數據庫還是有很多不足的地方的。今天我就給大家分享一些PG數據庫缺失的一些比較重要的企業級特征。

像FREEZE和VACUUM這樣的老生常談我就不細說了，這是地球人都知道的事情，也是PG永遠的痛。

作為一款企業級數據庫最為重要的是數據的完整性和安全性。在這方面PG數據庫存在幾個比較明顯的不足。首先是數據庫對數據完整性的校驗不夠完善，以前我也寫文章提出過在PG數據庫里面，一張表如果比較大，需要用多個文件來存儲，如果丟失了一個或者數個數據文件，目前PG的RDBS核心是沒有辦法感知到的。此時如果要掃描這張丟失了某些數據文件的表，RDBMS不會報錯，但是會得出錯誤的查詢結果。

圖片

這個問題我以前也寫文章討論過，當Oracle的數據文件被破壞的時候，RDBMS也不會馬上感知到，但是如果掃描某張表的時候訪問到了被損壞的文件或者數據塊，則能夠發現問題，企業級數據庫系統不需要隨時感知到錯誤（這個成本太高），但是不能回答錯誤的答案。

第二個問題是PG數據庫對自己的數據文件臨時文件的清理工作是做的不完整的。當數據庫出現一些問題的時候，或者出現一些異常的時候，是不會自動做清理工作的時間長了就會產生一些垃圾，包括一些孤兒文件。對于一個需要長期，甚至7*24運行的數據庫系統來說，自動清理垃圾是必備的能力。

因為缺少PMON/SMON之類的后臺進程，當BACKEND的故障的時候，無法由系統自動進行必要的清理工作，因此可能會導致數據存在不一致的可能性，PG可以采取保護措施，讓PG數據庫宕機。這種方式雖然是有效的，但是這種做法不是一個企業級數據庫應該有的。想要讓PG數據庫在這方面像一個企業級數據庫一樣就必須建立一組新的后臺進程，從而實現像oracle一樣能夠自如的應對各種系統故障以及進程故障。

試想如果一個企業級應用中因為某個用戶進程出問題，如果使用Oracle那么我們殺掉某個進程就搞定了，而如果換成PG數據庫，殺還是不殺呢？殺了如果整個實例宕了怎么辦？讓PG數據庫能夠自由殺用戶進程甚至一些不影響數據庫運行的后臺服務進程，是讓PG成為企業級數據庫的不可或缺的條件。

類似RAC的能力也是企業級數據庫必須就有的能力，無論什么情況下，當某個實例故障時能夠快速、自動、0數據丟失地切換是企業級應用對數據庫的基本要求。對于RAC，其實絕大多數用戶不需要RAC的橫向擴展能力，而是需要其高可用切換能力。現在很多基于PG開發的國產數據庫都在做類似RAC的功能，目標都是對等訪問，橫向擴展。其實我覺得這么做可能是勞民傷財。ASTORE如果不改掉，想做出優秀的RAC架構的共享存儲對等訪問集群來，幾乎是不可能的。

實際上如果PG數據庫能夠具備共享存儲，讀寫分離能力，就已經足夠了，類似ORACLE 兩節點時的ACTIVE-STANDBY模式，這個模式在二十年前在一些核心業務系統中被我推薦使用。如果PG數據庫具備類似的能力，當某個實例故障后能夠在幾十秒內實現業務完全切換到STANDBY實例，那么應對企業級關鍵應用已經足夠了。前陣子在電科金倉的一個活動中，金倉給大家演示了自己的RAC系統，當時很多用戶都覺得這確實是他們急需的功能。

當前基于流復制的高可用方案其缺點就是對于關鍵業務系統來說，快速的全自動切換實現起來十分困難。因為只有復制完成，并且數據確保0丟失情況下，對于關鍵系統才敢做自動化切換，而目前的流復制模式還是不夠讓人放心。基于RAFT/PAXOS復制組的實現，只要確保延時夠低，也是可接受的。不過成本略高，而且保護能力并不完整。Oracle RAC+ADG的MAA架構已經被證明是目前最成功的的高可用架構。

本來想寫篇短文，沒想到才寫了幾個點就已經這么多了。后面我簡單再列幾點問題吧：

• SQL引擎增強：PG缺少不少算子，比如HASH ANTI JOIN等，企業級應用十分復雜，如果數據量比較大，業務邏輯相對復雜，缺失算子的問題會導致某些業務無法快速執行，有興趣的廠商可以把PG的算子與Oracle做一下比較，看看還缺點啥，缺啥補啥吧；
• 分區表功能與能力向Oracle看齊：大型企業級應用，分區表的使用十分多，雖然PG也有分區表，但是其管理便捷性，訪問性能，對于超過1萬分區的大型表的支持能力都還很欠缺。另外類似分區分裂、交換分區之類的能力也尚有缺失；
• 全局臨時表性能優化：PG的全局分區表功能雖然和Oracle差不多，不過一些國內的ERP廠商已經領教過了PG的全局臨時表的性能問題，前些年在分析一個全局臨時表的性能問題的時候，我也讀過這部分PG的源碼，寫得真的不怎么樣；
• 表的在線重定義：需要長期7*24運行的企業級業務系統，對于超大表的再現重定義能力十分關鍵，Oracle做好這個功能都花了近20年的時間，國產數據庫廠商也需要下點力氣來做；
• SHARED BUFFERS越大，DROP TABLE等操作越慢的問題：這是因為PG的CHECKPOINT機制不夠優化導致的，Oracle當年為了優化這方面問題，對kcbdws數據結構做了多次優化，對CHECKPOINT QUEUE，LRU-W等鏈表的算法做了多次重構，才達到了目前的水平，基于PG的國產數據庫也必須在此做大量的優化；
• 復制延時控制：有效控制復制延遲，優化并發回放的性能；
• 企業級備份管理器：試過備份上百個TB的PG數據庫嗎？能夠讓幾十TB的PG數據庫在周末晚上的有限備份窗口中完成全備，避免影響第二天的業務高峰性能嗎？如果不能，那就去優化吧。