近兩年來，國內(nèi)外諸如AWS、Azure等公有云巨頭都先后推出了自研的數(shù)據(jù)庫服務,青云QingCloud不僅推出了分布式數(shù)據(jù)庫RadonDB,同時還將這一經(jīng)過公有云驗證的數(shù)據(jù)庫產(chǎn)品應用到企業(yè)數(shù)據(jù)中心，通過將分布式技術(shù)與數(shù)據(jù)庫相結(jié)合,再加上SSD的性能加成,性能好得讓人不敢相信。比如網(wǎng)聯(lián)公司公布去年“雙十一”時,其峰值交易量每秒達到92000筆,如果用RadonDB的話，也許只需數(shù)臺就可以支撐。

溫馨提示:這篇測試長文閱讀大約需要10分鐘。

如何根據(jù)企業(yè)所需構(gòu)建面向未來的數(shù)據(jù)中心,這是絕大多數(shù)CIO都在思考的問題。

尤其是智能終端時代,數(shù)據(jù)蔓延正使得這一問題更加復雜,比如,手機銀行之于營業(yè)廳固定的業(yè)務窗口,手機App之于固定數(shù)量的銷售渠道,以及源起網(wǎng)絡購物的一次次人造“狂歡節(jié)”……

對于企業(yè)來說,IT負載正變得不可預測,同時生態(tài)內(nèi)外的數(shù)據(jù)流通正日趨復雜與頻繁,數(shù)據(jù)蔓延正對企業(yè)IT的性能、容量以及管理帶來巨大的挑戰(zhàn)。

在IT演進的過程中,云計算已經(jīng)被認為是企業(yè)IT的必經(jīng)之路,這在過去幾年中已經(jīng)得以充分證實,尤其是公有云方面的實踐,一定程度上調(diào)和了企業(yè)IT需求與成本之間的矛盾,這也使得混合云趨勢正日趨明顯。

公有云的成功經(jīng)驗正越來越多地應用在企業(yè)內(nèi)部數(shù)據(jù)中心,以幫助企業(yè)更順利地向云端遷移,最典型莫過于源自互聯(lián)網(wǎng)分布式存儲的SDS(Software Define Storage,軟件定義存儲)已經(jīng)成為企業(yè)存儲市場最主流的趨勢之一。

RadonDB分布式數(shù)據(jù)庫:從公有云驗證到企業(yè)數(shù)據(jù)中心應用

隨著公有云服務在企業(yè)數(shù)據(jù)中心內(nèi)部的應用,不僅幫助用戶解決了現(xiàn)實問題,同時也讓公有云廠商更加了解企業(yè)業(yè)務特點,為后續(xù)推出滿足用戶需求的產(chǎn)品與解決方案提供了條件。典型如數(shù)據(jù)庫產(chǎn)品,近兩年來,國內(nèi)外諸如AWS、Azure等公有云巨頭都先后推出了自研的數(shù)據(jù)庫服務,而青云QingCloud不僅推出了分布式數(shù)據(jù)庫RadonDB,同時還將這一經(jīng)過公有云驗證的數(shù)據(jù)庫產(chǎn)品應用到企業(yè)數(shù)據(jù)中心。

相對于公有云環(huán)境,企業(yè)數(shù)據(jù)中心的業(yè)務更加復雜,對于IT基礎(chǔ)架構(gòu)的要求也更高。數(shù)據(jù)庫不僅需要部署在數(shù)據(jù)中心內(nèi)部的物理服務器、虛擬機、容器等私有云環(huán)境,并在必要時能夠擴展到公有云之上。

軟件定義存儲與SSD的應用推動分布式數(shù)據(jù)庫進入企業(yè)數(shù)據(jù)中心,實際上存儲與數(shù)據(jù)庫的結(jié)合亦更加緊密(如Server SAN的一大場景就是數(shù)據(jù)庫)。SSD的高性能優(yōu)勢在一定程度上有助于提升數(shù)據(jù)庫的性能,簡化數(shù)據(jù)庫架構(gòu),讓分布式成為可能,理論上實現(xiàn)容量的***擴展,并性能亦隨之線性增長。

青云QingCloud新一代分布式數(shù)據(jù)庫RadonDB,基于開源的MySQL技術(shù)研發(fā),而MySQL是全球范圍內(nèi)應用最廣泛的數(shù)據(jù)庫,其開源的性質(zhì)能夠杜絕廠商鎖定,開源社區(qū)的蓬勃發(fā)展培養(yǎng)了一大批精通MySQL的人才,為企業(yè)部署、應用、管理MySQL提供了便利。如同x86服務器一樣,其不僅方便使用,也易于管理,有助于降低企業(yè)數(shù)據(jù)中心成本。

但在海量數(shù)據(jù)時代,單機版MySQL數(shù)據(jù)庫已經(jīng)很難滿足企業(yè)應用需求,而部署集群版MySQL則更多出于可靠性目的,雖然也有企業(yè)基于MySQL開發(fā)出分布式部署版本,但更多是面向特定需求,離成熟產(chǎn)品還有一段距離。而RadonDB則率先在公有云中應用改進,然后根據(jù)企業(yè)應用特點進行優(yōu)化,進而形成一個標準商用的產(chǎn)品,以方便企業(yè)用戶使用。

具體來說, RadonDB主要包含兩大模塊的改進和創(chuàng)新:radon和xenon。radon是一個分布式SQL層,主要負責數(shù)據(jù)路由和計算;xenon則是一個MySQL集群高可用組件,用以構(gòu)建分布式存儲層,具有秒級選主(Master)、選主后的數(shù)據(jù)快速回放、以及實現(xiàn)主從切換后的數(shù)據(jù)零丟失等功能。RadonDB從技術(shù)上對分庫分表式概念進行了更進一步的擴展,使其成為具備高可用、滿足Snapshot隔離級別分布式事務的開源分布式數(shù)據(jù)庫,而非僅僅只是一個分庫分表組件。

RadonDB分布式數(shù)據(jù)庫架構(gòu)圖(來源:青云QingCloud)

RadonDB性能測試前 環(huán)境搭建和組件說明

一般來說,數(shù)據(jù)庫與存儲(確切地說是塊存儲)的關(guān)系非常緊密,通常數(shù)據(jù)庫的性能與存儲的性能息息相關(guān)。而分布式存儲的性能一方面要依賴硬件,同時也與分布式存儲軟件本身的優(yōu)化相關(guān)。下圖為RadonDB測試架構(gòu):

整個測試環(huán)境由6臺服務器和一臺25GbE交換機組成,主要分為分布式存儲環(huán)境和RadonDB分布式數(shù)據(jù)庫環(huán)境。每臺服務器均配備2顆Intel Xeon E5-2650 v4處理器(12核,2.2GHz)和64GB內(nèi)存。

在存儲方面,為了更好地體現(xiàn)RadonDB分布式數(shù)據(jù)庫的性能,E企研究院使用“全閃”配置的分布式存儲作為RadonDB數(shù)據(jù)庫存儲。分布式存儲以最小三節(jié)點部署,每個節(jié)點配備了4片4TB大容量的Intel DC P4510 SSD。這是Intel第四代U.2接口的NVMeSSD,更好的性能與較大的容量能夠更容易觀察到RadonDB數(shù)據(jù)庫性能的上限。

分布式存儲方案使用新一代25GbE網(wǎng)絡,以提升數(shù)據(jù)內(nèi)部流通的帶寬。根據(jù)以往的測試經(jīng)驗,在全閃配置環(huán)境中,10GbE網(wǎng)絡通常會成為存儲瓶頸,進而影響應用性能發(fā)揮。所以在本次RadonDB測試使用了25GbE網(wǎng)絡,分布式存儲通過iSCSI連接到RadonDB數(shù)據(jù),iSCSI是企業(yè)環(huán)境中標準通用的數(shù)據(jù)傳輸技術(shù),能夠最小化對企業(yè)現(xiàn)有環(huán)境的影響。同時,25GbE能夠更好地支持RDMA技術(shù)(Remote Direct Memory Access,遠程直接內(nèi)存訪問),即RoCE或iWARP,在iSCSI連接無法提供應用需要的存儲性能情況下,可以很容易升級到新的數(shù)據(jù)傳輸協(xié)議,比如iSER(iSCSI Extensions for RDMA)或者NVMe over Fabric等。

[[260997]]

在數(shù)據(jù)庫方面,RadonDB可最小二節(jié)點部署(滿足最小可用性),通常三節(jié)點起步。在本次測試中使用三節(jié)點部署,并以二節(jié)點數(shù)據(jù)庫性能作為參照,考量RadonDB數(shù)據(jù)庫的可擴展性。利用RadonDB的自動化部署與運維工具Ansible,進行簡單的端口和變量設置,即可實現(xiàn)一鍵安裝,整個部署過程簡潔方便。

E企研究院希望盡可能貼近真實應用環(huán)境,通過測試模型去盡可能真實地模擬實際應用環(huán)境,但實際環(huán)境中通常存在多種不可預估情況,且與特定應用負載息息相關(guān)。E企研究院在本次測試中使用Sysbench軟件用以評估RadonDB數(shù)據(jù)庫性能,并根據(jù)大多數(shù)應用運行負載構(gòu)造測試數(shù)據(jù),盡可能為更多用戶提供參考。

同時為了更進一步探尋RadonDB分布式數(shù)據(jù)庫的極限,因為這與RadonDB數(shù)據(jù)庫的應用場景相關(guān),E企研究院對測試組件進行了一些調(diào)整,將Intel DC P4800X SSD作為RadonDB數(shù)據(jù)庫的數(shù)據(jù)緩存。Intel DC P4800X SSD即Intel公司Optane(傲騰),相比SSD,具有更均衡的讀寫能力,且延遲更低,據(jù)Intel實驗室數(shù)據(jù):相比NAND SSD,Optane用作數(shù)據(jù)庫緩存,數(shù)據(jù)庫有數(shù)倍性能提升。

Intel將Optane用作數(shù)據(jù)庫緩存,有著3倍以上的性能提升,同時數(shù)據(jù)庫平均響應時間降低了三倍左右,以此說明Optane的性能優(yōu)異(來源于Intel)

隨著人工智能、大數(shù)據(jù)分析等應用方式的出現(xiàn),企業(yè)場景化、個性化服務等創(chuàng)新業(yè)務對移動互聯(lián)網(wǎng)的依賴越來越高,手機、互聯(lián)網(wǎng)交易成為主流的交易渠道,促銷、搶購等活動常常導致業(yè)務突發(fā)高點,業(yè)務數(shù)據(jù)量和交易量的暴增對企業(yè)數(shù)據(jù)庫提出了高的要求。

為此,E企研究院的測試圍繞“性能”而展開,一是RadonDB數(shù)據(jù)庫最小配置下的性能,二是從2節(jié)點擴展到3節(jié)點后,RadonDB數(shù)據(jù)庫的性能變化。

RadonDB小試牛刀:分布式技術(shù)在數(shù)據(jù)庫領(lǐng)域的驗證

E企研究院使用Sysbench軟件分別在RadonDB和MySQL數(shù)據(jù)庫中構(gòu)建了16張表,共2億行數(shù)據(jù),約占用80GB存儲空間。在讀、寫性能測試中,一個事務即一條SQL;在混合讀寫中,一個事務中包含4條讀SQL和1條寫SQL。

E企研究院首先測試了RadonDB數(shù)據(jù)庫分別在2節(jié)點與3節(jié)點下的性能,并以單機MySQL(社區(qū)版5.7.22)的性能作為參照組。兩者的軟硬件配置完全一樣,均使用相同容量的SSD作為數(shù)據(jù)存儲。

兩節(jié)點部署的RadonDB數(shù)據(jù)庫性能與單機部署的MySQL數(shù)據(jù)庫性能,在寫場景下大致相當,前者略高。這可以理解,在分布式環(huán)境下,兩節(jié)點部署通常是出于可用性設計,與單機部署的寫性能相差不大。但在讀性能方面,兩節(jié)點部署的RadonDB數(shù)據(jù)庫性能,相比單機部署的MySQL數(shù)據(jù)庫性能有較大提高(這有些類似RAID 1的讀寫性能特征)。

而在3節(jié)點部署的RadonDB數(shù)據(jù)庫環(huán)境下,相比2節(jié)點,其性能提升了1倍左右。如上圖,三節(jié)點RadonDB的80000 TPS相比2節(jié)點RadonDB的35000 TPS,寫性能提升超過一倍,而在讀性能方面,也約有50%的性能提升;在混合場景(讀寫比例8:2)下,性能提升了80%左右。相比2節(jié)點最小部署配置,3節(jié)點正常部署下,性能將約為單機部署的MySQL性能的2倍左右。

而在延遲方面,RadonDB數(shù)據(jù)庫發(fā)揮出了“分布式”技術(shù)的優(yōu)勢特點,即通過多節(jié)點的并行讀寫,不僅能夠提升數(shù)據(jù)庫的性能,同時極大地降低了事務處理過程中的瓶頸延遲。如上圖所示,在讀性能方面,3節(jié)點RadonDB數(shù)據(jù)庫的平均延遲僅為MySQL的60%,在寫方面,RadonDB數(shù)據(jù)庫平均延遲約為MySQL的三分之一,而在混合讀寫測試中,也降低到MySQL數(shù)據(jù)庫平均延遲的二分之一左右。

更高的性能與更低的平均延遲,意味著RadonDB數(shù)據(jù)庫可以支撐更核心更關(guān)鍵的應用場景,不僅是分布式原理提供了更好的可用性,同時性能和延遲都能滿足更為苛刻的應用需求。而且更為重要的是,這驗證了分布式技術(shù)同樣也適用于數(shù)據(jù)庫領(lǐng)域,能夠為應用需求提供“彈性”,即可伸縮的性能,以及容量。

不可預測性是現(xiàn)代IT面臨的一大難題,將分布式與數(shù)據(jù)庫相結(jié)合,這就意味著RadonDB也如分布式計算或分布式存儲技術(shù)那樣,能夠根據(jù)企業(yè)現(xiàn)有應用需求進行部署,隨著應用的性能需求變化而通過增刪數(shù)據(jù)庫節(jié)點來進行靈活調(diào)整(性能或容量)。

面向OLTP應用:如何進行性能擴展

上一測試是為了驗證RadonDB數(shù)據(jù)庫在實驗室極端環(huán)境下的性能,同時也檢驗環(huán)境是否安裝配置正確,其性能數(shù)據(jù)并不能代表生產(chǎn)環(huán)境中的性能。排除極少的極端情況,實際環(huán)境中數(shù)據(jù)庫的讀寫負載模型更加復雜多變,并與特定應用直接相關(guān)。而在這一測試中,E企研究院希望通過模擬貼近真實的應用負載,以此來考量QingCloud RadonDB數(shù)據(jù)庫在性能擴展方面的表現(xiàn)。

OLTP是數(shù)據(jù)庫最常見也是最核心的應用場景之一,通常是企業(yè)關(guān)鍵應用的代名詞,其通常意味著可靠性、可用性以及高性能等等特點,而在海量數(shù)據(jù)時代,其還增加了一個需求,即(性能和容量)的可擴展性,從數(shù)據(jù)庫層面來看,即對數(shù)據(jù)庫的管理與優(yōu)化,這通常是一個長期過程,且與應用負載的變化息息相關(guān)。

數(shù)據(jù)庫優(yōu)化方式與存儲系統(tǒng)的特點變化有著緊密的聯(lián)系。而隨著云計算時代的深入,尤其是分布式技術(shù)的不斷普及深化,正改變越多越多的企業(yè)IT架構(gòu),典型如分布式對計算和存儲行業(yè)的技術(shù)革新。而公有云供應商將分布式技術(shù)應用于數(shù)據(jù)庫領(lǐng)域,也將影響和改變數(shù)據(jù)庫的管理和優(yōu)化方式。

數(shù)據(jù)庫優(yōu)化,在一定程度上,即是根據(jù)應用特點對數(shù)據(jù)處理方式與存儲位置做出相應改變,因為很難對(SAN)存儲做出改變。但是云計算時代的數(shù)據(jù)庫,在引入分布式技術(shù)以后,則為數(shù)據(jù)庫性能優(yōu)化提供了另外一種選擇,借用存儲行業(yè)的兩個術(shù)語:Scale-out橫向擴展與Scale-up縱向擴展。典型如RadonDB數(shù)據(jù)庫通過分布式原理能夠?qū)崿F(xiàn)節(jié)點數(shù)的增加,性能與容量增長;而計算、存儲與網(wǎng)絡等硬件技術(shù)的發(fā)展,又為單個數(shù)據(jù)庫節(jié)點的性能提升帶來了條件。但對用戶而言有一個重要前提:RadonDB等新興的數(shù)據(jù)庫都是基于標準的x86硬件,這意味著能夠更快享受到x86及其周邊硬件更新帶來的性能紅利。如支持U.2接口的NVMe SSD和25GbE網(wǎng)絡幾乎是現(xiàn)在主流x86服務器的標配,但在傳統(tǒng)SAN存儲領(lǐng)域,要完全發(fā)揮更“企業(yè)范兒”的U.2 NVMe SSD的性能特點,還需時間,更不要說支持RDMA的25GbE網(wǎng)絡了。

因此,以下測試正是圍繞這兩個特點進行設計:一方面分別對二、三節(jié)點配置的RadonDB數(shù)據(jù)庫性能進行測試,考量其Scale-out橫向擴展后的性能變化;另一方面則通過在數(shù)據(jù)庫節(jié)點增加性能更好的存儲介質(zhì)(即Optane做緩存),而不改變其他條件,以此體現(xiàn)RadonDB數(shù)據(jù)庫在使用新硬件后的性能變化。以下為測試結(jié)果:

RadonDB分布式數(shù)據(jù)庫從2節(jié)點擴展到3節(jié)點之后,數(shù)據(jù)庫性能從6824 TPS(Transactions Per Second,每秒在線事務處理數(shù),衡量數(shù)據(jù)庫性能的單位)上升到了11285 TPS,TPS提升了大約1倍左右;平均延遲則從2節(jié)點的75ms下降為3節(jié)點的45ms,時間也差不多接近越來的二分之一。

對于基于開源的商用數(shù)據(jù)庫產(chǎn)品而言,在單一數(shù)據(jù)庫系統(tǒng)內(nèi),其TPS從千上升到萬是一個不小的進步。比如說起網(wǎng)絡購物,***個反應也許就是“雙十一”,政策規(guī)定,目前所有的網(wǎng)絡購物支付都必須經(jīng)過網(wǎng)聯(lián)清算公司(簡稱“網(wǎng)聯(lián)”)的結(jié)算平臺。據(jù)網(wǎng)聯(lián)公布的2019年“雙十一”數(shù)據(jù):其當日處理的交易總筆數(shù)為11.7億筆,在峰值時,每秒的交易處理在9.2萬筆左右。雖然并不能與實際情況劃等號,但也許10節(jié)點RadonDB數(shù)據(jù)庫就能支撐這一負載?出于可靠性,當然還需要額外幾臺備用。

這只是使用NAND SSD做數(shù)據(jù)庫存儲的情況,如果使用性能更好的新硬件,支撐每秒10萬筆交易,RadonDB數(shù)據(jù)庫節(jié)點數(shù)量也許能夠降到個位數(shù)。因為在另一測試中,E企研究院在每個RadonDB數(shù)據(jù)庫節(jié)點上增加了兩片容量為375GB的Intel Optane SSD DC P4800X(簡稱Optane,即傲騰SSD),互為冗余,用作數(shù)據(jù)庫緩存,主要利用Optane的高寫性能加速數(shù)據(jù)庫寫IO。同樣是在二、三節(jié)點RadonDB數(shù)據(jù)庫環(huán)境下進行測試,其性能變化如下:

Optane用作緩存之后,RadonDB數(shù)據(jù)庫兩節(jié)點的性能上升到了26900 TPS,大約是未使用Optane情況下的4倍左右;三節(jié)點性能則從11285上升到了60996,RadonDB數(shù)據(jù)庫性能至少提高了5倍以上。

而且,在數(shù)據(jù)庫響應時間方面也有很大的提升。如上表所列,未使用Optane時,2和3節(jié)點RadonDB數(shù)據(jù)庫的響應時間分別為75ms和19ms,在使用Optane之后,相同測試條件下,其響應時間分別下降到45ms和8ms,約為使用Optane前的四分之一。

僅就數(shù)據(jù)庫而言,也許只需數(shù)臺RadonDB數(shù)據(jù)庫就能支撐起“雙十一”龐大規(guī)模的交易量,這一方面得益于分布式技術(shù)在其中的應用;另一方面也得益于龐大的x86生態(tài)系統(tǒng),RadonDB數(shù)據(jù)庫能夠在盡可能短的時間內(nèi)就能夠驗證、應用更新且性能更好的硬件技術(shù)或產(chǎn)品,以此進一步提高數(shù)據(jù)庫自身的性能。

當然這雖然只是實驗室數(shù)據(jù),還有待實際環(huán)境驗證。但結(jié)合E企研究院以往的測試數(shù)據(jù)來看,RadonDB分布式數(shù)據(jù)庫已經(jīng)初步具備了成為企業(yè)關(guān)鍵應用數(shù)據(jù)庫的條件,具有較好的性能、可用性以及易維護性,并且將分布式技術(shù)帶來的“彈性”與數(shù)據(jù)庫很好地結(jié)合在一起。

雖然本次測試結(jié)果主要以性能數(shù)字展現(xiàn),但其背后卻RadonDB數(shù)據(jù)庫與傳統(tǒng)數(shù)據(jù)庫不同的特點,比如RadonDB數(shù)據(jù)庫性能和容量的可擴展性,這一方面來自于經(jīng)過驗證的分布式技術(shù),另一方面也可從采納新硬件中獲得,其背后離不開x86這一強大生態(tài);而另一強大生態(tài)則在于MySQL開源社區(qū),理論上RadonDB數(shù)據(jù)庫不僅能夠從開源社區(qū)獲得***的數(shù)據(jù)庫改進技術(shù),也能獲得寶貴的學習經(jīng)驗以及數(shù)據(jù)庫管理人才,盡可能降低企業(yè)用戶更新?lián)Q代所需的學習成本;而青云QingCloud公有云供應商的基因則助推了RadonDB的產(chǎn)品化過程,不僅能夠了解企業(yè)用戶的應用特點,同時也能加快其研發(fā)速度,讓RadonDB能夠更有針對性地滿足海量數(shù)據(jù)時代下數(shù)據(jù)庫性能與容量需求。2018年初,RadonDB 已在GitHub開源,可以通過radondb.io了解更多詳情和進行深度體驗。