如何評價 Uber 從 PostgreSQL 改為 MySQL？

01-07

原文： Why Uber Engineering Switched from Postgres to MySQL

We encountered many Postgres limitations:

Inefficient architecture for writes

Inefficient data replication

Issues with table corruption

Poor replica MVCC support

Difficulty upgrading to newer releases

以及

為PostgreSQL討說法 - 淺析《UBER ENGINEERING SWITCHED FROM POSTGRES TO MYSQL》--- by digoal

補充介紹一下digoal，外號德哥，非常嚴謹認真的dba，至今有10年的pg經驗，對於pg的技術發展變更一直和社區同步，常年推廣和普及pg，發表了大量的原創和翻譯的文章，錄製了大量詳細的pg相關的操作視頻，入門的深入的都有涉及，各種pg大會的組織者，在業界是非常知名的技術專家，對pg有興趣的可以關注一下。

歪個樓，鄙司某部門用的是pg，萬年不變的8.3，每次運維在新機上部署都是一番折磨。由於高低版本pg有一定程度不兼容，再加上相關研發早已離職，這部分業務就鎖定在了低版本pg，新代碼也被迫遷就，這種情況已經持續多年......

Uber之前就換過啊 Migrating Uber from MySQL to PostgreSQL

顯然是人的問題，沒有pg的expert，周圍一看去，哎，mysql有幾個dba還不錯，轉了吧。

從hacker news和reddit的討論來看，uber真是裝逼不成反被操啊。

uber本來名聲就不好，再來個這個顯得水平真的很爛，還想好好招人么？

問題其實很簡單：將PG從9.2升級到9.6比從直接切換到MySQL還費勁。

估計它們的技術人員不會用～

而且他們用的是9.2.....

Uber還是同一個人Evan Klitzk發的文章

Migrating Uber from MySQL to PostgreSQL

Why Uber Engineering Switched from Postgres to MySQL

按應用場景來說，都同意，除了最後那個點，然而按這個思路...MySQL也不是最優選啊~

A PostgreSQL Response to Uber

不能因為是Uber，它把資料庫換到MySQL，就像一些別有用心的人各種PG不好，過度解讀，這是很讓人反感的。在使用一個產品的過程遇到問題是正常的，換解決方案也是正常的，我們也換過DBMS，任何一個解決方案都不可能對每種場景都是最優的，更有可能是客戶自己深入的不到位導致了業務性能問題，寫個類都不能保證每個程序員能正確的調用，別說這麼複雜的DBMS，更別說換到MySql不遇到其它棘手的問題。PG是非常優秀的資料庫，無數商用成功案例，我也推薦digoal關於PG的各種技術解讀深入了解PG。

當然，不可否認，MySql也是非常優秀的資料庫......

Uber 的文章基本上是在說他們發現 MySQL 比 PostgreSQL 更適合他們的環境。不過這篇文章傳遞消息的方式卻非常的糟糕。他們應該寫「PostgreSQL 在重度更新操作場景下的一些限制」而不是「寫架構的缺陷」。例如，如果你的使用場景並非重度寫操作的，就無需擔心 Uber 描述的這些問題。

postgres名字很長我喜歡

uber各個系統用的技術堆棧也是不一樣的有的從mysql遷出有的遷入mysql 都很正常隨著需求的變化改變技術的選型是十分正常的事情不必大驚小怪的

anyway 解決痛點才是第一要務換不換mysql都是小事～

其實Uber的軟體系統平台的負載均衡調教好以後，具體使用MS SQL還是mysql都是沒有任何影響的，全部系統都低耦合地進行了有效隔離。

PostgreSQL的query planner極爛

合適就是最好用的, 支持各種轉.

uber這些人都是腦殘么？用Maria DB也不至於用MySQL啊