NewSQL供應商Clustrix公司技術項目管理副總裁Scott Sullivan對MySQL的局限性進行了一番闡釋，并具體探討了NewSQL數據庫如何為用戶帶來新的替代方案。

 

　　如何判斷業務規模超出MySQL應對能力

 

　　數據總量的迅猛增長促使我們爭先恐后地尋求更理想的數據管理解決方案。大多數擁有龐大用戶基礎的企業可能早就已經發現僅憑單一數據庫服務器根本無法管理所有應用程序—因此，如今最常見的解決方式在于同時使用多套令人困惑且高度復雜的數據管理系統。

 

　　大家可能已經在利用內存緩存MySQL服務器彈性集群處理讀取slave，并借助各類由云提供的Web/應用程序農場應對查詢應答任務。大家可能已經部署了跨地理分布的多主副本配置方案，旨在處理指向數據庫的寫入操作。又或者大家只是覺得調整只是時間問題，實施工作宜早不宜遲。

 

　　無論大家尚未著手、還是已經完成了上述全部工作，終有一天業務規模仍然會超出現有方案的解決能力—在大多數情況下，這一問題會出現在歷史悠久的MySQL身上—因此我們需要進行設施擴張以滿足當前或者今后的預期增長。但大家如何判斷拓展的時機是否已經到來?

 

　　1. 流量峰值階段延遲增加

 

　　如果大家的服務在常規時段運轉良好，但在每天的峰值時段總會響應遲緩，這就是各位需要對資源或者結構作出轉變的一大顯著指標。

 

　　面對這類情況，很多技術團隊會自然而然地將問題歸咎于負載生成機制：添加索引、重寫查詢能夠提高效率，并保證每頁視圖返回的結果更少等等—這些努力通常確實能帶來更出色的用戶體驗。不過這還僅僅是正確解決方案中的1%。如果大家發現自己需要每天一次、周而復始地進行優化，那就說明應該通過添加額外的硬件資源推進一輪顯著的容量升級了。

 

　　MySQL能夠對當前的技術方案以及任何系統進行向上擴展，但在向外擴展方面卻存在著局限。常見的MySQL平臺向外擴展方式可謂多種多樣，簡單些的可以部署只讀slave，復雜的方案則包括劃分NoSQL架構或者卸下其中的一部分查詢任務。任何一種解決辦法都要求對應用程序的邏輯以及數據訪問方式作出變更，有時候甚至需要改變我們的數據模型以及用戶體驗—而且這些變更無法快速完成，因此延遲高企的問題短時間內也就得不到解決。

 

　　包括ClustrixDB在內的各類NewSQL解決方案在設計上能夠毫不費力地接入附加硬件資源，而且整個容量增加過程只涉及機架與服務器堆棧添加—具體來講，無需應用程序變更、無需調整數據模型。作為一套關系型數據庫，NewSQL承諾輕松將多臺可用服務器進行集群化處理，從而突破當前單一實例硬件局限。

 

　　2. 報告與分析遲緩

 

　　最令數據庫管理員頭痛的任務，莫過于管理層希望在生產數據庫中運行報告系統。這是因為生產數據庫通常全天處于全速運行狀態，所以根本沒有余力額外完成統計服務運行狀況所必需的沉重計算任務。在生產數據庫中運行報告系統不僅需要耗費遠超出正常水平的時間，同時也會令用戶體驗大打折扣。

 

　　數據庫管理員們可能已經設置了一份專門用于分析及報告任務的生產副本(讀取slave)。這臺專用報告服務器中的數據可能由于復制延遲的存在而略微落后于生產流量，不過至少報告統計本身的處理速度能夠得到保證。這像是公司為某位員工專門配備公務用車—如果目前暫時不需要，車輛將處于閑置與等待狀態。但相比之下，將報告服務器用于處理用戶請求，同時在必要時讓其重新快速處理報告任務豈不更好?

 

　　NewSQL系統能夠以動態方式將額外服務器整合成一套單一的數據庫服務，這項功能在任何MySQL架構中都是不可能實現的。通過對NewSQL系統進行細化配置，大家的過剩容量不僅能夠偶爾處理報告任務，同時也能在用戶流量峰值階段貢獻自己的力量。

 

　　3. 定期與/或長期停機

 

　　MySQL系統已經發展成大型工作負載處理方案，這意味著其中往往存在大量潛在故障點。

 

　　我們可以以此為核心創建多個主或讀取slave，這將同時提高使用成本與復雜程度。不過每一套數據庫額外副本都相當于一個需要管理并保持同步的全新鏈接目標。每套副本都極易受到數據不一致性、后端故障或者軟件、硬件問題的影響。另外，我們擁有的系統數量越大，任意時間段內遭遇停機問題的可能性也就越高。

 

　　每次發生故障都需要我們進行手動調查與恢復—或者利用技術團隊開發出的自動化處理與恢復系統。

 

　　相比之下，NewSQL系統在設計思路上作為單一單元來運行。大家擁有一套需要管理的主數據庫，另外在處于遠程地理區域的數據中心內還另有一套輔助災難恢復系統。無論大家的數據庫服務器是由幾臺還是幾十臺服務器構成都沒關系;從數據庫管理員的角度出發，系統本身都是一個整體。硬件故障可以以自動化方式解決，這是因為系統會借助路由機制繞過無法正常使用的組件。

 

　　智能化NewSQL系統能夠自我修復并恢復對額外硬件故障的容錯能力，而且整個過程無需人為介入。有了這些主可用性功能與自我修復方案保駕護航，大家的向外擴展數據庫能夠順利將停機時間從原本的數小時降低至數秒鐘。

 

　　4. 高昂的部署成本

 

　　當大家的MySQL架構架構逐漸逼近單一實例服務器的局限，這時開發人員用于處理向外擴展問題所耗費的時間甚至會多于構建業務功能的時間。

 

　　最重要的是，我們針對請求所開發出的每一項新功能都需要考慮愈發復雜的MySQL構架，而無法僅僅面向最基本的SQL原則。原本簡單的請求變得極為復雜。當開發人員需要把大量時間耗費在向外擴展數據庫系統身上時，大家必須在兩種處理方式之間作出選擇：如果這種擴展方法能夠幫助業務實現差異性，那么現有機制尚有存在價值;如若不然，我們應該考慮把這部分時間用在更能發揮價值的地方。

 

　　5. 購買各種不同類型的硬件

 

　　對單一實例MySQL數據庫進行向上擴展只允許大家在現有商用硬件中進行挑選。我們當然可以在自己的系統中使用最為強大的CPU產品，或者采購一大堆擴展內存，但請記住—我們的主板接入能力是有限的，這才是最大的問題。

 

　　選擇商用硬件之外的方案可算是縮小性能差距努力中的最后一種可行嘗試。配備全閃存驅動器、512GB內存以及最高速處理器的頂級系統所帶來的開支，足以幫助大家買下一整套商用系統集群—甚至還不止。

 

　　真正的向外擴展NewSQL解決方案在設計思路上優先考慮運行在價格低廉的商用硬件之上，而這類設備正是當前高性價比方案的典型代表。這樣一來，大家的運營費用將始終保持可預測性，從而保證設施規模始終符合業務營收而非超出營收水平。