PostgreSQL也很強(qiáng)大，為何在中國大陸MySQL成為主流，PostgreSQL屈居二線呢？
PostgreSQL能否替代MySQL？我感覺PostgreSQL非常強(qiáng)大，很多地方超過了MySQL。
舉幾個例子：
1.豐富的數(shù)據(jù)類，支持?jǐn)?shù)組、字典、json、序列號
2.強(qiáng)大的審計函數(shù)
3.強(qiáng)大的索引，易于sql調(diào)優(yōu)
PostgreSQL在許多地方，有MySQL無法比擬的優(yōu)勢。但是在中國大陸，許多公司的核心業(yè)務(wù)庫，都是MySQL，PostgreSQL則屈居二線，作為審計類的數(shù)據(jù)庫來使用。
為什么不讓PostgreSQL來扛大梁呢，而要用MySQL，PostgreSQL不合適么？
MySQL和PostgreSQL在功能上各有千秋，為什么沒能在業(yè)界中形成“平分天下”的局面呢？小編精選了幾位知乎網(wǎng)友的精彩回答，分享給大家學(xué)習(xí)交流（仁者見仁，智者見智，勿引戰(zhàn)~）：
以下均為個人感覺，沒做過統(tǒng)計，就當(dāng)個參考吧。
MySQL和Postgres的早期完全是兩個極端。MySQL更像是個“基本上滿足關(guān)系數(shù)據(jù)庫語法的大號KV”，對關(guān)系型數(shù)據(jù)庫的高級功能支持得很不好。我入行時接觸的MySQL 5.1和MyISAM存儲引擎，不支持ACID，但有如下幾點在當(dāng)時的互聯(lián)網(wǎng)公司看來是非常合適：1. 互聯(lián)網(wǎng)公司為了擴(kuò)展，長期的經(jīng)驗是，僅僅把數(shù)據(jù)庫當(dāng)作是一個“存儲”，而非存儲+核心數(shù)據(jù)邏輯的計算節(jié)點。大量的計算都在業(yè)務(wù)服務(wù)器上進(jìn)行，而業(yè)務(wù)服務(wù)器可以無限水平擴(kuò)展，無需擔(dān)心有狀態(tài)的數(shù)據(jù)遷移問題；2. 因為沒有提供很多高級功能和數(shù)據(jù)一致性的保障，MySQL對于簡單的sql支持的反而更加直接，在速度上有很大的優(yōu)勢；3. 對于OLTP，完全不需要復(fù)雜的數(shù)據(jù)處理功能。簡單的select ... from ... where id = xxx; insert into xxx；update xxx set xxx=xxx where id = xxxx是OLTP的主流功能?；谶@些功能的ORM的出現(xiàn)大大提高了生產(chǎn)效率；對于OLAP，盡管Postgres查詢分析功能很強(qiáng)，但是一般互聯(lián)網(wǎng)公司的數(shù)據(jù)量實在太大，用Postgres這種數(shù)據(jù)庫根本無法處理。通常會用MapReduce、Hive、Pig等大數(shù)據(jù)處理工具來分析；4. 多線程模型，天然對高并發(fā)支持良好。而pg一直是多進(jìn)程模型。進(jìn)程的創(chuàng)建會更慢，更耗內(nèi)存。雖然有些PG的連接池方案，但是MySQL在這方面“開箱即用”；5. Postgres早期并不支持“邏輯復(fù)制”。物理復(fù)制意味著存儲格式的細(xì)節(jié)完全暴露，不兼容的版本無法直接組成主從同步，于是無法做滾動升級。這就意味著在升級數(shù)據(jù)庫時，必須停服，把整個集群升級后再恢復(fù)。而MySQL從一開始就是邏輯復(fù)制（這其實是由于MySQL一直是server和存儲引擎分層的架構(gòu)，邏輯復(fù)制發(fā)生在server層）。這個缺陷會讓Postgres的運營不受業(yè)務(wù)開發(fā)者的待見。誰也不希望自己的業(yè)務(wù)停服。反過來再看Postgres的優(yōu)點，會發(fā)現(xiàn)對于OLTP并沒有太大的吸引力：1. 豐富的數(shù)據(jù)類型：通常用處不大，常用類型足夠了。如果有復(fù)雜類型，業(yè)務(wù)上自己序列化，存儲成varchar就行?？梢杂胘son，PB，avro等。序列化反序列化都發(fā)生在業(yè)務(wù)服務(wù)器，更好維護(hù)和優(yōu)化；2. 強(qiáng)大的審計函數(shù)：互聯(lián)網(wǎng)早期活下來是一切，審計并不是核心需求（通常需要嚴(yán)格審計的領(lǐng)域早就會用Oracle/msSQL，不差錢）；3. 強(qiáng)大的索引：Postgres的自定義索引功能很強(qiáng)大。但是對于MySQL，關(guān)鍵的幾列有索引就夠了，不需要復(fù)雜的高級索引。我承認(rèn)早期MySQL的查詢優(yōu)化器智商堪憂，但如果要改，一句explain，然后force index也就是了，對于開發(fā)人員簡單直接。有一段時間LBS很流行，當(dāng)時MongoDB很潮地直接支持了空間索引。當(dāng)時大家紛紛“NoSQL”，就更不會看Postgres一眼。然后到了大概2015年，MySQL 5.7也支持空間索引了。4. Posgres的MVCC實現(xiàn)牛不？牛。serial snapshot isolation是很強(qiáng)，但是到了需要變更數(shù)據(jù)嚴(yán)格一致的時候，select ... for update又不是不能用：）5. 對于序列號，sequence是很好。但是互聯(lián)網(wǎng)公司對于簡單場景用auto increment，對于生產(chǎn)場景就直接用分布式序列號生成服務(wù)了。Postgres的序列號產(chǎn)生器～偏雞肋。6. Postgres的全文索引很強(qiáng)，但強(qiáng)得過ES？強(qiáng)得過專門定制的搜索引擎系統(tǒng)？要知道搜索業(yè)務(wù)最關(guān)鍵的是把“最匹配搜索人需要的搜索結(jié)果返回出來”，而不是僅僅“能搜到一堆不分主次但滿足關(guān)鍵字匹配的結(jié)果”。因此早期MySQL變成了事實上的互聯(lián)網(wǎng)企業(yè)OLTP的事實標(biāo)準(zhǔn)。不管干啥業(yè)務(wù)，MySQL都不可或缺。在行業(yè)里跳槽來跳槽去的程序員普遍對MySQL也更熟悉。大量圍繞MySQL的商業(yè)服務(wù)都成為了行業(yè)主流。新一代分布式數(shù)據(jù)庫，像TiDB為了吸引用戶，首先要做的是“兼容MySQL的語法”。再往后，MySQL增加了更多“關(guān)系型數(shù)據(jù)庫該有的”功能，比如完全支持ACID的innodb成為默認(rèn)存儲引擎，比如5.7的json原生支持，8.0的window function/CTE。而Postgres也增加了更多的“互聯(lián)網(wǎng)功能”，但是時機(jī)已經(jīng)過去了。大家MySQL跑著業(yè)務(wù)好好的，而切換數(shù)據(jù)庫絕對不是僅僅像某些ORM標(biāo)榜的換一個Dialect就行的，整個編程模型，性能表現(xiàn)，運維工具和流程都要有巨大的變化。如非必要，犯不著為了一個“most advanced”的標(biāo)語去折騰，更不會為了數(shù)據(jù)庫愛好者的情懷做傷害利益的事情。我已經(jīng)不寫代碼、做技術(shù)管理一段時間了，但是有些支持工程師做技術(shù)選型的經(jīng)驗，根據(jù)業(yè)務(wù)上的需求來聊一聊吧。這里一半是我們技術(shù)選型時TL告訴我的，一半是我個人代碼實踐的經(jīng)驗。數(shù)據(jù)庫這種早期用了就基本不能換的東西是有滯后性的，你看到現(xiàn)在MySQL的現(xiàn)狀，是“5年前MySQL是國內(nèi)幾乎唯一選擇”造成的情況。5年前Postgres就已經(jīng)在歐美初創(chuàng)項目里比較受歡迎了，國內(nèi)公司數(shù)據(jù)量、體量是國外公司無法比的，畢竟用戶人數(shù)多，隨便都上億，而且國外這幾年新項目活得好的公司都是B2B，有幾十萬上百萬用戶量就很不錯了。Postgres有scaling issue（擴(kuò)展問題？這個詞中文怎么說），一個表2-3T就不行了，不做大量優(yōu)化查詢速度就以秒開始做單位了，這是云數(shù)據(jù)庫提供商不會告訴你的。他們只會告訴你Postgres的優(yōu)點。題外話，NoSQL也有類似的壞處。但是除非在生產(chǎn)環(huán)境中踩過坑，沒有人會告訴你的。在技術(shù)社區(qū)里噴某個解決方案不行是會被鄙視的，特別是大公司，有這種體量業(yè)務(wù)的工程師是沒時間跟你說這種掃興的話的。Postgres的好處之一是有好幾年給新語言的ORM比MySQL成熟，對全棧工程師更友好。歐美的全棧工程師一般是腳本語言后端（Node、RoR、Python）加上前端。國內(nèi)更流行的是強(qiáng)類型語言（Java）后端，一般不會同時前端的，Java + MySQL是真香。歐美這種全棧工程師的弱點就是對后端沒有那么深的理解，這里就不細(xì)聊了。前幾年不需要運維支持就能部署的云服務(wù)提供商（Digital Ocean、Heroku）只支持Postgres。同上，全棧工程師一般是沒有運維能力的。EC2上給你裝個MySQL？RDS的文檔能看懂就很不錯了好嗎~MySQL對于你說的那些Postgres優(yōu)點，都在國內(nèi)有業(yè)界已經(jīng)驗證過，實施經(jīng)驗人數(shù)也很多的最佳解決方案。而且那些優(yōu)點，是工程師做得爽而已，跟業(yè)務(wù)沒啥實質(zhì)性的關(guān)系。而踩過Postgres坑的這種人招不到，才是阻礙業(yè)務(wù)的第一大要素。最后，為什么都是data類才用PG，因為data不是業(yè)務(wù)組，運維支持力度沒那么大，也沒有實時性能上的壓力，上面的壞處不是什么壞處，好處卻是可見的，能夠提高開發(fā)速度的。這可能還真的跟PHP有點關(guān)系，PHP很早的版本就有內(nèi)置的mysql支持，很多Linux發(fā)行版都可以一鍵安裝LAMP套件（Apache + MySQL + PHP），基本不用配置就可以開始用。其實國內(nèi)PHP流行的時候已經(jīng)有pgsql的支持了，但是習(xí)慣和早期沿襲的資料的影響仍然是巨大的。因為MySQL用得多，自然熟悉MySQL的DBA也多，熟悉pgsql的DBA少，也就進(jìn)一步影響了其它語言的選型。對于當(dāng)時的大部分開發(fā)者和公司來說，PGSQL的那些高級功能反正也不會用，自然就跟不存在沒什么兩樣。從技術(shù)而言，PG 功能豐富，SQL 支持得很完備，強(qiáng)大的數(shù)據(jù)類型，嚴(yán)謹(jǐn)?shù)年P(guān)系模型，很難從關(guān)系模型去找出PG的不合理之處，多年積累，連全文索引詞庫都非常豐富，據(jù)說對于一些簡單的搜索，都可以擺脫搜索引擎了，優(yōu)化器做得很好，在代價選擇上 PG 實現(xiàn)了基因算法，這一點連Oracle 也沒有做到。讀過一部分 PG 的代碼和 MySQL 的代碼，對比起來，PG 的代碼寫得非常工整，注釋也很細(xì)致，真的可以稱得上code 教科書級別的工程，一定是一幫有情懷的coder 寫出來的，對比起來，MySQL 就是一坨……可是這個問題是一個工程性問題，就不要用這些方面來衡量一個工程問題！歷史總是時勢造英雄，看看MySQL 火起來的那段時間，正是互聯(lián)網(wǎng)爆發(fā)式增長的那幾年。由于PG 豐富的功能，所以它顯得太重了，多進(jìn)程并發(fā)，再加上早期的存儲做得不夠好，太吃資源。在那個時代，內(nèi)存和存儲都是比較昂貴的資源，早期的PG 性能也不太好，由于關(guān)系模型支持得很好，用起來會有諸多限制，學(xué)習(xí)成本會比較高。比起這些，MySQL 要輕量很多，到現(xiàn)在這也是它的一個優(yōu)點，在互聯(lián)網(wǎng)這個特定的場景中，大家為了追求快速迭代和拓展性，使用的 SQL 功能不會太多，都夠用。而PG 由于更嚴(yán)謹(jǐn)?shù)?SQL 關(guān)系模型，很多用法都限制得比較死，MySQL 卻要靈活很多，你的劣勢就出來了。這個讓用戶用起來很爽，但是對于兼容 MySQL 的兼容實現(xiàn)者很痛苦；有些 feature 在特定的場景中用起很便利，但是在通用的模型中卻禁不起推敲，要不要兼容它呢？但用戶很難感知到這些，除非測試去亂試，一般人不會那么無聊，這就是工程上的權(quán)衡。很難說誰好誰壞。而用的人多了，相關(guān)的使用經(jīng)驗會匯總到社區(qū)，形成部署方案、工具等，這又是工程中的正反饋。在江湖中，有幾個身負(fù)各項絕技的大俠最后成了將軍和皇帝的？感覺是在幾個互聯(lián)網(wǎng)痛點的時間窗口沒趕上，蠻可惜的。之前 uber 有一篇文章：Why Uber Engineering Switched from Postgres to MySQL（link.zhihu.com/?target=https%3A//eng.uber.com/Postgres-to-MySQL-migration/）里面提到的幾個問題現(xiàn)在我猜應(yīng)該有解決，但是時間點晚了，比如：
MySQL 給人的感覺就是「我啥都挫，要啥特性沒啥特性，事務(wù)都用起來沒多少年，但是我十、二十年前就有主從邏輯復(fù)制跟 MHA」。
"為何MySQL在大陸成為主流，PostgreSQL屈居二線呢？"歡迎在留言區(qū)交流，留下你的觀點~
來源丨知乎：zhihu.com/question/31955622
該文章在 2024/3/15 15:17:44 編輯過
400 186 1886
