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

 

　　如何判斷業(yè)務(wù)規(guī)模超出MySQL應(yīng)對能力

 

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

 

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

 

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

 

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

 

　　如果大家的服務(wù)在常規(guī)時段運轉(zhuǎn)良好，但在每天的峰值時段總會響應(yīng)遲緩，這就是各位需要對資源或者結(jié)構(gòu)作出轉(zhuǎn)變的一大顯著指標。

 

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

 

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

 

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

 

　　2. 報告與分析遲緩

 

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

 

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

 

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

 

　　3. 定期與/或長期停機

 

　　MySQL系統(tǒng)已經(jīng)發(fā)展成大型工作負載處理方案，這意味著其中往往存在大量潛在故障點。

 

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

 

　　每次發(fā)生故障都需要我們進行手動調(diào)查與恢復—或者利用技術(shù)團隊開發(fā)出的自動化處理與恢復系統(tǒng)。

 

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

 

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

 

　　4. 高昂的部署成本

 

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

 

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

 

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

 

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

 

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

 

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