您好,登錄后才能下訂單哦!
怎么解析RadonDB分布式數據庫核心技術與實現,相信很多沒有經驗的人對此束手無策,為此本文總結了問題出現的原因和解決方法,通過這篇文章希望你能解決這個問題。
摘要:隨著數據規模的逐步擴大,存儲和運維成本逐漸增加,企業對數據庫的要求也逐漸提高。有人認為以MySQL為代表的傳統數據庫已經過時,不能滿足數據爆炸時代企業的要求;以NoSQL為代表的新型數據庫仍有局限性,不具備ACID特性,很難滿足企業對核心業務數據的嚴苛需求。此次分享的RadonDB是一款將分布式一致性協議Raft與MySQL相結合的新一代分布式關系型數據庫。RadonDB的最大特點是結合兩類數據庫的優點,讓DBA無縫地從傳統的、單機時代的MySQL過渡到云原生的、無限擴展的分布式關系型數據庫。
RadonDB架構圖
RadonDB定位是新一代分布式關系數據庫,在今天這個云計算快速發展的時代,我們更愿意稱它是一個云原生數據庫,云原生數據庫的天然屬性是分布式、可擴展、高可用、強一致。下面的MyNewSQL,是因為我們把MySQL和NewSQL融合起來,來滿足以上的幾個特性。
當中一個請求到來之后,SQL層會把這個請求解析成分布式的執行計劃,然后,把這個SQL在后端的存儲層并行的執行。而且它還會進行二次運算,就是Orderby/limit/groupby/aggration/join….等等。它還是一個無中心化的設計,部署起來比較方便,容易擴展,這是整個SQL層的一個設計。
Storage Nodes
再看存儲層,存儲層是RadonDB里一個比較新穎的設計,也是我們定位為在新一代分布式數據庫的一個原因。
第一個挑戰,怎么快速選主?
第二個挑戰,選出新的主后,數據怎么快速地回放?
第三個挑戰,數據回放完,數據怎么保證不丟失? RadonDB是怎么解決的?
對于第一個挑戰,我們使用了Raft協議,大家要知道,Raft協議主要干兩件事,第一個就是選主,第二個是數據同步。在RadonDB里只使用Raft進行選主,當主掛掉之后,我們使用Raft選出新的主,然后數據同步。我們是基于MySQL原生的FGTID機制和并行復制這些特性進行快速回放。
保證數據不丟失,我們還是基于MySQL,并使用了MySQL的Semi-Sync機制,當用戶寫到主副本時,首先,它要到達一個從副本,從副本收到之后,再反饋給客戶端,這樣就時刻地保證了一個從副本與主副本的數據完全一致,從節點被選入新的主節點,保證了這個數據不丟失。
當選入新的主節點之后,RadonDB的Log 并行復制還是基于MySQL的機制,并行復制,快速地回放,這就等于實現了把Raft選主和Log 并行復制結合。原生態Raft協議里這兩個,Raft Log并行回放是比較困難的,但是,我們結合MySQL就很好地完成了。而且,這三個副本是一個無中心化的設計,只要我們可達,它的部署比較靈活。
擴容
RadonDB的底層是全部基于MySQL,所以在擴容的時候也比較方便,因為MySQL有一套工具和機制。
大家可以看到上圖,其實MySQL Xa機制總共有5個步驟,但是到RadonDB里,我們進行了抽象,就是進行了封裝。我們實現了快照的隔離級別,實現了Snapshot Isolation事務隔離級別。
Binlog
另外,RadonDB支持Binlog,大家可能認為一個分布式數據庫,就是里面需要放一些海量的數據,但數據一旦進入你的分布數據庫,怎么能出來?就比較麻煩,因此, RadonDB提供一個Binlog機制,就是讓數據能快速的同步處理。
OLTP + OLAP
比如說,我們有一個OLAP的集群,可設置為RadonDB的Binlog,Binlog是實時地更新,這就完成了一個異構化的過程和數據流出,而且是實時的。
大家也看到,在剛才的架構圖里,右下角有一個計算節點,其實,我們的計算節點就是通過這種機制跟RadonDB的數據進行同步。這樣,就把OLTP和OLAP結合了起來,當用戶一個比較復雜的查詢到達RadonDB之后,RadonDB會根據SQL的模式發到TP節點還是AP節點,前端的用戶是沒有感知的,這就做到了一些資源的隔離。當然了,這也有一個缺點,數據可能是兩份,但目前,我們是通過異構化、列式存儲來進行的,高壓縮做這種機制。
審計日志
另外,RadonDB還提供了一些審計日志這些功能,為了方便大家對業務進行一些審計,而且審計機制還可以定位一些慢查詢SQL,因為分布式的數據庫,節點比較多,所以定位一個SQL會比較復雜,有了審計日志,大家可以定位一些慢的SQL。
備份和恢復
RadonDB提供了一整套備份和恢復的工具,可以讓用戶快速地把數據流進去,流出來,比原生的要快很多。
性能
mysql> show processlist;
第一條命是,MySQL常用的,表示用戶的鏈接到RadonDB的狀態。
mysql> show txnz;
第二個命令是,分布式事務在哪個階段執行,耗時多少,這個都可以很清楚地看到。
mysql> show queryz;
最后一個命令,具體哪些子句落到哪些節點,甚至耗時多少,比如說,某個節點有一些問題,都可以從這個上面反映出來,比較靈活。
看完上述內容,你們掌握怎么解析RadonDB分布式數據庫核心技術與實現的方法了嗎?如果還想學到更多技能或想了解更多相關內容,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。