最近討論 Uber 的 MySQL 換 PostgreSQL 後又換回 MySQL 的文章...

先把兩份連結丟出來,一份是 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

3 thoughts on “最近討論 Uber 的 MySQL 換 PostgreSQL 後又換回 MySQL 的文章...”

  1. 我看到的卻不是 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 以上的版本

  2. I do not see any other database do better (fast and flexible) replication than MySQL does. not even close

  3. 以 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

Leave a Reply

Your email address will not be published. Required fields are marked *