MySQL對決：MySQL與MariaDB孰優孰劣？

【IT168 評論】也許你對MySQL資料庫新秀MariaDB有所耳聞，作為MySQL的又一分支，MariaDB誕生於甲骨文收購Sun公司之後。MariaDB擁有諸多值得認真體味的優秀特性，這不僅是由於MariaDB專案由MySQL最初創始人Monty Widenius所建立，更因為它與MySQL始終保持著緊密聯絡。

　　先從相關技術社群所能提供的支援與除錯積極性入手，考慮利用MariaDB替代MySQL的可行性。舉例來說，如果要付費簽訂一套技術支援協議，並且把甲骨文方案作為理想的支援交付機制，那麼MySQL無疑是最合理的選擇。然而，如果能把高高在上的MySQL叢集CGE(即運營商級版本)的姿態放低一些，那麼甲骨文提供的社群版本顯然更為合適。

　　如何做出具體取捨要看各企業技術團隊的實際情況以及他們對開源文化的熟悉程度。如果他們更喜歡從甲骨文的諮詢服務中心獲取支援資訊以及官方解答，那麼MySQL將成為理想的選擇。

　　與MySQL相近的使用感受

　　對於那些打算儘早擺脫甲骨文控制的MySQL使用者來說，相容性無疑是需要關注的首要問題。這也是MariaDB向下相容特性如此重要的關鍵所在。向下相容意味著什麼?

　　儘管兩款軟體包的名稱有所區別，但檢查其資源庫時，一定會發現二者之間存在著千絲萬縷的聯絡與高度一致的相似之處。命令列工具的二進位制名稱，例如mysqladmin、mysqldump、mysql shell以及後臺程式都保持著名稱上的統一。更進一步，二者的資料檔案彼此之間也完全相容。MariaDB能夠直接與現有MySQL例項中的資料檔案及表定義順利協作。

　　持續不斷的改進步伐

　　向下相容的可貴之處在於不需要對應用程式做出任何形式或程度上的改動。利用MariaDB取代MySQL之後，大家能夠立即享受由此帶來的效能提升。來自Facebook、Twitter、谷歌以及Percona等媒體平臺的社群支援將搶先一步入駐MariaDB，而後才逐步在MySQL中鋪開。

　　MariaDB還通過資料檢索資訊模式給使用者帶來更令人滿意的處理手段，其中包括微秒支援。如果大家正在使用TIME或者DATETIME資料型別，則可以為其指定特殊精度，例如TIME(4)，括號中的數字代表小數點後顯示多少位。MariaDB最高支援到小數點後六位——也就是0.000001秒或者稱之為1微秒。這已經是小得不能再小的時間單位了。而對於那些沒有特別指定精度的用例，MariaDB會預設忽略小數點後的餘數以簡化讀取難度。

　　你們一定有過在MySQL中執行執行時間超長的ALTER TABLE，一直等到滿腔怒火的經歷。MariaDB會為這類操作提供一套命令列程式指示器，這樣大家就可以預先估計執行所需要的時間。這確實是一項令人拍手叫好的創新。

　　查詢執行對於面向Web的應用程式來說往往算是一項重大挑戰。MySQL查詢執行背後的實際大腦其實是查詢優化器，MariaDB在這方面也做出了一系列顯著改進，包括更好的子查詢優化效果、更快的執行速度、更高的執行效率以及更具一致性的連線、匯出表以及檢視等。另外，MariaDB為使用者提供額外的控制選擇，用於設定優化器如何做出決定、如何顯示更多內部處理流程以及如何通過伺服器引數完成配置工作。

　　MariaDB還提供一系列經過合併的核心強化機制，移除了對效能影響極大的互斥器。所謂互斥器，是一種在核心中連續訪問資源的鎖定機制。如果資源目前正處於佔用狀態，程式就必須保持等待直到資源再次可用。MySQL核心中的現有互斥器始終在現代硬體當中也會造成非常嚴重的拖慢現象。將其取消幫助MariaDB順利與如今愈發常見的大型SMP裝置相對接。

　　最後，如果大家希望向基於單元的複製機制轉移但卻受制於單元複製日誌中的SQL宣告問題，MariaDB也拿出了很好的解決方案。

　　基於單元的複製機制並非始終可讀，因為使用者一直在傳送原始資料塊，也就是資料在傳送之前與之後的“映象”而非實際執行的SQL宣告。資料塊被交付至從資料庫當中並直接寫入檔案，而不再由SQL進行重複執行。由於這個原因，SQL宣告無法成為MySQL日誌內容的一部分。

　　而在MariaDB當中，SQL宣告被記錄在專門針對單元複製流程的庫日誌裡，其處理方式與基於宣告的複製完全相同。這部分SQL宣告能夠有效幫助管理人員進行故障排查並在特定情況下實現時間點恢復目標。MariaDB的此項改進堪稱雪中送炭。

　　進一步挑戰極限

　　對於那些希望進一步挑戰極限的使用者來說，MariaDB所具備的功能足以打破固有MySQL功能的束縛。

　　初學者可以在兩套高效能儲存引擎當中做出選擇：Aria與XtraDB。儘管二者都不具備對現有MySQL部署的向下相容能力，但我們仍然可以通過一條簡單的ALTER命令在這些引擎中重新建立表。

　　即將迎接的是一種名為Galera的全新叢集化技術。這種技術與NDB Cluster及其它知名方案完全不同。Galera允許主動-主動多體更新，這一點在NDB Cluster中由於JOIN的侷限而無法完成。現在大家可能真正對雲伺服器進行規模化寫入，更令人欣喜的是，我們甚至能夠使用並行及同步複製功能。

　　想要獲得NoSQL般的理想速度?HandlerSocket外掛是個不錯的選擇，它可以在不經過優化器的情況下直接訪問儲存引擎，從而一舉將速度提升到原先的十倍以上。大家現在還可以利用MariaDB中的動態列機制獲取大量JSON格式的返回資料——這同樣是MySQL所無法企及的。

　　MariaDB中還包含另一套全新儲存引擎，這就是Cassandra SE。它允許使用者向一套Cassandra資料儲存體系內寫入或者讀取資料。SQL與NoSQL之間的融合終於不再令人頭痛。

　　想要合併來自不同主資料庫內的資料?多源複製功能正是滿足大家需求的最佳方案。假設我們的源資料被儲存在多個例項當中，MariaDB能夠將它們同時引導到同一個下游例項當中——這樣的效果在MySQL中仍然無法實現。

　　如果前面提到的這些新特性還不足以吸引你，MariaDB還擁有一套殺手鐗——它其實是一個完全遵循GPL許可的MySQL版本。所有相關外掛及功能元件都是開源方案，這相當於幫助使用者在安全性及除錯識別透明度等各個方面都享受到了開源帶來的便利。MySQL則適用於GPL或者由甲骨文提供的商業許可，這就導致一部分元件開源、另一部分閉源。

　　在蘋果和桔子之間做出選擇

　　如果大家正著手評估各類MySQL替代發行版，肯定需要認真權衡它們各自的優勢與弱項。

　　就以Percona為例，它足以成為甲骨文MySQL社群版本的另一種替代方案。Percona往往在引入新功能方面表現得更為保守，這相當於在穩定性方面做出一丁點提升、但卻在獲得最新最優秀的功能方面畏首畏尾。Percona相對於MySQL也算得上是很大的進步，不過也許仍然無法像MariaDB那樣為我們帶來業界頂尖的解決方案。

　　Drizzle也是MySQL替代者大家庭中的另一位成員，只不過它的特色在於通過重新編寫適應雲部署環境。它確實屬於開源專案沒錯，但卻並沒能提供面向MySQL的向下相容能力。大家需要捨棄原有資料並重新載入新資料，甚至對應用程式做出調整，只有這樣它才能順暢地執行下去。

　　雖然MariaDB在普及程度上與Percona尚存在一定差距，但它的人氣增長速度卻不容小覷。舉例來說，紅帽公司就已經在自己的企業發行版中利用MariaDB取代MySQL;谷歌公司最近也針對MariaDB專案組織了一次工程師投票。在欣欣向榮的MySQL替代方案領域，MariaDB正以日益壯大之勢穩步邁向王者寶座。

　　原文連結：MySQL face-off: MySQL or MariaDB?

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26435490/viewspace-1076758/，如需轉載，請註明出處，否則將追究法律責任。