1. 簡介
RadonDB是一款基于MySQL研發(fā)的新一代分布式關系型數(shù)據(jù)庫(MyNewSQL)。
向用戶提供具備?融級高可用、強一致、超大容量的數(shù)據(jù)庫服務，高度兼容MySQL語法，自動?平分表，智能化擴容。
2. RadonDB 的 優(yōu) 勢
(1):自動?平分表，一鍵即可開啟智能化擴容，擴容過程業(yè)務不中斷。
(2)數(shù)據(jù)多副本并可跨數(shù)據(jù)中?部署，率先使用GTID并行復制+Raft一致性協(xié)議確保副本間數(shù)據(jù)強一致、零丟失主副本故障自動秒級切換，實現(xiàn)自動化運維，無需??干預。
(3)存儲副本使用MySQL(5.7.19)存儲，穩(wěn)定可靠的存儲能力與強大的計算能力并存。
(4)提供分布式事務能力，保證跨節(jié)點操作的數(shù)據(jù)一致性。
(5)同時支持OLTP(高并發(fā)事務需求)和OLAP(復雜分析需求)。
(6)高度兼容MySQL語法，數(shù)據(jù)可快速導?、導出，簡單易用。
3. 架構
RadonDB由SQL節(jié)點(Distributed SQL Nodes)和存儲節(jié)點(Storage Nodes)以及計算節(jié)點(Compute Nodes)三大部分組成。
整體架構如下：
3.1 SQL節(jié)點
SQL節(jié)點主要負責:
(1)生成分布式執(zhí)行計劃(Distributed Plan)
(2)生成分布式執(zhí)行器(Distributed Executor)且并行式執(zhí)行
(3)協(xié)調分布式事務
對于用戶的每一個query，到達一個SQL節(jié)點后，處理流程如下：
SQL節(jié)點是無狀態(tài)的，但是為了保證事務的Snapshot Isolation隔離性，目前是一寫多讀模式。
3.2 存儲節(jié)點
RadonDB整個存儲層由多個存儲節(jié)點組成。
每個存儲節(jié)點默認是由一主兩從(三副本)的高可用MySQL集群組成，負責分區(qū)數(shù)據(jù)的存儲與計算。
3.2.1 副本基MySQL存儲
為什么選擇MySQL進行副本存儲呢?
我們的考量是:
(1): MySQL穩(wěn)定可靠、多索引寫原子保證
(2):儲存可以異構化，InnoDB/TokuDB多引擎可選
(3): 盡量把計算下推給MySQL，充分發(fā)揮數(shù)據(jù)就近(Data Locality)優(yōu)勢，以減少存儲層與SQL層數(shù)據(jù)傳輸
(4)：MySQL 8.0即將推出，功能更加強大
3.2.2副本高可用，強一致
為了保證節(jié)點內副本的高可用，我們把MySQL GTID并行復制技術與分布式一致性協(xié)議Raft完美結合，在主副本故障后自動秒級切換并瞬間可用，并確保切換后數(shù)據(jù)零丟失。
在RadonDB里，我們把GTID(Global Transaction Identifier)作為Raft協(xié)議的log index，結合MySQL的Multi-Threaded Slave (MTS)，可以做到log entry的并行復制、并行回放，log重放時間異常短暫，故障切換后即刻對外服務。
同時，RadonDB使用強Semi-Sync-Replication技術確保至少一個從副本與主副本在數(shù)據(jù)上是完全同步的，當主副本故障后，數(shù)據(jù)完全同步的從副本將被選為新的主副本，這樣就確保了數(shù)據(jù)零丟失，并實現(xiàn)了高可用。
比如，某個存儲節(jié)點的三副本狀態(tài)為:
這樣當Master(主副本)不可服務的時候，Slave1(從副本)將被選為新主，Slave2自動’CHANGE MASTER TO’到新主Slave1并根據(jù)GTID(4和5)進行數(shù)據(jù)同步，切換后狀態(tài)為:
當某個副本不可用被判定為損壞時，RadonDB則開啟流式重建(streaming-rebuildme)機制，對該副本進行快速重建，以保證足夠多的副本可用。
3.3 數(shù)據(jù)分布
RadonDB對數(shù)據(jù)的劃分最小單元是一個“小表”。
劃分策略為(默認):
(1):整張表共 4096 slots
(2):每個小表 128 slots
這里的4096和128均可配置，默認可支持單表最大4PB的容量(假設物理盤最大1TB)。
如果我們在RadonDB里創(chuàng)建一個表t1，數(shù)據(jù)分布情況為:
可以看到，表t1被劃分成32個小表，它們均勻的分散在多個存儲節(jié)點上。
每個小表都有一個自?的哈希區(qū)間，用于標識自?所能存儲的HASH范圍。
3.4 動態(tài)擴容
為了減少擴容數(shù)據(jù)遷移量，RadonDB優(yōu)先以?表為單位進行遷移。
RadonDB定期的采集存儲節(jié)點資源使用情況(CPU/Disk/表熱度等)，在擴容的時候會優(yōu)先選擇這些空間緊張且熱度較高的?表為遷移對象，使得整體資源分配達到最優(yōu)。
擴容時，?先進行全量遷移(并發(fā)式)，然后根據(jù)全量時的位點進行增量同步，如果業(yè)務寫?較大，數(shù)據(jù)差異量一直呈加大趨勢，RadonDB會啟動動態(tài)限流機制以加快增量遷移。
遷移完畢，RadonDB會對表數(shù)據(jù)并發(fā)式做Checksum校驗，嚴格保證遷移前后數(shù)據(jù)的正確性，根據(jù)我們的測試(RDB虛機環(huán)境)，Checksum速率可以達到300MB/s，所以對這些小表來說還是非?？斓?。
添加新存儲節(jié)點后數(shù)據(jù)分布情況:
3.5 分布式事務
為什么需要分布式事務能力呢?
我們通過一個例子來說明分布式事務的重要性，比如用戶執(zhí)行了一個區(qū)間update操作:
Distributed Executor在不同存儲節(jié)點執(zhí)行情況為:
這里，node2的執(zhí)行器執(zhí)行失敗，其他2個執(zhí)行成功，如果沒有分布式事務保證，整個表其實是處于一種不一致、甚?數(shù)據(jù)不可用狀態(tài)。
RadonDB提供了分布式事務能力，node1和node3的操作將被回滾(ROLLBACK)，這樣就保證了跨節(jié)點操作原子性，使數(shù)據(jù)庫處于一個一致性狀態(tài)。
3.6數(shù)據(jù)一致性
那么，RadonDB支持什么級別的一致性呢?
我們先來看一個場景，對于2個不同的client操作，一個為區(qū)間讀，一個為區(qū)間更新，比如：
假設表t1.a初始值全部為0，如果沒有分布式事務保證, client1的查詢結果集可能是:
因為client1的查詢讀到了client2的更新數(shù)據(jù)(部分)。
在RadonDB里，這種情況是不存在的，client1的返回結果集有2種。
全 部 為1
這種情況發(fā)生在client2-update完成后client1-select再執(zhí)行:
全 部 為0
client1-select的開始(START)在client2-update完成(COMMIT)之前：
RadonDB在一致性上做到了SI(Snapshot Isolation)級別，只要某個分布式事務沒有commit，或部分區(qū)已經commit，那么它的操作對其他事務都是不可見的。
我們使用go-jepsen進行SI測試，經過100多億次操作并檢測，并在檢測期間隨機kill存儲節(jié)點主副本，均未發(fā)現(xiàn)問題。
go-jepsen是一個驗證SI隔離級別的工具，它的原理比較容易理解:
1個線程不停的更新(update)整張表，16個讀線程不停的掃表(scan)，然后對讀到的數(shù)據(jù)進行等值校驗，如果這批數(shù)據(jù)有差異，說明讀到了update的臟數(shù)據(jù)，是不滿足SI的。
4. 復雜查詢
對于跨節(jié)點join等復雜查詢(偏OLAP查詢)，如果放到SQL層實現(xiàn)，這樣的問題有:
(1)：SQL層與存儲層網(wǎng)絡傳輸較大，因為數(shù)據(jù)要在SQL層進行計算和過濾，導致性能低下或不可用復雜查詢會搶占OLTP資源，互相干擾而造成抖動
(2):出于以上考慮，RadonDB對于復雜的OLAP類查詢，SQL層會自動路由到單獨的計算節(jié)點進行計算并返回，OLAP和OLTP資源完全隔離，互不影響，用戶在使用時無感知。
這樣的缺點是數(shù)據(jù)需要2份，目前通過高壓縮解決。
5. 性能
5.1 硬件環(huán)境:
5.2 測試模型
sysbench: 16表, 512線程，隨機寫，5000萬條數(shù)據(jù)
5.3 測試結果
可以看到RadonDB的延遲是單機MySQL的1/3，但性能幾乎是單機的3倍，這要得益于RadonDB對大表進行切分后，用戶的寫操作在這些?表上可并發(fā)式執(zhí)行。
6.數(shù)據(jù)導?和導出
RadonDB目前只支持go-mydumper?式的數(shù)據(jù)導?和導出。
XeLabs/go-mydumper使用go語?開發(fā)，與maxbube/mydumper格式完全兼容，但是對并行進行了優(yōu)化，性能更加卓越。
導?數(shù)據(jù)到RadonDB，go-mydumper會批量并行式導?，??？旖?。
從RadonDB導出數(shù)據(jù)時，go-mydumper會批量并行流式導出，資源占用率較低。
6.1 安 裝go-mydumper
6.2.如何導?數(shù)據(jù)到RadonDB
6.2.1 從數(shù)據(jù)源導出數(shù)據(jù)
?先使用mydumper從別的MySQL數(shù)據(jù)源導出數(shù)據(jù)，比如:
6.2.2 修改schema
在導出目錄(比如sbtest.sql)里找到*-schema.sql(比如sbtest.benchyou0-scehma.sql):
對原語句最后增加’PARTITION BY HASH(分區(qū)鍵)’的語法:
sbtest.benchyou0-schema.sql:
修改為(這里是以id為分區(qū)鍵):
6.2.3導?數(shù)據(jù)到RadonDB
6.4如何導RadonDB數(shù)據(jù)
可以使用mydumper導出RadonDB數(shù)據(jù)，此過程是流式獲取(select語句加’/*backup*/’ hint)并導出，基本不占用系統(tǒng)內存。
7. 總結
RadonDB是一個基于MySQL而實現(xiàn)的高可用、強一致的分布式數(shù)據(jù)庫。
RadonDB具備雙層計算能力，SQL節(jié)點提供基本的計算能力(結果集的?次運算)，而存儲層由于使用MySQL則具備強大的存儲計算能力。
對于用戶的每一個query，RadonDB都盡可能的把計算下推，讓存儲層MySQL過濾掉更多的數(shù)據(jù)，以減少SQL層和存儲層之間的網(wǎng)絡傳輸，充分利用data locality優(yōu)勢，發(fā)揮最佳性能。
我們認為基于MySQL的分布式數(shù)據(jù)庫(MyNewSQL)遠未到頭，RadonDB只是一個開始。
免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。
