RadonDB：新一代的分布式關(guān)系型數(shù)據(jù)庫

1. 簡介

RadonDB是一款基于MySQL研發(fā)的新一代分布式關(guān)系型數(shù)據(jù)庫(MyNewSQL)。

向用戶提供具備?融級高可用、強(qiáng)一致、超大容量的數(shù)據(jù)庫服務(wù)，高度兼容MySQL語法，自動(dòng)?平分表，智能化擴(kuò)容。

2. RadonDB 的 優(yōu) 勢

(1):自動(dòng)?平分表，一鍵即可開啟智能化擴(kuò)容，擴(kuò)容過程業(yè)務(wù)不中斷。

(2)數(shù)據(jù)多副本并可跨數(shù)據(jù)中?部署，率先使用GTID并行復(fù)制+Raft一致性協(xié)議確保副本間數(shù)據(jù)強(qiáng)一致、零丟失主副本故障自動(dòng)秒級切換，實(shí)現(xiàn)自動(dòng)化運(yùn)維，無需??干預(yù)。

(3)存儲副本使用MySQL(5.7.19)存儲，穩(wěn)定可靠的存儲能力與強(qiáng)大的計(jì)算能力并存。

(4)提供分布式事務(wù)能力，保證跨節(jié)點(diǎn)操作的數(shù)據(jù)一致性。

(5)同時(shí)支持OLTP(高并發(fā)事務(wù)需求)和OLAP(復(fù)雜分析需求)。

(6)高度兼容MySQL語法，數(shù)據(jù)可快速導(dǎo)?、導(dǎo)出，簡單易用。

3. 架構(gòu)

RadonDB由SQL節(jié)點(diǎn)(Distributed SQL Nodes)和存儲節(jié)點(diǎn)(Storage Nodes)以及計(jì)算節(jié)點(diǎn)(Compute Nodes)三大部分組成。

整體架構(gòu)如下：

3.1 SQL節(jié)點(diǎn)

SQL節(jié)點(diǎn)主要負(fù)責(zé):

(1)生成分布式執(zhí)行計(jì)劃(Distributed Plan)

(2)生成分布式執(zhí)行器(Distributed Executor)且并行式執(zhí)行

(3)協(xié)調(diào)分布式事務(wù)

對于用戶的每一個(gè)query，到達(dá)一個(gè)SQL節(jié)點(diǎn)后，處理流程如下：

SQL節(jié)點(diǎn)是無狀態(tài)的，但是為了保證事務(wù)的Snapshot Isolation隔離性，目前是一寫多讀模式。

3.2 存儲節(jié)點(diǎn)

RadonDB整個(gè)存儲層由多個(gè)存儲節(jié)點(diǎn)組成。

每個(gè)存儲節(jié)點(diǎn)默認(rèn)是由一主兩從(三副本)的高可用MySQL集群組成，負(fù)責(zé)分區(qū)數(shù)據(jù)的存儲與計(jì)算。

3.2.1 副本基MySQL存儲

為什么選擇MySQL進(jìn)行副本存儲呢?

我們的考量是:

(1): MySQL穩(wěn)定可靠、多索引寫原子保證

(2):儲存可以異構(gòu)化，InnoDB/TokuDB多引擎可選

(3): 盡量把計(jì)算下推給MySQL，充分發(fā)揮數(shù)據(jù)就近(Data Locality)優(yōu)勢，以減少存儲層與SQL層數(shù)據(jù)傳輸

(4)：MySQL 8.0即將推出，功能更加強(qiáng)大

3.2.2副本高可用，強(qiáng)一致

為了保證節(jié)點(diǎn)內(nèi)副本的高可用，我們把MySQL GTID并行復(fù)制技術(shù)與分布式一致性協(xié)議Raft完美結(jié)合，在主副本故障后自動(dòng)秒級切換并瞬間可用，并確保切換后數(shù)據(jù)零丟失。

在RadonDB里，我們把GTID(Global Transaction Identifier)作為Raft協(xié)議的log index，結(jié)合MySQL的Multi-Threaded Slave (MTS)，可以做到log entry的并行復(fù)制、并行回放，log重放時(shí)間異常短暫，故障切換后即刻對外服務(wù)。

同時(shí)，RadonDB使用強(qiáng)Semi-Sync-Replication技術(shù)確保至少一個(gè)從副本與主副本在數(shù)據(jù)上是完全同步的，當(dāng)主副本故障后，數(shù)據(jù)完全同步的從副本將被選為新的主副本，這樣就確保了數(shù)據(jù)零丟失，并實(shí)現(xiàn)了高可用。

比如，某個(gè)存儲節(jié)點(diǎn)的三副本狀態(tài)為:

這樣當(dāng)Master(主副本)不可服務(wù)的時(shí)候，Slave1(從副本)將被選為新主，Slave2自動(dòng)’CHANGE MASTER TO’到新主Slave1并根據(jù)GTID(4和5)進(jìn)行數(shù)據(jù)同步，切換后狀態(tài)為:

當(dāng)某個(gè)副本不可用被判定為損壞時(shí)，RadonDB則開啟流式重建(streaming-rebuildme)機(jī)制，對該副本進(jìn)行快速重建，以保證足夠多的副本可用。

3.3 數(shù)據(jù)分布

RadonDB對數(shù)據(jù)的劃分最小單元是一個(gè)“小表”。

劃分策略為(默認(rèn)):

(1):整張表共 4096 slots

(2):每個(gè)小表 128 slots

這里的4096和128均可配置，默認(rèn)可支持單表最大4PB的容量(假設(shè)物理盤最大1TB)。

如果我們在RadonDB里創(chuàng)建一個(gè)表t1，數(shù)據(jù)分布情況為:

可以看到，表t1被劃分成32個(gè)小表，它們均勻的分散在多個(gè)存儲節(jié)點(diǎn)上。

每個(gè)小表都有一個(gè)自?的哈希區(qū)間，用于標(biāo)識自?所能存儲的HASH范圍。

3.4 動(dòng)態(tài)擴(kuò)容

為了減少擴(kuò)容數(shù)據(jù)遷移量，RadonDB優(yōu)先以?表為單位進(jìn)行遷移。

RadonDB定期的采集存儲節(jié)點(diǎn)資源使用情況(CPU/Disk/表熱度等)，在擴(kuò)容的時(shí)候會(huì)優(yōu)先選擇這些空間緊張且熱度較高的?表為遷移對象，使得整體資源分配達(dá)到最優(yōu)。

擴(kuò)容時(shí)，?先進(jìn)行全量遷移(并發(fā)式)，然后根據(jù)全量時(shí)的位點(diǎn)進(jìn)行增量同步，如果業(yè)務(wù)寫?較大，數(shù)據(jù)差異量一直呈加大趨勢，RadonDB會(huì)啟動(dòng)動(dòng)態(tài)限流機(jī)制以加快增量遷移。

遷移完畢，RadonDB會(huì)對表數(shù)據(jù)并發(fā)式做Checksum校驗(yàn)，嚴(yán)格保證遷移前后數(shù)據(jù)的正確性，根據(jù)我們的測試(RDB虛機(jī)環(huán)境)，Checksum速率可以達(dá)到300MB/s，所以對這些小表來說還是非常快的。

添加新存儲節(jié)點(diǎn)后數(shù)據(jù)分布情況:

3.5 分布式事務(wù)

為什么需要分布式事務(wù)能力呢?

我們通過一個(gè)例子來說明分布式事務(wù)的重要性，比如用戶執(zhí)行了一個(gè)區(qū)間update操作:

Distributed Executor在不同存儲節(jié)點(diǎn)執(zhí)行情況為:

這里，node2的執(zhí)行器執(zhí)行失敗，其他2個(gè)執(zhí)行成功，如果沒有分布式事務(wù)保證，整個(gè)表其實(shí)是處于一種不一致、甚?數(shù)據(jù)不可用狀態(tài)。

RadonDB提供了分布式事務(wù)能力，node1和node3的操作將被回滾(ROLLBACK)，這樣就保證了跨節(jié)點(diǎn)操作原子性，使數(shù)據(jù)庫處于一個(gè)一致性狀態(tài)。

3.6數(shù)據(jù)一致性

那么，RadonDB支持什么級別的一致性呢?

我們先來看一個(gè)場景，對于2個(gè)不同的client操作，一個(gè)為區(qū)間讀，一個(gè)為區(qū)間更新，比如：

假設(shè)表t1.a初始值全部為0，如果沒有分布式事務(wù)保證, client1的查詢結(jié)果集可能是:

因?yàn)閏lient1的查詢讀到了client2的更新數(shù)據(jù)(部分)。

在RadonDB里，這種情況是不存在的，client1的返回結(jié)果集有2種。

全 部 為1

這種情況發(fā)生在client2-update完成后client1-select再執(zhí)行:

全 部 為0

client1-select的開始(START)在client2-update完成(COMMIT)之前：

RadonDB在一致性上做到了SI(Snapshot Isolation)級別，只要某個(gè)分布式事務(wù)沒有commit，或部分區(qū)已經(jīng)commit，那么它的操作對其他事務(wù)都是不可見的。

我們使用go-jepsen進(jìn)行SI測試，經(jīng)過100多億次操作并檢測，并在檢測期間隨機(jī)kill存儲節(jié)點(diǎn)主副本，均未發(fā)現(xiàn)問題。

go-jepsen是一個(gè)驗(yàn)證SI隔離級別的工具，它的原理比較容易理解:

1個(gè)線程不停的更新(update)整張表，16個(gè)讀線程不停的掃表(scan)，然后對讀到的數(shù)據(jù)進(jìn)行等值校驗(yàn)，如果這批數(shù)據(jù)有差異，說明讀到了update的臟數(shù)據(jù)，是不滿足SI的。

4. 復(fù)雜查詢

對于跨節(jié)點(diǎn)join等復(fù)雜查詢(偏OLAP查詢)，如果放到SQL層實(shí)現(xiàn)，這樣的問題有:

(1)：SQL層與存儲層網(wǎng)絡(luò)傳輸較大，因?yàn)閿?shù)據(jù)要在SQL層進(jìn)行計(jì)算和過濾，導(dǎo)致性能低下或不可用復(fù)雜查詢會(huì)搶占OLTP資源，互相干擾而造成抖動(dòng)

(2):出于以上考慮，RadonDB對于復(fù)雜的OLAP類查詢，SQL層會(huì)自動(dòng)路由到單獨(dú)的計(jì)算節(jié)點(diǎn)進(jìn)行計(jì)算并返回，OLAP和OLTP資源完全隔離，互不影響，用戶在使用時(shí)無感知。

這樣的缺點(diǎn)是數(shù)據(jù)需要2份，目前通過高壓縮解決。

5. 性能

5.1 硬件環(huán)境:

5.2 測試模型

sysbench: 16表, 512線程，隨機(jī)寫，5000萬條數(shù)據(jù)

5.3 測試結(jié)果

可以看到RadonDB的延遲是單機(jī)MySQL的1/3，但性能幾乎是單機(jī)的3倍，這要得益于RadonDB對大表進(jìn)行切分后，用戶的寫操作在這些?表上可并發(fā)式執(zhí)行。

6.數(shù)據(jù)導(dǎo)?和導(dǎo)出

RadonDB目前只支持go-mydumper?式的數(shù)據(jù)導(dǎo)?和導(dǎo)出。

XeLabs/go-mydumper使用go語?開發(fā)，與maxbube/mydumper格式完全兼容，但是對并行進(jìn)行了優(yōu)化，性能更加卓越。

導(dǎo)?數(shù)據(jù)到RadonDB，go-mydumper會(huì)批量并行式導(dǎo)?，??？旖荨?/p>

從RadonDB導(dǎo)出數(shù)據(jù)時(shí)，go-mydumper會(huì)批量并行流式導(dǎo)出，資源占用率較低。

6.1 安 裝go-mydumper

6.2.如何導(dǎo)?數(shù)據(jù)到RadonDB

6.2.1 從數(shù)據(jù)源導(dǎo)出數(shù)據(jù)

?先使用mydumper從別的MySQL數(shù)據(jù)源導(dǎo)出數(shù)據(jù)，比如:

6.2.2 修改schema

在導(dǎo)出目錄(比如sbtest.sql)里找到*-schema.sql(比如sbtest.benchyou0-scehma.sql):

對原語句最后增加’PARTITION BY HASH(分區(qū)鍵)’的語法:

sbtest.benchyou0-schema.sql:

修改為(這里是以id為分區(qū)鍵):

6.2.3導(dǎo)?數(shù)據(jù)到RadonDB

6.4如何導(dǎo)RadonDB數(shù)據(jù)

可以使用mydumper導(dǎo)出RadonDB數(shù)據(jù)，此過程是流式獲取(select語句加’/*backup*/’ hint)并導(dǎo)出，基本不占用系統(tǒng)內(nèi)存。

7. 總結(jié)

RadonDB是一個(gè)基于MySQL而實(shí)現(xiàn)的高可用、強(qiáng)一致的分布式數(shù)據(jù)庫。

RadonDB具備雙層計(jì)算能力，SQL節(jié)點(diǎn)提供基本的計(jì)算能力(結(jié)果集的?次運(yùn)算)，而存儲層由于使用MySQL則具備強(qiáng)大的存儲計(jì)算能力。

對于用戶的每一個(gè)query，RadonDB都盡可能的把計(jì)算下推，讓存儲層MySQL過濾掉更多的數(shù)據(jù)，以減少SQL層和存儲層之間的網(wǎng)絡(luò)傳輸，充分利用data locality優(yōu)勢，發(fā)揮最佳性能。

我們認(rèn)為基于MySQL的分布式數(shù)據(jù)庫(MyNewSQL)遠(yuǎn)未到頭，RadonDB只是一個(gè)開始。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。