【51CTO精選譯文】MySQL集群是一款實時、可擴展的事務(wù)性數(shù)據(jù)庫。其設(shè)計初衷在于為對實時性能要求較高的應(yīng)用程序打造一套嵌入式電信數(shù)據(jù)庫，并實現(xiàn)運營商級別的可用性。不過MySQL集群也可以通過擴展實現(xiàn)諸多企業(yè)級解決方案，例如移動支付系統(tǒng)、實時分析、數(shù)據(jù)流與分析以及內(nèi)容管理等事務(wù)。MySQL集群的橫向擴展能力足以滿足密集型工作負載的需求，其集群架構(gòu)如下圖所示：

整信集群由三類節(jié)點構(gòu)成：數(shù)據(jù)節(jié)點、應(yīng)用程序節(jié)點以及管理節(jié)點。

• 數(shù)據(jù)節(jié)點通常負責數(shù)據(jù)訪問與存儲事務(wù)。
• 應(yīng)用程序節(jié)點提供由應(yīng)用程序邏輯層及應(yīng)用API指向數(shù)據(jù)節(jié)點的鏈接。
• 管理節(jié)點在集群配置體系中的作用至關(guān)重要，并在網(wǎng)絡(luò)分區(qū)環(huán)境下負責負載指派。

在本文中，我們將共同探討提升MySQL集群性能的***實踐方案。通過這些方案，大家將能在各類工作負載中實現(xiàn)游刃有余的資源分配效果。

最適合MySQL集群的應(yīng)用程序

MySQL集群能確保來自應(yīng)用程序或者SQL節(jié)點的更新立即被用于集群體系中的每一個節(jié)點。表格被劃分至一系列商用節(jié)點當中，從而實現(xiàn)數(shù)據(jù)庫的橫向可擴展性。

MYSQL集群在數(shù)據(jù)庫層處理表格劃分，這就避免了對應(yīng)用程序?qū)拥挠绊?。這一特性能夠大大簡化應(yīng)用程序的開發(fā)與維護工作。在事務(wù)性工作負載方面，MySQL集群還能提供非常強大的數(shù)據(jù)吞吐能力。另外，這套集群可以利用多個并行SQL節(jié)點，且每個節(jié)點都提供多個連接。

最適合MySQL集群的應(yīng)用程序包括：

• 交易平臺/系統(tǒng)；
• 支付網(wǎng)關(guān)；
• 用戶配置管理；
• 多人網(wǎng)絡(luò)游戲；
• IMS服務(wù)；
• DHCP寬帶接入；
• VoIP及視頻會議。

識別性能問題

我們一直建議大家對延遲及事務(wù)數(shù)據(jù)吞吐量等性能指標進行重復(fù)檢測方針。另一大關(guān)注重點在于考量數(shù)據(jù)庫的特定變更及其可用性。大家應(yīng)該在變更實際部署前進行性能測試，并在優(yōu)化技術(shù)安置完畢后再次進行測試。

在某些情況下，我們可能無意中遇上必須滿足的特殊需求。通過迭代流程，大家可以追蹤目標的當前進展。除了檢測應(yīng)用程序的整體性能，大家還應(yīng)該考慮個別事務(wù)的性能表現(xiàn)。某些查詢請求可能需要很長時間才能執(zhí)行完畢。

如果大家利用SQL對接入MySQL Enterprise Monitor的數(shù)據(jù)庫進行查詢，那么不妨試試Query Analyzer--它能追蹤所有負載較高的事務(wù)。如果大家沒有接入Enterprise Monitor，那么MySQL慢速查詢?nèi)罩疽沧阋詭椭覀冋页鎏幚磉^程過長的事務(wù)。我們可以通過對long_query_time變量的設(shè)定選擇日志中到底應(yīng)該保留哪些慢速查詢（即慢到何種程度）。變量數(shù)值的單位是"秒"，將該數(shù)值設(shè)為"0"則代表在日志中記錄下所有查詢請求。

由于對long_query_time變量所做出的變更不會馬上體現(xiàn)在活動連接當中，因此大家需要刪除當前連接然后重新建立。

MySQL集群在數(shù)據(jù)節(jié)點內(nèi)保留著全部細節(jié)信息。這部分數(shù)據(jù)可由名為NDBINFO的虛擬數(shù)據(jù)庫直接使用。舉例來說，NDBINFO能夠顯示磁盤頁面緩沖區(qū)的使用信息。所謂磁盤頁面緩沖區(qū)，其實是各個數(shù)據(jù)節(jié)點根據(jù)表格進行磁盤操作時的緩存。通常情況下，其緩沖命中率越高、則性能表現(xiàn)越好。調(diào)整這部分緩存的大小會對系統(tǒng)產(chǎn)生顯著影響。大家可以通過mysql命令行訪問磁盤頁面緩沖數(shù)據(jù)。#p#

性能優(yōu)化

訪問模式

要想讓MySQL集群部署發(fā)揮出與預(yù)期相符的性能，最重要的一點在于了解數(shù)據(jù)庫結(jié)構(gòu)。有一點需要注意--MySQL集群表格中的數(shù)據(jù)并不會被保存在MySQL服務(wù)器當中。這些數(shù)據(jù)實際上被劃分至由多個數(shù)據(jù)節(jié)點構(gòu)成的資源池當中，如下圖所示。

表格中的各行將被拆分成多個區(qū)塊，每個數(shù)據(jù)節(jié)點保留一個區(qū)塊的主片段及另一個區(qū)塊的次片段。

如果查詢需要多次網(wǎng)絡(luò)跳轉(zhuǎn)，例如由服務(wù)器向數(shù)據(jù)節(jié)點或者在不同數(shù)據(jù)節(jié)點之間，那么性能與可擴展性都可能受到影響。因此，要想讓MySQL集群獲得***性能表現(xiàn)，我們必須盡量減少網(wǎng)絡(luò)跳轉(zhuǎn)次數(shù)。表格劃分基于主鍵散列，但我們可以對其進行重寫以提高性能。簡單的訪問模式是創(chuàng)建可擴展且高性能解決方案的關(guān)鍵。

網(wǎng)絡(luò)跳轉(zhuǎn)的必要次數(shù)取決于來自各分支結(jié)構(gòu)的結(jié)果集與接合深度。如果表格的接合深度過大，那么指向數(shù)據(jù)節(jié)點的每一次跳轉(zhuǎn)也將耗費更多時間。要想獲得***性能，我們需要利用主鍵查找--其完成時間是恒定的，與數(shù)據(jù)庫規(guī)模及數(shù)據(jù)節(jié)點數(shù)目沒有關(guān)系。

使用AQL

通過使用AQL（即適應(yīng)性查詢本地化），性能改善將體現(xiàn)得更為明顯。

AQL能夠?qū)⒉樵冇蒑ySQL服務(wù)器指派向全部數(shù)據(jù)節(jié)點，且查詢由本地數(shù)據(jù)副本負責執(zhí)行。然后它會向MySQL服務(wù)器發(fā)回合并結(jié)果集，從而最終實現(xiàn)減少網(wǎng)絡(luò)跳轉(zhuǎn)、提高性能表現(xiàn)的目的。

AQ能幫助MySQL集群高效處理涉及大量復(fù)雜查詢事務(wù)的用例。

為了獲得更理想的使用效果，大家可以在變更表格模式（包括添加、刪除索引或者執(zhí)行其它重要變更）后在某一臺MySQL服務(wù)器中運行OPTIMIZE TABLE <tab-name>。

在實際使用環(huán)境中的測試結(jié)果顯示，AQL能夠?qū)⒋罅坎樵兪聞?wù)的整體效率提升70倍。在測試中，一套網(wǎng)絡(luò)內(nèi)容存儲管理系統(tǒng)中包含有十一套復(fù)雜表格，在對其進行正常查詢時，整個流程需要耗時87秒。但在AQL的幫助下，整個流程的時耗被直接縮短至1.26秒。

在默認情況下，AQL受到全局變量ndb_join_pushdown的控制。為了能夠讓AQL切實起效，我們需要對其進行如下規(guī)則修改：

• 要加入的列必須使用同一種數(shù)據(jù)類型，包括VARCHAR長度列在內(nèi)。
• 無法對指向BLOB或TEXT列的連接起效。
• 不支持顯式封鎖，但我們可以通過基于NDB存儲引擎鎖定的隱式行實現(xiàn)同等效果。
• 無法對明顯由HASH或者RANGE進行劃分的連接起效。

分布感知應(yīng)用

在利用MySQL集群向表格中添加行時，每一行都歸屬于一個分區(qū)。每個分區(qū)又都由集群中的一個特定數(shù)據(jù)節(jié)點所掌控。只有事務(wù)需要的全部數(shù)據(jù)都被劃分到同一個分區(qū)當中時，集群性能才能實現(xiàn)***。這意味著我們要利用一個單獨數(shù)據(jù)節(jié)點來取消在多個節(jié)點之間往復(fù)傳輸所帶來的延遲提升。

MySQL集群默認通過主鍵散列對數(shù)據(jù)進行劃分。我們可以指定主鍵中的特定字段并將其提交給散列算法，從而改變默認方案。

大家也可以利用分區(qū)裁剪方案。分區(qū)裁剪流程是指通過單一數(shù)據(jù)節(jié)點進行索引掃描，其延遲改善效果取決于數(shù)據(jù)節(jié)點的數(shù)量及結(jié)果集的大小。數(shù)據(jù)節(jié)點越多、需要取回的記錄越少，改進的效果也就越好。

下圖顯示了分區(qū)裁剪對性能的提升情況。

分區(qū)裁剪能夠有效降低小型結(jié)果集的延遲狀況，但對較大的結(jié)果集而言反倒會提高延遲表現(xiàn)。上圖中的紅色條形代表分區(qū)裁剪后的延遲數(shù)字。

在這種情況下，應(yīng)用程序分布機制對于新增額外節(jié)點的識別能力就成了保證性能改善的關(guān)鍵。

使用連接池

MySQL集群在多個數(shù)據(jù)節(jié)點進行大量并行操作時的吞吐能力***。有鑒于此，我們必須同時利用多臺MySQL服務(wù)器且應(yīng)用程序的各個線程全部接入這些服務(wù)器。要訪問數(shù)據(jù)節(jié)點，mysqld進程會默認使用單獨的NDB API連接。由于大量應(yīng)用程序線程同時搶占這一條連接，我們需要設(shè)置一套互斥機制以避免吞吐操作發(fā)生沖突。

一種方案是讓每個應(yīng)用線程都使用其專用的mysqld進程，但這不僅浪費資源、同時也會增加應(yīng)用程序的復(fù)雜性。

更為高效的方案是如上圖所示，建立由mysqld進程向數(shù)據(jù)節(jié)點的多條NDB API連接。

為了使用連接池，每條（來自mysqld）連接都需要在config.ini文件中擁有自己的[mysqld]或者[api]分節(jié)號，然后在my.cnf文件中將ndbcluster-connection-pool值設(shè)置為大于1。另外，我們也絕不能在啟動mysqld進程的同時將ndb-node-ida作為命令行選項。在我們的測試實例中，單一mysqld進程擁有四個NDB API連接。

上圖顯示了連接池所帶來的性能提升。一般來說，應(yīng)用程序的性能普遍能獲得70%的提升，但在某些特殊情況下、其提升幅度可能超過150%。

添加節(jié)點以實現(xiàn)擴展

MySQL集群在設(shè)計思路中納入了橫向擴展考量。能夠添加額外的MySQL服務(wù)器或者數(shù)據(jù)節(jié)點，大家可以顯著提升整體性能。

我們還能夠向處于運行狀態(tài)的MySQL集群中添加新的MySQL服務(wù)器或者節(jié)點組。也就是說，我們完全不必關(guān)機并重新加載集群?，F(xiàn)有表格中的數(shù)據(jù)將被重新劃分到所有接入數(shù)據(jù)節(jié)點當中。最安全的處理方式是使用MySQL Cluster Manager。這款集群管理器能自動處理關(guān)于額外節(jié)點添加的所有事務(wù)，而且我們不必擔心整個過程會造成任何服務(wù)丟失。

總結(jié)

在過去九年中（自2004年起），MySQL集群已經(jīng)逐步成為一款成熟的解決方案，能夠滿足極端性能水平要求以及高達99.99%的嚴格正常運行標準。正如在文章開頭所說，自適應(yīng)查詢本地化、參數(shù)調(diào)整以及分布感知等特性令MySQL集群在性能方面更上一層樓，從而有能力服務(wù)于更廣泛的應(yīng)用組合方案。作為數(shù)據(jù)庫技術(shù)的核心要素，實時監(jiān)控與報告功能的強化也幫助數(shù)據(jù)庫開發(fā)人員及管理員們得以更好地在MySQl集群中擴展自己的用例。

原文鏈接：

http://www.agileload.com/agileload/blog/2013/03/11/optimizing-the-performance-of-mysql-cluster