MySQL安魂九霄，PostgreSQL駛向云外
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
本月 MySQL 9.0 終于發布了，距離上一次大版本更新 8.0 (@2016-09) 已經過去整整八年。然而這個空洞無物的所謂 “創新版本” 卻猶如一個惡劣的玩笑，宣告著 MySQL 正在死去。 空洞無物的創新版本 糊弄了事的向量類型 姍姍來遲的JS函數 日漸落后的功能特性 越新越差的性能表現 無可救藥的隔離等級 枯萎收縮的生態規模 是誰殺死了MySQL？ PG駛向云外，MySQL安魂九霄 PostgreSQL 正在高歌猛進，而 MySQL 卻日薄西山，作為 MySQL 生態主要抗旗者的 Percona 也不得不悲痛地承認這一現實，連發了三篇《MySQL將何去何從》，《Oracle最終還是殺死了MySQL》，《Oracle還能挽救MySQL嗎》，公開表達了對 MySQL 的失望與沮喪； Percona 的 CEO Peter Zaitsev 也直言不諱道：
有的數據庫正在吞噬數據庫世界，而有的數據庫正在黯然地凋零死去。 MySQL is dead，Long live PostgreSQL！ 空洞無物的創新版本MySQL 官網發布的 "What's New in MySQL 9.0"[5] 介紹了 9.0 版本引入的幾個新特性，而 MySQL 9.0 新功能概覽 一文對此做了扼要的總結：
然后呢？就這些嗎？這就沒了！？ 這確實是讓人驚詫不已，因為 PostgreSQL 每年的大版本發布都有無數的新功能特性，例如計劃今秋發布的 PostgreSQL 17 還只是 beta1，就已然有著蔚為壯觀的新增特性列表：
而最近幾年的 PostgreSQL 新增特性甚至足夠專門編成一本書了。比如《快速掌握PostgreSQL版本新特性》便收錄了 PostgreSQL 最近七年的重要新特性 —— 將目錄塞的滿滿當當：
回頭再來看看 MySQL 9 更新的六個特性，后四個都屬于無關痛癢，一筆帶過的小修補，拿出來講都嫌丟人。而前兩個 向量數據類型 和 JS存儲過程 才算是重磅亮點。 BUT —— MySQL 9.0 的向量數據類型只是 BLOB 類型換皮 —— 只加了個數組長度函數，而這種程度的功能，28年前 PostgreSQL 誕生的時候就支持了。 而 Javascript 存儲過程支持竟然還是一個 企業版獨占特性，開源版不提供 —— 同樣的功能，13年前 的 PostgreSQL 9.1 就已經有了。 時隔八年的 “創新大版本” 更新就帶來了倆 “老特性”，其中一個還是企業版特供。“創新”這倆字，在這里顯得如此辣眼與諷刺。 糊弄了事的向量類型2023年，AI爆火，帶動了向量數據庫賽道。當下幾乎所有主流 DBMS 都已經提供向量數據類型支持 —— MySQL 除外。 用戶可能原本期待著在 9.0 創新版，向量支持能彌補一些缺憾，結果發布后等到的只有震撼 —— 竟然還可以這么糊弄？ 在 MySQL 9.0 的 官方文檔[6] 上，只有三個關于向量類型的函數。拋開與字符串互轉的兩個，真正的功能函數就一個
向量數據庫的門檻不是一般的低 —— 有個向量距離度量函數就行（內積，10行C代碼，小學生水平編程任務），這樣可以通過全表掃描求距離 + 但 MySQL 9 甚至連這樣一個最基本的向量距離函數都懶得去實現，這絕對不是能力問題，而是 Oracle 根本就不想好好做 MySQL 了。老司機一眼就能看出這里的所謂 “向量類型” 不過是 不糊弄的例子可以參考 MySQL 的老對手 PostgreSQL。在過去一年中，PG 生態里就涌現出了至少六款向量數據庫擴展（
在這一年內， 拿 向量是新的JSON[10]，然而向量數據庫的宴席都已經散場了，MySQL 都還沒來得及上桌 —— 它完美錯過了下一個十年 AI 時代的增長動能，正如它在上一個十年里錯過互聯網時代的JSON文檔數據庫一樣。 姍姍來遲的JS函數另一個 MySQL 9.0 帶來的 “重磅” 特性是 —— Javascript 存儲過程。 然而用 Javascript 寫存儲過程并不是什么新鮮事 —— 早在 2011 年，PostgreSQL 9.1 就已經可以通過 如果我們查看 DB-Engine 近十二年的 “數據庫熱度趨勢” ，不難發現只有 PostgreSQL 與 Mongo 兩款 DBMS 在獨領風騷 —— MongoDB (2009) 與 PostgreSQL 9.2 (2012) 都極為敏銳地把握住了互聯網開發者的需求 —— 在 “JSON崛起” 的第一時間就添加 JSON 特性支持（文檔數據庫），從而在過去十年間吃下了數據庫領域最大的增長紅利。
當然，MySQL 的干爹 —— Oracle 也在2014年底的12.1中添加了 JSON 特性與 Javascript 存儲過程的支持 —— 而 MySQL 自己則不幸地等到了 2024 年才補上這一課 —— 但已經太遲了！ Oracle 支持用 C，SQL，PL/SQL，Pyhton，Java，Javascript 編寫存儲過程。但在 PostgreSQL 支持的二十多種存儲過程語言面前，只能說也是小巫見大巫，只能甘拜下風了：
不同于 PostgreSQL 與 Oracle 的開發理念，MySQL 的各種最佳實踐里都不推薦使用存儲過程 —— 所以 Javascript 函數對于 MySQL 來說是個雞肋特性。然而即便如此，Oracle 還是把 Javascript 存儲過程支持做成了一個 MySQL企業版專屬 的特性 —— 考慮到絕大多數 MySQL 用戶使用的都是開源社區版本，這個特性屬實是發布了個寂寞。 日漸落后的功能特性MySQL 在功能上缺失的絕不僅僅是是編程語言/存儲過程支持，在各個功能維度上，MySQL 都落后它的競爭對手 PostgreSQL 太多了 —— 功能落后不僅僅是在數據庫內核功能上，更發生在擴展生態維度。 來自 CMU 的 Abigale Kim 對主流數據庫的可擴展性[14]進行了研究：PostgreSQL 有著所有 DBMS 中最好的 可擴展性（Extensibility），以及其他數據庫生態難望其項背的擴展插件數量 —— 375+，這還只是 PGXN 注冊在案的實用插件，實際生態擴展總數已經破千[15]。
這些擴展插件為 PostgreSQL 提供了各種各樣的功能 —— 地理空間，時間序列，向量檢索，機器學習，OLAP分析，全文檢索，圖數據庫，讓 PostgreSQL 真正成為一專多長的全棧數據庫 —— 單一數據庫選型便可替代各式各樣的專用組件：MySQL，MongoDB，Kafka，Redis，ElasticSearch，Neo4j，甚至是專用分析數倉與數據湖。
當 MySQL 還落在 “關系型 OLTP 數據庫” 的窠臼時， PostgreSQL 早已經放飛自我，從一個關系型數據庫發展成了一個多模態的數據庫，最終成為了一個數據管理的抽象框架與開發平臺。 PostgreSQL正在吞噬數據庫世界[16] —— 它正在通過插件的方式，將整個數據庫世界內化其中。“一切皆用 Postgres[17]” 也已經不再是少數精英團隊的前沿探索，而是成為了一種進入主流視野的最佳實踐。 而在新功能支持上，MySQL 卻顯得十分消極 —— 一個應該有大量 Breaking Change 的“創新大版本更新”，不是糊弄人的擺爛特性，就是企業級的特供雞肋，一個大版本就連雞零狗碎的小修小補都湊不夠數。 越新越差的性能表現缺少功能也許并不是一個無法克服的問題 —— 對于一個數據庫來說，只要它能將自己的本職工作做得足夠出彩，那么架構師與DBA總是可以多費些神，用各種其他的數據積木一起拼湊出所需的功能。 MySQL 曾引以為傲的核心特點便是 性能 —— 至少對于互聯網場景下的簡單 OLTP CURD 來說，它的性能是非常不錯的。然而不幸地是，這一點也正在遭受挑戰：Percona 的博文《Sakila：你將何去何從[18]》中提出了一個令人震驚的結論： MySQL 的版本越新，性能反而越差
根據 Percona 的測試，在 sysbench 與 TPC-C 測試下，最新 MySQL 8.4 版本的性能相比 MySQL 5.7 出現了平均高達 20% 的下降。而 MySQL 專家 Mark Callaghan 進一步進行了 詳細的性能回歸測試[19]，確認了這一現象：
盡管 MySQL 的優化器在 8.x 有一些改進，一些復雜查詢場景下的性能有所改善，但分析與復雜查詢本來就不是 MySQL 的長處與適用場景，只能說聊勝于無。相反，如果作為基本盤的 OLTP CRUD 性能出了這么大的折損，那確實是完全說不過去的。
Peter Zaitsev 在博文《Oracle最終還是殺死了MySQL[20]》中評論：“與 MySQL 5.6 相比，MySQL 8.x 單線程簡單工作負載上的性能出現了大幅下滑。你可能會說增加功能難免會以犧牲性能為代價，但 MariaDB 的性能退化要輕微得多，而 PostgreSQL 甚至能在 新增功能的同時顯著提升性能·[21]”。
MySQL的性能隨版本更新而逐步衰減，但在同樣的性能回歸測試中，PostgreSQL 性能卻可以隨版本更新有著穩步提升。特別是在最關鍵的寫入吞吐性能上，最新的 PostgreSQL 17beta1 相比六年前的 PG 10 甚至有了 30% ～ 70% 的提升。 在 Mark Callaghan 的 性能橫向對比[22] （sysbench 吞吐場景） 中，我們可以看到五年前 PG 11 與 MySQL 5.6 的性能比值（藍），與當下 PG 16 與 MySQL 8.0.34 的性能比值（紅）。PostgreSQL 和 MySQL 的性能差距在這五年間拉的越來越大。
幾年前的業界共識是 PostgreSQL 與 MySQL 在 簡單 OLTP CRUD 場景 下的性能基本相同。然而此消彼長之下，現在 PostgreSQL 的性能已經遠遠甩開 MySQL 了。PostgreSQL 的各種讀吞吐量相比 MySQL 高 25% ～ 100% 不等，在一些寫入場景下的吞吐量更是達到了 200% 甚至 500% 的恐怖水平。 MySQL 賴以安身立命的性能優勢，已經不復存在了。 無可救藥的隔離等級如果只是性能不好，總歸還有辦法來優化修補。但如果是正確性出了問題，那真就是無可救藥了。 《MySQL正確性竟如此拉垮？[23]》一文指出，在正確性這個體面數據庫產品必須的基本屬性上，MySQL 的表現一塌糊涂。 權威的分布式事務測試組織 JEPSEN[24] 研究發現，MySQL 文檔聲稱實現的 可重復讀/RR 隔離等級，實際提供的正確性保證要弱得多 —— MySQL 8.0.34 默認使用的 RR 隔離等級實際上并不可重復讀，甚至既不原子也不單調，連 單調原子視圖/MAV 的基本水平都不滿足。
MySQL 的 ACID 存在缺陷，且與文檔承諾不符 —— 而輕信這一虛假承諾可能會導致嚴重的正確性問題，例如數據錯漏與對賬不平。對于一些數據完整性很關鍵的場景 —— 例如金融，這一點是無法容忍的。 此外，能“避免”這些異常的 MySQL 可串行化/SR 隔離等級難以生產實用，也非官方文檔與社區認可的最佳實踐；盡管專家開發者可以通過在查詢中顯式加鎖來規避此類問題，但這樣的行為極其影響性能，而且容易出現死鎖。 與此同時，PostgreSQL 在 9.1 引入的 可串行化快照隔離（SSI） 算法可以用極小的性能代價提供完整可串行化隔離等級 —— 而且 PostgreSQL 的 SR 在正確性實現上毫無瑕疵 —— 這一點即使是 Oracle 也難以企及。
李海翔教授在《一致性八仙圖》論文中，系統性地評估了主流 DBMS 隔離等級的正確性，圖中藍/綠色代表正確用規則/回滾避免異常；黃A代表異常，越多則正確性問題就越多；紅“D”指使用了影響性能的死鎖檢測來處理異常，紅D越多性能問題就越嚴重； 不難看出，這里正確性最好（無黃A）的實現是 PostgreSQL SR，與基于PG的 CockroachDB SR，其次是略有缺陷 Oracle SR；主要都是通過機制與規則避免并發異常；而 MySQL 出現了大面積的黃A與紅D，正確性水平與實現手法糙地不忍直視。 做正確的事很重要，而正確性是不應該拿來做利弊權衡的。在這一點上，開源關系型數據庫兩巨頭 MySQL 和 PostgreSQL 在早期實現上就選擇了兩條截然相反的道路：MySQL 追求性能而犧牲正確性；而學院派的 PostgreSQL 追求正確性而犧牲了性能。 在互聯網風口上半場中，MySQL 因為性能優勢占據先機乘風而起。但當性能不再是核心考量時，正確性就成為了 MySQL 的 致命出血點。更為可悲的是，MySQL 連犧牲正確性換來的性能，都已經不再占優了，這著實讓人唏噓不已。 枯萎收縮的生態規模對一項技術而言，用戶的規模直接決定了生態的繁榮程度。瘦死的駱駝比馬大，爛船也有三斤釘。MySQL 曾經搭乘互聯網東風扶搖而起，攢下了豐厚的家底，它的 Slogan 就很能說明問題 —— “世界上最流行的開源關系型數據庫”。
不幸的是在 2023 年，至少根據全世界最權威的開發者調研之一的 StackOverflow Annual Developer Survey[25] 結果來看，MySQL 的使用率已經被 PostgreSQL 反超了 —— 最流行數據庫的桂冠已經被 PostgreSQL 摘取。 特別是，如果將過去七年的調研數據放在一起，就可以得到這幅 PostgreSQL / MySQL 在專業開發者中使用率的變化趨勢圖（左上） —— 在橫向科比的同一標準下，PostgreSQL 流行與 MySQL 那魘葡緣靡荒苛巳弧�
對于中國來說，此消彼長的變化趨勢也同樣成立。但如果對中國開發者說 PostgreSQL 比 MySQL 更流行，那確實是違反直覺與事實的。 將 StackOverflow 專業開發者按照國家細分，不難看出在主要國家中（樣本數 > 600 的 31 個國家），中國的 MySQL 使用率是最高的 —— 58.2% ，而 PG 的使用率則是最低的 —— 僅為 27.6%，MySQL 用戶幾乎是 PG 用戶的一倍。 與之恰好反過來的另一個極端是真正遭受國際制裁的俄聯邦：由開源社區運營，不受單一主體公司控制的 PostgreSQL 成為了俄羅斯的數據庫大救星 —— 其 PG 使用率以 60.5% 高居榜首，是其 MySQL 使用率 27% 的兩倍。
中國因為同樣的自主可控信創邏輯，最近幾年 PostgreSQL 的使用率也出現了顯著躍升 —— PG 的使用率翻了三倍，而 PG 與 MySQL 用戶比例已經從六七年前的 5:1 ，到三年前的3:1，再迅速發展到現在的 2:1，相信會在未來幾年內會很快追平并反超世界平均水平。畢竟，有這么多的國產數據庫，都是基于 PostgreSQL 打造而成 —— 如果你做政企信創軟件生意，那么大概率已經在用 PostgreSQL 了。 拋開政治因素，用戶選擇使用一款數據庫與否，核心考量還是質量、安全、效率、成本等各個方面是否“先進”。先進的因會反映為流行的果，流行的東西因為落后而過氣，而先進的東西會因為先進變得流行，沒有“先進”打底，再“流行”也難以長久。號稱“最流行”的 MySQL，終究還是難敵時間的審判。 究竟是誰殺死了MySQL？MySQL 曾經也輝煌過，但再精彩的演出也會落幕。 MySQL 正在死去 —— 更新疲軟，功能落后，性能劣化，質量出血，生態萎縮，此乃天命，實非人力所能救也。但究竟是誰殺死了 MySQL，難道是 PostgreSQL 嗎？Peter Zaitsev 在《Oracle最終還是殺死了MySQL》一文中控訴，Oracle 的不作為與瞎指揮最終害死了 MySQL；并在后續《Oracle還能挽救MySQL嗎》一文中指出了真正的根因： MySQL 的知識產權被 Oracle 所擁有，它不是像 PostgreSQL 那種 “由社區擁有和管理” 的數據庫，也沒有 PostgreSQL 那樣廣泛的獨立公司貢獻者。不論是 MySQL 還是其分叉 MariaDB，它們都不是真正意義上像 Linux，PostgreSQL，Kubernetes 這樣由社區驅動的的原教旨純血開源項目，而是由單一商業公司主導。 比起向一個商業競爭對手貢獻代碼，白嫖競爭對手的代碼也許是更為明智的選擇 —— AWS 和其他云廠商利用 MySQL 內核參與數據庫領域的競爭，卻不回饋任何貢獻。于是作為競爭對手的 Oracle 也不愿意再去管理好 MySQL，而干脆自己也參與進來搞云 —— 僅僅只關注它自己的 MySQL heatwave 云版本，就像 AWS 僅僅專注于其 RDS 管控和 Aurora 服務一樣。在 MySQL 之死上，云廠商也難辭其咎。
逝者不可追，來者猶可待。PostgreSQL 應該從 MySQL 上吸取教訓 —— 盡管 PG 社區已經非常小心地避免出現一家獨大的情況出現，但生態確實在朝著幾家巨頭云廠商作大壟斷的不利方向發展。 云正在吞噬開源 —— 云廠商編寫了開源軟件的管控軟件，組建了專家池，通過提供維護攫取了軟件生命周期中的絕大部分價值，但卻通過搭便車的行為將最大的成本 —— 產研交由整個開源社區承擔。 云上 真正有價值的管控/監控代碼卻從來不回饋開源社區 —— 在數據庫領域，我們已經在 MongoDB，ElasticSearch，Redis，以及 MySQL 上看到了這一現象，而 PostgreSQL 社區確實應當引以為鑒。 好在 PG 生態總是不缺足夠頭鐵的人和公司，愿意站出來維護生態的平衡，反抗公有云廠商的霸權。例如，我自己開發的 PostgreSQL 發行版 Pigsty，旨在提供一個開箱即用、本地優先的開源云數據庫 RDS 替代，將社區自建 PostgreSQL 數據庫服務的底線，拔高到比云廠商 RDS PG 更高的水平線。 而另一個《云計算泥石流[31]》系列專欄則旨在扒開云服務背后的信息不對稱，從而幫助公有云廠商更加體面，亦稱得上是成效斐然。
盡管我是 PostgreSQL 的堅定支持者，但我也贊同 Peter Zaitsev 的觀點：“如果 MySQL 徹底死掉了，開源關系型數據庫實際上就被 PostgreSQL 一家壟斷了，而壟斷并不是一件好事，因為它會導致發展停滯與創新減緩。PostgreSQL 要想進入全盛狀態，有一個 MySQL 作為競爭對手并不是壞事”。 —— 至少，MySQL 可以作為一個與鞭策激勵，讓 PostgreSQL 社區保持凝聚力與危機感，不斷提高自身的技術水平，保持開放、透明、公正的社區治理模式，從而繼續推動數據庫技術的發展。 PostgreSQL 帶著開源軟件的初心與愿景繼續堅定前進 —— 它將走上 MySQL 未走完的長路，寫完 MySQL 未寫完的詩篇，見到 MySQL 未見的世界，活成 MySQL 未曾活過的愿。在這，謹以一首《PG駛向云外，MySQL安魂九霄》，送給曾經的對手 —— MySQL。 PG駛向云外，MySQL安魂九霄我那些殘夢，靈異九霄 徒忙漫奮斗，滿目滄愁 在滑翔之后，完美墜落 在四維宇宙，眩目遨游 我那些爛曲，流竄九州 云游魂飛奏，音憤符吼 在宿命身后，不停揮手 視死如歸仇，毫無保留 黑色的不是夜晚，是漫長的孤單 看腳下一片黑暗，望頭頂星光璀璨 嘆世萬物皆可盼，唯真愛最短暫 失去的永不復返，世守恒而今倍還 搖旗吶喊的熱情，攜光陰漸遠去 人世間悲喜爛劇，晝夜輪播不停 紛飛的濫情男女，情仇愛恨別離 一代人終將老去，但總有人正年輕
References
該文章在 2024/7/25 12:30:58 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
