[閒聊] Google棄甲骨文MySQL，導入MariaDB
日前，Google捨MySQL朝MariaDB轉移的意圖，終於進入明朗化階段。在今年超大型資料庫
（XLDB）會議中，Google網站可靠度部門（SRE，Site Reliability Engineer）的資深系
統工程師，同時也負責Google內部MySQL資料庫的Jeremy Cole揭露了Google大規模汰換
MySQL的計畫。
他在XLDB會議的演講中表示，Google正計畫淘汰內部數千臺MySQL資料庫，改換用另一個
開源資料庫MariaDB，目前也有部分資料庫已改用MariaDB最新的10.0版。
日前，MariaDB基金會成員之一的SkySQL執行長Patrik Sallner也向國外媒體透露，
Google在2013年初就開始與MariaDB基金會接洽，希望能在轉換過程中，降低資料庫遷徙
的負擔與風險。
甲骨文MySQL封閉色彩逐漸濃厚
MariaDB是從MySQL獨立出來的另一套衍生資料庫（Folk版本），而且都來自相同的創始人
Michael Widenius（代號Monty）和其他創始人在1994年開始開發MySQL，2008年將MySQL
賣給了昇陽電腦，傳為開源軟體商業化的經典案例。
2年後，MySQL更推出大受歡迎的5.5版，但甲骨文卻收購了昇陽電腦。MySQL二度易主，
MySQL社群擔心甲骨文箝制而紛紛出走，Michael Widenius因而推出了與MySQL相容的
MariaDB，而MySQL原有高層則成立了SkySQL公司，廣納舊版MySQL的開發工程師，來與甲
骨文主導的MySQL分庭抗禮，目前，MySQL最被廣泛使用的是2010年的5.5版，2013年推出
的5.6版還未普及。
Google早在MySQL 4.0版時就開始採用。Google離職員工Benjy Weinberger在Quora網站上
透露，在Google開發出BigTable檔案系統前，很多服務都使用MySQL。直到2010年，
Google的賺錢金雞母Google Ads廣告服務，還大量使用MySQL叢集。直到現在，Jeremy
Cole在演講中透露，Google仍有許多MySQL資料庫，其版本橫跨了古老的4.0版，到較新的
MySQL 5.1版。
不過，他在這場演講中並未進一步提及Google資料庫遷徙的詳情，而是用個人身分從技術
角度出發，分享Google的MySQL資料庫使用經驗。但從他對MySQL的評價中，也能一窺
Google用MariaDB取代MySQL背後的考量。
首先，Jeremy Cole認為，MySQL的優點是，簡易查詢的效率較高，對於一個簡易查詢的要
求，通常能以小於500微秒（μs）的時間回應，此外，MySQL也有一個相對穩定的資料儲
存層InnoDB，最後，MySQL的安裝與操作都相對容易，同時也有許多網路上的學習資源可
供利用。
但MySQL的缺點是不擅長應付圖形資料（Graph Data），而且大量執行ID generation功能
時效率慢，他認為，主導MySQL的甲骨文著重於追加一些華麗的新功能，而忽視了MySQL的
穩定性與整體效率。綜觀以上特性，他認為，MySQL適合用管理小於1.5TB的資料，或者作
為大量資料的後端備份系統。
此外，Jeremy Cole認為，甲骨文主導下的MySQL，在正式釋出可用版，對外揭露的資訊不
足，十分缺乏透明度，而且，甲骨文較少修正來自使用者回報的臭蟲、也不常聽取開發社
群的討論、意見與對新功能的需求，雖然MySQL是開放源碼的資料庫，但他認為，甲骨文
的作為，讓MySQL的封閉性色彩逐漸濃厚。
而MariaDB雖然MySQL是同源所生的程式碼，但運作的理念卻有很大的不同。Jeremy Cole
表示，MariaDB是由Michael Widenius領導，並囊括了許多最初開發MySQL的開發人員，創
立目的就是為了擺脫甲骨文的控制。它採用了新的儲存引擎，並以相容於甲骨文的MySQL
5.5版本為出發點，目前的MariaDB 10.0版，就是建立在MySQL 5.6版本的完全複製版本（
Fork）之上。
痞客邦研發副理林瑞男也表示，甲骨文在2010主導了MySQL之後，有逐漸將原始碼封閉的
傾向，因此，開源碼社群以MySQL為基礎另起爐灶，發展出了MariaDB的分支，希望維持開
放源碼的特性。
林瑞男認為以甲骨文對MySQL的封閉態度，加上MariaDB和MySQL到目前為止其資料格式可
以互通，導致許多企業都有將資料庫系統轉換的打算，例如，維基百科早已將資料庫從
MySQL換成MariaDB、而Linux作業系統Red Hat、SUSE也採用了MariaDB作為其網站資料庫
，種種跡象越來越顯示出甲骨文主導的MySQL勢力已經開始動搖了。
MySQL創始人：MySQL轉移至MariaDB逐漸成潮流
而MySQL的創始人Michael Widenius也以電子郵件回覆，信中分析了Google捨棄MySQL而改
用MariaDB的原因，究其原因，可以個別從甲骨文 MySQL的推力和MariaDB的拉力兩個方面
來談。
首先，甲骨文 MySQL並不支援外部的更新（Patch）機制，甲骨文並未保證未來MySQL程式
碼的開放性，此外，MySQL對於越來越多新的程式碼，也不再提供測試環境，他認為，這
樣的封閉性，將讓甲骨文之外的開發者，幾乎完全無法在甲骨文的MySQL上撰寫新的功能
。
反觀，採用MariaDB的企業能夠直接與開源碼社群的開發者討論，計畫開發新功能，另一
方面，MariaDB也永久保證了其開放源碼的特性，他說，對於Google而言，最重要的是
MariaDB提供了許多業務上的關鍵的功能，例如全域交易辨識碼（Global Transaction ID
）、平行複製（Parallel Replication）、多來源複製（Multi Source Replication）、
以及集體上傳（Group Commit）等功能。
此外，Michael Widenius也認為，Google在其核心資料庫管理系統上，是想要企圖擺脫甲
骨文的控制，他表示，目前已經有越來越多的企業企圖從MySQL轉換成MariaDB，MariaDB
將成為未來資料庫的主流。
而由於MariaDB與MySQL是位元相容的（Binary Compatible），其資料格式也都可互通，
而所有與MySQL相關的工具、應用程式與連接器（Connector），都可以直接在MariaDB上
使用，Michael Widenius表示，這代表著MySQL的使用者可以輕易的將系統轉移至MariaDB
。
超過一半的SkySQL客戶從MySQL轉至MariaDB
此外，他也表示，MariaDB在因應複雜的查詢上，效率高過MySQL，而在複製設定（
Replication Setup）上的速度，MariaDB也比MySQL高出許多。他認為，這個轉換已經明
顯形成未來的趨勢，SkySQL公司提供超過400家的企業資料庫的支援服務，其中包括維基
百科等，超過200家的企業都已經從MySQL轉移至MariaDB，他對於企業捨棄甲骨文主導下
的MySQL而朝更開放的資料庫管理系統邁進的趨勢，抱持著十分確定的態度。
林瑞男則表示，痞客邦當初之所以選擇MySQL，在於其支援資源豐富，容易找到參考資料
與顧問，此外，目前MySQL使用的企業也較多，意味著使用、維護上的問題大多可以找到
解答。
然而，目前痞客邦的資料庫，也已非甲骨文下的MySQL，而是Percona所提供的MySQL分支
版本，痞客邦會於此版本中繼續維護、開發。林瑞男也表示，視MariaDB的發展情況，未
來痞客邦也有可能將資料庫管理系統遷移至MariaDB。文⊙楊智傑
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 27.105.57.23
→
09/26 23:16, , 1F
09/26 23:16, 1F
→
09/26 23:16, , 2F
09/26 23:16, 2F
→
09/26 23:56, , 3F
09/26 23:56, 3F
→
09/26 23:56, , 4F
09/26 23:56, 4F
推
09/27 00:11, , 5F
09/27 00:11, 5F
推
09/27 00:35, , 6F
09/27 00:35, 6F
推
09/27 02:11, , 7F
09/27 02:11, 7F
→
09/27 02:58, , 8F
09/27 02:58, 8F
→
09/27 05:31, , 9F
09/27 05:31, 9F
推
09/27 08:07, , 10F
09/27 08:07, 10F
推
09/27 08:13, , 11F
09/27 08:13, 11F
→
09/27 08:14, , 12F
09/27 08:14, 12F
推
09/27 08:31, , 13F
09/27 08:31, 13F
推
09/27 08:51, , 14F
09/27 08:51, 14F
推
09/27 09:13, , 15F
09/27 09:13, 15F
→
09/27 09:13, , 16F
09/27 09:13, 16F
→
09/27 09:14, , 17F
09/27 09:14, 17F
→
09/27 09:15, , 18F
09/27 09:15, 18F
推
09/27 09:17, , 19F
09/27 09:17, 19F
推
09/27 11:02, , 20F
09/27 11:02, 20F
推
09/27 12:57, , 21F
09/27 12:57, 21F
推
09/27 14:08, , 22F
09/27 14:08, 22F
推
09/27 15:05, , 23F
09/27 15:05, 23F
推
09/27 21:19, , 24F
09/27 21:19, 24F
→
09/27 21:19, , 25F
09/27 21:19, 25F
推
09/27 22:35, , 26F
09/27 22:35, 26F
推
09/28 11:28, , 27F
09/28 11:28, 27F
推
09/28 11:36, , 28F
09/28 11:36, 28F
→
09/29 11:55, , 29F
09/29 11:55, 29F