之前呢！筆者在某平臺上看了關(guān)于PostgreSQL相關(guān)的內(nèi)容，并且看到下面評論中問到關(guān)于PostgreSQL這個數(shù)據(jù)庫到底好不好用。那么下面我們就來聊聊關(guān)于PostgreSQL相關(guān)的內(nèi)容，并且相比較于MySQL等一些數(shù)據(jù)到底有什么樣的區(qū)別。

PostgreSQL的優(yōu)勢

PostgreSQL自稱是目前為止最先進(jìn)的關(guān)系型數(shù)據(jù)庫，但是事實上，它不僅僅只是一個單純的關(guān)系型的數(shù)據(jù)庫。它其實還支持了一些非關(guān)系型數(shù)據(jù)的存儲，也就是說它還支持了一些NoSQL的數(shù)據(jù)類型。例如用它可以實現(xiàn)KV鍵值對的存儲，可以實現(xiàn)JSON數(shù)據(jù)的存儲。

其實從本質(zhì)上來講，PostgreSQL才是真正的NoSQL，也就是Not Only SQL，不僅僅是SQL。這就是因為它不僅僅支持了關(guān)系型數(shù)據(jù)的存儲，而且還支持了非關(guān)系型數(shù)據(jù)的存儲，也就是說從另外一個角度上來講，PostgreSQL其實可以理解為一個全棧類型的數(shù)據(jù)庫。

那么什么是全棧呢？這里的全棧就是指它所能支持的使用場景比較的多，可以支持各種各樣的擴(kuò)展。

上面我們提到，PostgreSQL所支持的數(shù)據(jù)類型非常的豐富，這樣使得它所能適配的場景會比較多，另外一點(diǎn)就是它也是可以支持事務(wù)操作的，而且它還提供了非常豐富的數(shù)據(jù)分析工具，雖然定位是一個對象關(guān)系數(shù)據(jù)庫，但是它對于一些SQL結(jié)構(gòu)化查詢的支持也是非常好的。在有些方面的SQL操作的支持要比MySQL要更加的豐富，包括對于子查詢、窗口函數(shù)等的支持。

PostgreSQL還支持了時序數(shù)據(jù)存儲、地理位置信息的存儲、數(shù)據(jù)倉庫等PG都提供了它對應(yīng)的解決方案。而且想必很多人也對其很多支持的高可用實現(xiàn)方案有所了解。例如PostgreSQL它也支持高可用集群部署方案，并且支持副本的冗余、也支持內(nèi)存主從同步機(jī)制，它內(nèi)置的基于二進(jìn)制的同步復(fù)制方式在大部分情況下，比MySQL所支持的基于binlog的同步方式可能更加可靠。

另外就是PostgreSQL是它所支持的開源協(xié)議是BSD，也就是說它的開發(fā)的自由度會比較高，我們甚至可以基于PostgreSQL可以進(jìn)行一些二次開發(fā)，并且二次開發(fā)的產(chǎn)品也可以變成自己的商業(yè)產(chǎn)品，國內(nèi)有很多的數(shù)據(jù)倉庫都是基于它來進(jìn)行的二次開發(fā)，所以很多云原生的關(guān)系型數(shù)據(jù)庫基本上都與它有著或多或少的聯(lián)系，這也是PostgreSQL社區(qū)一直非常活躍的原因之一。

擴(kuò)展性

PostgreSQL的擴(kuò)展性也是比較強(qiáng)的，它是基于目錄驅(qū)動進(jìn)行的擴(kuò)展。可以非常靈活的在其中添加一些數(shù)據(jù)類型、操作方式、以及內(nèi)置函數(shù)等等。這過程也是非常彈性的也就是說你用的時候可以將它加上，不用的時候刪除就可以了，不需要進(jìn)行多余的編譯加載的操作。這也是PostgreSQL為什么可以支持去自定義一些新的數(shù)據(jù)類型的原因。

與MySQL的差異

MySQL是基于GPLv2開源協(xié)議，雖然社區(qū)活躍度也不低，但是它背后畢竟是甲骨文，所以說商業(yè)化程度其實并不是太高。

MySQL支持了很多的存儲引擎，除了InnoDB和NDB之外，其他的引擎都不支持事務(wù)操作。像是PostgreSQL的話它就只有一個存儲引擎，所以直接就是支持事務(wù)的。雖然這種方式可以省去你選擇的麻煩，但是所帶來的問題就是無法進(jìn)行合理的均衡設(shè)計，但是從另一個方面來講，既然支持了，就一定會考慮性能，但是它在某些場景中，例如遇到一些小數(shù)據(jù)量的讀寫，可能就比不過MySQL所支持的一些其他的存儲引擎了。

PostgreSQL對于SQL語句的兼容性要比MySQL要更好一些，像是對于一些子查詢的支持，對于聯(lián)表查詢等PostgreSQL的性能要比MySQL要更好一些。

PostgreSQL對于客戶端程序的支持，要比MySQL支持的要更豐富。

PostgreSQL對于數(shù)據(jù)類型的支持也要比MySQL要更多一些。例如它可以用來存儲一些JSON，XML格式的數(shù)據(jù)。對于這種數(shù)據(jù)的支持可能PostgreSQL要略勝于MySQL。這主要是因為PostgreSQL在操作一些并發(fā)讀寫的時候，會省略在MySQL中底層所支持的一些鎖的操作。但是在對于數(shù)據(jù)量較小的情況下，MySQL會更加方便。這其實也是非常符合很多真實場景中所暴露出來的問題的。

所以如果在某些實在是不方便進(jìn)行分庫分表的場景下，并且單個表的數(shù)據(jù)量比較大的情況下，并且還有很多復(fù)雜的查詢操作的時候，可能使用PostgreSQL會更加好一些。但是需要注意，在一些并發(fā)場景下由于MySQL的操作會進(jìn)行一些底層處理，在內(nèi)存消耗方面要比PostgreSQL要小，這是因為PostgreSQL是基于進(jìn)程進(jìn)行的處理，也就是說一個客戶端對應(yīng)一個進(jìn)程，而在MySQL中一個請求只對應(yīng)著一個線程。相比較而言，進(jìn)程消耗的資源可能要比線程消耗的資源要大得多。所以并不是說PostgreSQL在處理這種場景就一定好，只是相對而言要比MySQL要性能更好，但是它需要一些其他的手段來保證這種性能優(yōu)勢。

在很早之前就有人揚(yáng)言PostgreSQL的性能已經(jīng)完全碾壓MySQL了，但是MySQL人家又不是沒有在發(fā)展變化，所以說MySQL在不斷的升級迭代的過程中對性能上的提升也是有目共睹的。

到底要不要使用PostgreSQL

要不要使用PostgreSQL還是要根據(jù)實際的使用場景來決定？第一，就是你要開發(fā)的系統(tǒng)是一個新的系統(tǒng)，第二，就是老系統(tǒng)是否需要使用PostgreSQL來進(jìn)行迭代。

這就要看后續(xù)的開發(fā)場景了，如果后續(xù)的開發(fā)過程中可能會遇到一些非結(jié)構(gòu)化的存儲，或者是會存儲一些KV數(shù)據(jù)，存儲一些地理位置信息，存儲一些帶有時序性的數(shù)據(jù)，那么對于這些數(shù)據(jù)的存儲，就要考慮是否使用PostgreSQL了。

當(dāng)然這種數(shù)據(jù)也可以使用MySQL來進(jìn)行存儲，但是有一點(diǎn)，能用不代表好用。反過來也是一樣的。PostgreSQL所支持的有些操作，在對于一些數(shù)據(jù)的處理上來講，也或許沒有MySQL更加好用。

畢竟專業(yè)的數(shù)據(jù)存儲還是要專業(yè)的數(shù)據(jù)庫來進(jìn)行支持的么。

另外需要注意的就是PostgreSQL只支持了一個存儲引擎，所以對于運(yùn)維這方面的要求還是比較高的。如果團(tuán)隊里面沒有對PostgreSQL非常精通的DBA的話建議還是不要使用了。因為數(shù)據(jù)這種東西，畢竟是會影響很多的東西的，基本上屬于各個公司的核心數(shù)據(jù)資產(chǎn)，一旦丟失后果非常嚴(yán)重。

總結(jié)

考慮到以上這些內(nèi)容，你就要看看新項目中是否使用PostgreSQL數(shù)據(jù)庫，并且老項目中是否需要對數(shù)據(jù)庫這方面進(jìn)行迭代升級，對于這一點(diǎn)，筆者還是不太建議老項目進(jìn)行迭代。因為你無法保證項目就一定合適，也無法保證數(shù)據(jù)就一定支持。