長(zhǎng)久以來(lái),MySQL一直扮演著Web數(shù)據(jù)庫(kù)生力軍的角色。目前它已經(jīng)成為世界上眾多頂級(jí)規(guī)模網(wǎng)站的技術(shù)基礎(chǔ),同時(shí)也作為開(kāi)源軟件方案服務(wù)于無(wú)數(shù)其它小規(guī)模業(yè)務(wù)環(huán)境。不過(guò)已經(jīng)有越來(lái)越多用戶(hù)意識(shí)到,MySQL在特定情況下已經(jīng)無(wú)法有效實(shí)現(xiàn)規(guī)模化擴(kuò)展需求。
NewSQL供應(yīng)商Clustrix公司技術(shù)項(xiàng)目管理副總裁Scott Sullivan對(duì)MySQL的局限性進(jìn)行了一番闡釋?zhuān)⒕唧w探討了NewSQL數(shù)據(jù)庫(kù)如何為用戶(hù)帶來(lái)新的替代方案。
如何判斷業(yè)務(wù)規(guī)模超出MySQL應(yīng)對(duì)能力
數(shù)據(jù)總量的迅猛增長(zhǎng)促使我們爭(zhēng)先恐后地尋求更理想的數(shù)據(jù)管理解決方案。大多數(shù)擁有龐大用戶(hù)基礎(chǔ)的企業(yè)可能早就已經(jīng)發(fā)現(xiàn)僅憑單一數(shù)據(jù)庫(kù)服務(wù)器根本無(wú)法管理所有應(yīng)用程序—因此,如今最常見(jiàn)的解決方式在于同時(shí)使用多套令人困惑且高度復(fù)雜的數(shù)據(jù)管理系統(tǒng)。
大家可能已經(jīng)在利用內(nèi)存緩存MySQL服務(wù)器彈性集群處理讀取slave,并借助各類(lèi)由云提供的Web/應(yīng)用程序農(nóng)場(chǎng)應(yīng)對(duì)查詢(xún)應(yīng)答任務(wù)。大家可能已經(jīng)部署了跨地理分布的多主副本配置方案,旨在處理指向數(shù)據(jù)庫(kù)的寫(xiě)入操作。又或者大家只是覺(jué)得調(diào)整只是時(shí)間問(wèn)題,實(shí)施工作宜早不宜遲。
無(wú)論大家尚未著手、還是已經(jīng)完成了上述全部工作,終有一天業(yè)務(wù)規(guī)模仍然會(huì)超出現(xiàn)有方案的解決能力—在大多數(shù)情況下,這一問(wèn)題會(huì)出現(xiàn)在歷史悠久的MySQL身上—因此我們需要進(jìn)行設(shè)施擴(kuò)張以滿(mǎn)足當(dāng)前或者今后的預(yù)期增長(zhǎng)。但大家如何判斷拓展的時(shí)機(jī)是否已經(jīng)到來(lái)?
1. 流量峰值階段延遲增加
如果大家的服務(wù)在常規(guī)時(shí)段運(yùn)轉(zhuǎn)良好,但在每天的峰值時(shí)段總會(huì)響應(yīng)遲緩,這就是各位需要對(duì)資源或者結(jié)構(gòu)作出轉(zhuǎn)變的一大顯著指標(biāo)。
面對(duì)這類(lèi)情況,很多技術(shù)團(tuán)隊(duì)會(huì)自然而然地將問(wèn)題歸咎于負(fù)載生成機(jī)制:添加索引、重寫(xiě)查詢(xún)能夠提高效率,并保證每頁(yè)視圖返回的結(jié)果更少等等—這些努力通常確實(shí)能帶來(lái)更出色的用戶(hù)體驗(yàn)。不過(guò)這還僅僅是正確解決方案中的1%。如果大家發(fā)現(xiàn)自己需要每天一次、周而復(fù)始地進(jìn)行優(yōu)化,那就說(shuō)明應(yīng)該通過(guò)添加額外的硬件資源推進(jìn)一輪顯著的容量升級(jí)了。
MySQL能夠?qū)Ξ?dāng)前的技術(shù)方案以及任何系統(tǒng)進(jìn)行向上擴(kuò)展,但在向外擴(kuò)展方面卻存在著局限。常見(jiàn)的MySQL平臺(tái)向外擴(kuò)展方式可謂多種多樣,簡(jiǎn)單些的可以部署只讀slave,復(fù)雜的方案則包括劃分NoSQL架構(gòu)或者卸下其中的一部分查詢(xún)?nèi)蝿?wù)。任何一種解決辦法都要求對(duì)應(yīng)用程序的邏輯以及數(shù)據(jù)訪(fǎng)問(wèn)方式作出變更,有時(shí)候甚至需要改變我們的數(shù)據(jù)模型以及用戶(hù)體驗(yàn)—而且這些變更無(wú)法快速完成,因此延遲高企的問(wèn)題短時(shí)間內(nèi)也就得不到解決。
包括ClustrixDB在內(nèi)的各類(lèi)NewSQL解決方案在設(shè)計(jì)上能夠毫不費(fèi)力地接入附加硬件資源,而且整個(gè)容量增加過(guò)程只涉及機(jī)架與服務(wù)器堆棧添加—具體來(lái)講,無(wú)需應(yīng)用程序變更、無(wú)需調(diào)整數(shù)據(jù)模型。作為一套關(guān)系型數(shù)據(jù)庫(kù),NewSQL承諾輕松將多臺(tái)可用服務(wù)器進(jìn)行集群化處理,從而突破當(dāng)前單一實(shí)例硬件局限。
2. 報(bào)告與分析遲緩
最令數(shù)據(jù)庫(kù)管理員頭痛的任務(wù),莫過(guò)于管理層希望在生產(chǎn)數(shù)據(jù)庫(kù)中運(yùn)行報(bào)告系統(tǒng)。這是因?yàn)樯a(chǎn)數(shù)據(jù)庫(kù)通常全天處于全速運(yùn)行狀態(tài),所以根本沒(méi)有余力額外完成統(tǒng)計(jì)服務(wù)運(yùn)行狀況所必需的沉重計(jì)算任務(wù)。在生產(chǎn)數(shù)據(jù)庫(kù)中運(yùn)行報(bào)告系統(tǒng)不僅需要耗費(fèi)遠(yuǎn)超出正常水平的時(shí)間,同時(shí)也會(huì)令用戶(hù)體驗(yàn)大打折扣。
數(shù)據(jù)庫(kù)管理員們可能已經(jīng)設(shè)置了一份專(zhuān)門(mén)用于分析及報(bào)告任務(wù)的生產(chǎn)副本(讀取slave)。這臺(tái)專(zhuān)用報(bào)告服務(wù)器中的數(shù)據(jù)可能由于復(fù)制延遲的存在而略微落后于生產(chǎn)流量,不過(guò)至少報(bào)告統(tǒng)計(jì)本身的處理速度能夠得到保證。這像是公司為某位員工專(zhuān)門(mén)配備公務(wù)用車(chē)—如果目前暫時(shí)不需要,車(chē)輛將處于閑置與等待狀態(tài)。但相比之下,將報(bào)告服務(wù)器用于處理用戶(hù)請(qǐng)求,同時(shí)在必要時(shí)讓其重新快速處理報(bào)告任務(wù)豈不更好?
NewSQL系統(tǒng)能夠以動(dòng)態(tài)方式將額外服務(wù)器整合成一套單一的數(shù)據(jù)庫(kù)服務(wù),這項(xiàng)功能在任何MySQL架構(gòu)中都是不可能實(shí)現(xiàn)的。通過(guò)對(duì)NewSQL系統(tǒng)進(jìn)行細(xì)化配置,大家的過(guò)剩容量不僅能夠偶爾處理報(bào)告任務(wù),同時(shí)也能在用戶(hù)流量峰值階段貢獻(xiàn)自己的力量。
3. 定期與/或長(zhǎng)期停機(jī)
MySQL系統(tǒng)已經(jīng)發(fā)展成大型工作負(fù)載處理方案,這意味著其中往往存在大量潛在故障點(diǎn)。
我們可以以此為核心創(chuàng)建多個(gè)主或讀取slave,這將同時(shí)提高使用成本與復(fù)雜程度。不過(guò)每一套數(shù)據(jù)庫(kù)額外副本都相當(dāng)于一個(gè)需要管理并保持同步的全新鏈接目標(biāo)。每套副本都極易受到數(shù)據(jù)不一致性、后端故障或者軟件、硬件問(wèn)題的影響。另外,我們擁有的系統(tǒng)數(shù)量越大,任意時(shí)間段內(nèi)遭遇停機(jī)問(wèn)題的可能性也就越高。
每次發(fā)生故障都需要我們進(jìn)行手動(dòng)調(diào)查與恢復(fù)—或者利用技術(shù)團(tuán)隊(duì)開(kāi)發(fā)出的自動(dòng)化處理與恢復(fù)系統(tǒng)。
相比之下,NewSQL系統(tǒng)在設(shè)計(jì)思路上作為單一單元來(lái)運(yùn)行。大家擁有一套需要管理的主數(shù)據(jù)庫(kù),另外在處于遠(yuǎn)程地理區(qū)域的數(shù)據(jù)中心內(nèi)還另有一套輔助災(zāi)難恢復(fù)系統(tǒng)。無(wú)論大家的數(shù)據(jù)庫(kù)服務(wù)器是由幾臺(tái)還是幾十臺(tái)服務(wù)器構(gòu)成都沒(méi)關(guān)系;從數(shù)據(jù)庫(kù)管理員的角度出發(fā),系統(tǒng)本身都是一個(gè)整體。硬件故障可以以自動(dòng)化方式解決,這是因?yàn)橄到y(tǒng)會(huì)借助路由機(jī)制繞過(guò)無(wú)法正常使用的組件。
智能化NewSQL系統(tǒng)能夠自我修復(fù)并恢復(fù)對(duì)額外硬件故障的容錯(cuò)能力,而且整個(gè)過(guò)程無(wú)需人為介入。有了這些主可用性功能與自我修復(fù)方案保駕護(hù)航,大家的向外擴(kuò)展數(shù)據(jù)庫(kù)能夠順利將停機(jī)時(shí)間從原本的數(shù)小時(shí)降低至數(shù)秒鐘。
4. 高昂的部署成本
當(dāng)大家的MySQL架構(gòu)架構(gòu)逐漸逼近單一實(shí)例服務(wù)器的局限,這時(shí)開(kāi)發(fā)人員用于處理向外擴(kuò)展問(wèn)題所耗費(fèi)的時(shí)間甚至?xí)嘤跇?gòu)建業(yè)務(wù)功能的時(shí)間。
最重要的是,我們針對(duì)請(qǐng)求所開(kāi)發(fā)出的每一項(xiàng)新功能都需要考慮愈發(fā)復(fù)雜的MySQL構(gòu)架,而無(wú)法僅僅面向最基本的SQL原則。原本簡(jiǎn)單的請(qǐng)求變得極為復(fù)雜。當(dāng)開(kāi)發(fā)人員需要把大量時(shí)間耗費(fèi)在向外擴(kuò)展數(shù)據(jù)庫(kù)系統(tǒng)身上時(shí),大家必須在兩種處理方式之間作出選擇:如果這種擴(kuò)展方法能夠幫助業(yè)務(wù)實(shí)現(xiàn)差異性,那么現(xiàn)有機(jī)制尚有存在價(jià)值;如若不然,我們應(yīng)該考慮把這部分時(shí)間用在更能發(fā)揮價(jià)值的地方。
5. 購(gòu)買(mǎi)各種不同類(lèi)型的硬件
對(duì)單一實(shí)例MySQL數(shù)據(jù)庫(kù)進(jìn)行向上擴(kuò)展只允許大家在現(xiàn)有商用硬件中進(jìn)行挑選。我們當(dāng)然可以在自己的系統(tǒng)中使用最為強(qiáng)大的CPU產(chǎn)品,或者采購(gòu)一大堆擴(kuò)展內(nèi)存,但請(qǐng)記住—我們的主板接入能力是有限的,這才是最大的問(wèn)題。
選擇商用硬件之外的方案可算是縮小性能差距努力中的最后一種可行嘗試。配備全閃存驅(qū)動(dòng)器、512GB內(nèi)存以及最高速處理器的頂級(jí)系統(tǒng)所帶來(lái)的開(kāi)支,足以幫助大家買(mǎi)下一整套商用系統(tǒng)集群—甚至還不止。
真正的向外擴(kuò)展NewSQL解決方案在設(shè)計(jì)思路上優(yōu)先考慮運(yùn)行在價(jià)格低廉的商用硬件之上,而這類(lèi)設(shè)備正是當(dāng)前高性?xún)r(jià)比方案的典型代表。這樣一來(lái),大家的運(yùn)營(yíng)費(fèi)用將始終保持可預(yù)測(cè)性,從而保證設(shè)施規(guī)模始終符合業(yè)務(wù)營(yíng)收而非超出營(yíng)收水平。