先把兩份連結丟出來,一份是 PyPgDay 2013 時由 Uber 的 Evan Klitzke 給的「Migrating Uber from MySQL to PostgreSQL」,原 PDF 連結已經失效 (看起來已經被刪除),但這個網路年代什麼都可以找到備份... 可以在「Migrating Uber from MySQL to PostgreSQL」取得,但這個網站怪怪的,我另外丟了一份到 Google Docs 上。
另外一份則是同一個人 Evan Klitzke 在 2016 年發表於公司的官方網站上:「Why Uber Engineering Switched from Postgres to MySQL」。
2013 年描述了從 MySQL 換到 PostgreSQL,2016 年同一個人出來則描述了從 PostgreSQL 換到 MySQL 的理由,有種臉腫腫的感覺。
先抓 2013 年的重點,當時分享的目標是要用 PostGIS:

在 2016 年的文章絕口不提 PostGIS,而是提到各種效能問題:花了很長的篇幅講 Non-clustered Index 與 Clustered Index 的設計,以及 Replication 時的頻寬效能差異。
先不管 PostGIS,如果真的是 UPDATE 造成效能問題,那麼不是要朝 sharding 解決嗎,怎麼是換成 MySQL?換到 MySQL 後還是會遇到效能問題啊,你還是要在 application 層上面找出方案啊。
這篇文章看起來更像是內部技術與政治問題掛勾在一起談,因為政治原因而換 MySQL,然後找出技術原因說明換的理由 XDDD
我看到的卻不是 Uber 他們說 UPDATE 有什麼效能問題,而是:
1. PostgreSQL 的 WAL Replication 會消耗大量頻寬
2. PostgreSQL 的 WAL Replication 會讓你在升級 PostgreSQL 版本的時候有很長的 downtime
3. PostgreSQL 的 WAL Replication 有淺在的風險可能讓 index 損毀
而為什麼會有上面 1, 2 點狀況,就是上面提到的 index 如何在硬碟儲存還有 WAL 設計有關
至於第 3 點,是曾經在 9.2 時有個 bug 使 replica 套用錯 WAL 記錄,導致 index 壞掉。Uber 擔心這種 bug 未來可能還會再出現
文章後面也有提到,如果是使用 PostgreSQL 的話,最好使用 pglogical 來做 replication
不過 pglogical 只支援 9.4 以上的版本
I do not see any other database do better (fast and flexible) replication than MySQL does. not even close
以 RTT 來說,通常 PostgreSQL UPDATE 會比 MySQL/InnoDB 快,但當 Table 有著很多 Indexes 又在 udpate-heavy 場景時,情況就不同了。PostgreSQL 會因為頻繁更新相關 Indexes 而更慢甚至有寫次數放大的問題。雖然很多 PostgreSQL 專家提到 HOT updates,但對 Uber 的場景沒太大作用,因為 HOT updates 是有條件限制的。
不過 gslin 前輩舉 2013 年簡報應該是沒有意義的。Uber 高級主任工程師最近已宣稱,MySQL 是用於新的應用,而且他們現在還有很多 PostgreSQL,所以或許可以合理猜測,2013 年簡報提的 PostGIS 應用目前還存在,而且還是 PostgreSQL。
https://news.ycombinator.com/item?id=12217179