這個(gè)話題我一年半年前在《PG離企業(yè)核心應(yīng)用數(shù)據(jù)庫還有多遠(yuǎn)》一文中國也談到過，隨著對(duì)PG理解的越來越深入，我發(fā)現(xiàn)這個(gè)話題的內(nèi)容也不斷在擴(kuò)大。想做好一款能夠支撐關(guān)鍵業(yè)務(wù)的企業(yè)級(jí)數(shù)據(jù)庫產(chǎn)品并不是那么容易的事情。雖然我們有大量?jī)?yōu)秀的開源數(shù)據(jù)庫，但是把開源代碼改造為一個(gè)真正意義上的企業(yè)級(jí)數(shù)據(jù)庫并非易事。

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

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

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

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

圖片

這個(gè)問題我以前也寫文章討論過，當(dāng)Oracle的數(shù)據(jù)文件被破壞的時(shí)候，RDBMS也不會(huì)馬上感知到，但是如果掃描某張表的時(shí)候訪問到了被損壞的文件或者數(shù)據(jù)塊，則能夠發(fā)現(xiàn)問題，企業(yè)級(jí)數(shù)據(jù)庫系統(tǒng)不需要隨時(shí)感知到錯(cuò)誤（這個(gè)成本太高），但是不能回答錯(cuò)誤的答案。

第二個(gè)問題是PG數(shù)據(jù)庫對(duì)自己的數(shù)據(jù)文件臨時(shí)文件的清理工作是做的不完整的。當(dāng)數(shù)據(jù)庫出現(xiàn)一些問題的時(shí)候，或者出現(xiàn)一些異常的時(shí)候，是不會(huì)自動(dòng)做清理工作的時(shí)間長(zhǎng)了就會(huì)產(chǎn)生一些垃圾，包括一些孤兒文件。對(duì)于一個(gè)需要長(zhǎng)期，甚至7*24運(yùn)行的數(shù)據(jù)庫系統(tǒng)來說，自動(dòng)清理垃圾是必備的能力。

因?yàn)?span>缺少PMON/SMON之類的后臺(tái)進(jìn)程，當(dāng)BACKEND的故障的時(shí)候，無法由系統(tǒng)自動(dòng)進(jìn)行必要的清理工作，因此可能會(huì)導(dǎo)致數(shù)據(jù)存在不一致的可能性，PG可以采取保護(hù)措施，讓PG數(shù)據(jù)庫宕機(jī)。這種方式雖然是有效的，但是這種做法不是一個(gè)企業(yè)級(jí)數(shù)據(jù)庫應(yīng)該有的。想要讓PG數(shù)據(jù)庫在這方面像一個(gè)企業(yè)級(jí)數(shù)據(jù)庫一樣就必須建立一組新的后臺(tái)進(jìn)程，從而實(shí)現(xiàn)像oracle一樣能夠自如的應(yīng)對(duì)各種系統(tǒng)故障以及進(jìn)程故障。

試想如果一個(gè)企業(yè)級(jí)應(yīng)用中因?yàn)槟硞€(gè)用戶進(jìn)程出問題，如果使用Oracle那么我們殺掉某個(gè)進(jìn)程就搞定了，而如果換成PG數(shù)據(jù)庫，殺還是不殺呢？殺了如果整個(gè)實(shí)例宕了怎么辦？讓PG數(shù)據(jù)庫能夠自由殺用戶進(jìn)程甚至一些不影響數(shù)據(jù)庫運(yùn)行的后臺(tái)服務(wù)進(jìn)程，是讓PG成為企業(yè)級(jí)數(shù)據(jù)庫的不可或缺的條件。

類似RAC的能力也是企業(yè)級(jí)數(shù)據(jù)庫必須就有的能力，無論什么情況下，當(dāng)某個(gè)實(shí)例故障時(shí)能夠快速、自動(dòng)、0數(shù)據(jù)丟失地切換是企業(yè)級(jí)應(yīng)用對(duì)數(shù)據(jù)庫的基本要求。對(duì)于RAC，其實(shí)絕大多數(shù)用戶不需要RAC的橫向擴(kuò)展能力，而是需要其高可用切換能力?，F(xiàn)在很多基于PG開發(fā)的國產(chǎn)數(shù)據(jù)庫都在做類似RAC的功能，目標(biāo)都是對(duì)等訪問，橫向擴(kuò)展。其實(shí)我覺得這么做可能是勞民傷財(cái)。ASTORE如果不改掉，想做出優(yōu)秀的RAC架構(gòu)的共享存儲(chǔ)對(duì)等訪問集群來，幾乎是不可能的。

實(shí)際上如果PG數(shù)據(jù)庫能夠具備共享存儲(chǔ)，讀寫分離能力，就已經(jīng)足夠了，類似ORACLE 兩節(jié)點(diǎn)時(shí)的ACTIVE-STANDBY模式，這個(gè)模式在二十年前在一些核心業(yè)務(wù)系統(tǒng)中被我推薦使用。如果PG數(shù)據(jù)庫具備類似的能力，當(dāng)某個(gè)實(shí)例故障后能夠在幾十秒內(nèi)實(shí)現(xiàn)業(yè)務(wù)完全切換到STANDBY實(shí)例，那么應(yīng)對(duì)企業(yè)級(jí)關(guān)鍵應(yīng)用已經(jīng)足夠了。前陣子在電科金倉的一個(gè)活動(dòng)中，金倉給大家演示了自己的RAC系統(tǒng)，當(dāng)時(shí)很多用戶都覺得這確實(shí)是他們急需的功能。

當(dāng)前基于流復(fù)制的高可用方案其缺點(diǎn)就是對(duì)于關(guān)鍵業(yè)務(wù)系統(tǒng)來說，快速的全自動(dòng)切換實(shí)現(xiàn)起來十分困難。因?yàn)橹挥袕?fù)制完成，并且數(shù)據(jù)確保0丟失情況下，對(duì)于關(guān)鍵系統(tǒng)才敢做自動(dòng)化切換，而目前的流復(fù)制模式還是不夠讓人放心。基于RAFT/PAXOS復(fù)制組的實(shí)現(xiàn)，只要確保延時(shí)夠低，也是可接受的。不過成本略高，而且保護(hù)能力并不完整。Oracle RAC+ADG的MAA架構(gòu)已經(jīng)被證明是目前最成功的的高可用架構(gòu)。

本來想寫篇短文，沒想到才寫了幾個(gè)點(diǎn)就已經(jīng)這么多了。后面我簡(jiǎn)單再列幾點(diǎn)問題吧：

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