国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

18143453325 或 在線咨詢 在線咨詢
18143453325 或 在線咨詢
所在位置： 首頁(yè) > 營(yíng)銷資訊 > 電子商務(wù) > 國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)對(duì)比

國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)對(duì)比

時(shí)間：2023-03-13 08:40:01 | 來(lái)源：電子商務(wù)

時(shí)間：2023-03-13 08:40:01 來(lái)源：電子商務(wù)

轉(zhuǎn)自：https://cloud.tencent.com/developer/article/1574148

引入

與Oracle在華大規(guī)模裁員相比，國(guó)產(chǎn)數(shù)據(jù)庫(kù)好消息連連，2019年可以說(shuō)是國(guó)產(chǎn)數(shù)據(jù)庫(kù)年。舉幾個(gè)例子，華為推出GaussDB，并成功上線招商銀行/工商銀行核心系統(tǒng);中信信用卡系統(tǒng)運(yùn)行在中興GoldenDB之上；Oceanbase登頂TPC-C....

雖然近些年國(guó)內(nèi)外云計(jì)算如火如荼，但如果你關(guān)心IT新聞的話會(huì)發(fā)現(xiàn)，國(guó)產(chǎn)數(shù)據(jù)庫(kù)針對(duì)的并不是云，而是on premise，特別是金融業(yè)（《盤點(diǎn)2019：對(duì)國(guó)產(chǎn)數(shù)據(jù)庫(kù)的一點(diǎn)觀察和總結(jié)》）。本文主要分析一下on premise 數(shù)據(jù)庫(kù)，特別是分布式數(shù)據(jù)庫(kù)。

現(xiàn)在的分布式數(shù)據(jù)庫(kù)基本上都借鑒Google的spanner/F1論文,采用paxos/raft協(xié)議來(lái)保證數(shù)據(jù)的強(qiáng)一致性，所以從架構(gòu)上來(lái)都類似，可以明顯區(qū)分出計(jì)算節(jié)點(diǎn)和存儲(chǔ)節(jié)點(diǎn)。但Oracle Exadata脫胎于集中式的共享存儲(chǔ)，令人驚訝的是，它的架構(gòu)與這些分布式數(shù)據(jù)庫(kù)不謀而合。

Oracle

Oracle是國(guó)產(chǎn)數(shù)據(jù)庫(kù)最大的競(jìng)爭(zhēng)對(duì)手，也是大家相對(duì)熟悉的數(shù)據(jù)庫(kù)，讓我們從它入手。 下圖是一個(gè)經(jīng)典的Oracle體系架構(gòu)圖。

圖 1

硬件上它由至少2臺(tái)服務(wù)器以及共享的存儲(chǔ)組成，它們之間的通訊通過高速網(wǎng)絡(luò)完成，軟件上，一般是Oracle RAC。

在2008年，Oracle推出了數(shù)據(jù)庫(kù)一體機(jī)Exadata，它的架構(gòu)如下圖：

圖 2

共享的集中式存儲(chǔ)變成了多個(gè)普通的x86存儲(chǔ)節(jié)點(diǎn)，它和后面我們提到的share nothing的國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)有很多相似之處。

關(guān)于Oracle Exadata的詳細(xì)文檔，可以參考《Oracle Exadata技術(shù)白皮書》，這里只對(duì)幾個(gè)主要組件做一個(gè)大概介紹。

TIDB

TiDB是近幾年很火的分布式數(shù)據(jù)庫(kù)，它的架構(gòu)最近似Oracle，下圖和主要組件的解釋來(lái)自官網(wǎng)。

圖 3

TiDB

TiDB 是無(wú)狀態(tài)的，推薦至少部署兩個(gè)實(shí)例，前端通過負(fù)載均衡組件對(duì)外提供服務(wù)。當(dāng)單個(gè)實(shí)例失效時(shí)，會(huì)影響正在這個(gè)實(shí)例上進(jìn)行的 Session，從應(yīng)用的角度看，會(huì)出現(xiàn)單次請(qǐng)求失敗的情況，重新連接后即可繼續(xù)獲得服務(wù)。單個(gè)實(shí)例失效后，可以重啟這個(gè)實(shí)例或者部署一個(gè)新的實(shí)例。

PD

PD 是一個(gè)集群，通過 Raft 協(xié)議保持?jǐn)?shù)據(jù)的一致性，單個(gè)實(shí)例失效時(shí)，如果這個(gè)實(shí)例不是 Raft 的 leader，那么服務(wù)完全不受影響；如果這個(gè)實(shí)例是 Raft 的 leader，會(huì)重新選出新的 Raft leader，自動(dòng)恢復(fù)服務(wù)。PD 在選舉的過程中無(wú)法對(duì)外提供服務(wù)，這個(gè)時(shí)間大約是3秒鐘。推薦至少部署三個(gè) PD 實(shí)例，單個(gè)實(shí)例失效后，重啟這個(gè)實(shí)例或者添加新的實(shí)例。

TiKV

TiKV 是一個(gè)集群，通過 Raft 協(xié)議保持?jǐn)?shù)據(jù)的一致性（副本數(shù)量可配置，默認(rèn)保存三副本），并通過 PD 做負(fù)載均衡調(diào)度。單個(gè)節(jié)點(diǎn)失效時(shí)，會(huì)影響這個(gè)節(jié)點(diǎn)上存儲(chǔ)的所有 Region。對(duì)于 Region 中的 Leader 結(jié)點(diǎn)，會(huì)中斷服務(wù)，等待重新選舉；對(duì)于 Region 中的 Follower 節(jié)點(diǎn)，不會(huì)影響服務(wù)。當(dāng)某個(gè) TiKV 節(jié)點(diǎn)失效，并且在一段時(shí)間內(nèi)（默認(rèn) 30 分鐘）無(wú)法恢復(fù)，PD 會(huì)將其上的數(shù)據(jù)遷移到其他的 TiKV 節(jié)點(diǎn)上。

可以簡(jiǎn)單地和Oracle做個(gè)對(duì)比:



Oceanbase

Oceanbase組件概念：

圖 4 - Oceanbase組件，原來(lái)于云棲社區(qū)

OceanBase由如下幾個(gè)部分組成：

客戶端：用戶使用OccanBase的方式和MySQL數(shù)據(jù)庫(kù)完全相同，支持JDBC、C客戶端訪問，等等?；贛ySQL數(shù)據(jù)庫(kù)開發(fā)的應(yīng)用程序、工具能夠直接遷移到OceanBase。

RootServer:管理集群中的所有服務(wù)器，子表（tablet）數(shù)據(jù)分布以及副本管理。RootServer一般為一主一備，主備之間數(shù)據(jù)強(qiáng)同步。

UpdateServer:存儲(chǔ)OccanBase系統(tǒng)的增量更新數(shù)據(jù)。UpdateServer一般為一主一備，主備之間可以配置不同的同步模式。部署時(shí)，UpdateServer進(jìn)程和RootServer 進(jìn)程往往共用物理服務(wù)器。

ChunkServer:存儲(chǔ)OccanBase系統(tǒng)的基線數(shù)據(jù)?；€數(shù)據(jù)一般存儲(chǔ)兩份或者三份，可配置。 MergeServer:接收并解析用戶的SQL請(qǐng)求，經(jīng)過詞法分析、語(yǔ)法分析、查詢優(yōu)化等一系列操作后轉(zhuǎn)發(fā)給相應(yīng)的ChunkServer或者UpdateServer。如果請(qǐng)求的數(shù)據(jù)分布在多臺(tái)ChunkServer上，MergeServer 還需要對(duì)多臺(tái)ChunkServer返回的結(jié)果進(jìn)行合并。客戶端和MergeScrver之間采用原生的MySQL通信協(xié)議，MySQL客戶端可以直接訪問MergeServer。 OceanBase支持部署多個(gè)機(jī)房，每個(gè)機(jī)房部署一個(gè)包含RootServer、MergeServer、ChunkServer以及UpdateServer 的完整OceanBase集群，每個(gè)集群由各自的RootServer負(fù)責(zé)數(shù)據(jù)劃分、負(fù)載均衡、集群服務(wù)器管理等操作，集群之間數(shù)據(jù)同步通過主集群的主UpdateSever往備集群同步增量更新操作日志實(shí)現(xiàn)?？蛻舳伺渲昧硕鄠€(gè)集群的RootServer地址列表，使用者可以設(shè)置每個(gè)集群的流量分配比例，客戶端根據(jù)這個(gè)比例將讀寫操作發(fā)往不同的集群。

再翻譯一下，

tablet是一個(gè)類似AU 和Region的概念。Oracle中AU是datafile的一部分，TiDB中Region和oceanbase tablet都是table的部分?jǐn)?shù)據(jù)。

從文中描述中還可以看到所有的寫操作都要經(jīng)過UpdateServer。這是一個(gè)潛在問題？

在Oracle中有個(gè)DRM概念，每個(gè)對(duì)象都有一個(gè)master，針對(duì)這個(gè)對(duì)象的讀寫都要通過這個(gè)master來(lái)獲得相應(yīng)的權(quán)限。但DRM的bug很多，多個(gè)版本中都要求關(guān)閉這個(gè)特性。Oceanbase似乎將這個(gè)功能獨(dú)立出來(lái)，將UpdateServer作為所有對(duì)象的master并負(fù)責(zé)所有的寫，以避免相應(yīng)問題，但顯而易見也可能引入了另外一個(gè)瓶頸。

如有可能，是不是在多租戶環(huán)境把另外一個(gè)備updateserver利用起來(lái)，甚至是部署多個(gè)updateserver為不同的租戶服務(wù)？

單活rootserver不是一個(gè)問題，在大部分集群包括Oracle RAC中也有相應(yīng)的OCR/PE master概念，重要的是切換時(shí)間。

GaussDB

GaussDB 架構(gòu)圖：

圖 5 - GaussDB 架構(gòu)圖 （來(lái)源于《GaussDB 200 一體機(jī) 6.5.1 產(chǎn)品文檔》）

簡(jiǎn)單明了

GaussDB中沒有類似AU/Region/tablet這樣的概念，它的同步是通過主備DN完成的。副本的同步單位是DN，這個(gè)顆粒度很大。一個(gè)DN其實(shí)就是一個(gè)數(shù)據(jù)庫(kù)，日志和數(shù)據(jù)存在于同一個(gè)節(jié)點(diǎn)。為防止一個(gè)DN崩潰的時(shí)候數(shù)據(jù)丟失，主備最好采用強(qiáng)同步，類似用Oracle中的最大保護(hù)模式，眾所周知這種模式會(huì)導(dǎo)致性能下降，并增大系統(tǒng)的不可用性。

TDSQL

騰訊TDSQL 架構(gòu)圖：

圖 5 - TDSQL 架構(gòu)圖 （來(lái)源于《騰訊專有云數(shù)據(jù)庫(kù)TDSQL白皮書 V2.0》）

l 物理節(jié)點(diǎn)組(SET)：由 MySQL 、 監(jiān)控和信息采集(TAgent)組成，通常情況下

l 決策集群：TzooKeeper它是TDSQL提供配置維護(hù)、選舉決策、路由同步等，并能支撐數(shù)據(jù)庫(kù)節(jié)點(diǎn)組（分片）的創(chuàng)建、刪除、替換等工作，并統(tǒng)一下發(fā)和調(diào)度所有 DDL （數(shù)據(jù)庫(kù)模式定義語(yǔ)言）操作， 通常決策集群需要采用奇數(shù)臺(tái)，實(shí)際部署的時(shí)候應(yīng) 大于等于 3 組并跨機(jī)房部署 。

l 接入網(wǎng)關(guān)集群(OLTP Proxy)：在網(wǎng)絡(luò)層連接管理 SQL 解析、分配路由 。請(qǐng)注意,OLTP Proxy并非騰訊云網(wǎng)關(guān) TGW 集群 。

1. OLTP Proxy 通常與 MySQL 混合部署，也可以部署在不同物理設(shè)備中

2. 從配置集群(TzooKeeper)拉取數(shù)據(jù)庫(kù)節(jié)點(diǎn)（分片）狀態(tài)，提供分片路由，實(shí)現(xiàn)透明讀寫；

3. 記錄并監(jiān)控 SQL 執(zhí)行信息，分析 SQL 執(zhí)行效率，記錄并監(jiān)控用戶接入信息，進(jìn)行安全性鑒權(quán)，阻斷風(fēng)險(xiǎn)操作；

4. OLTP Proxy 通?？梢灾苯釉L問，但仍然建議前端部署,需部署可提供負(fù)載均衡能力網(wǎng)關(guān)并由網(wǎng)關(guān)對(duì)用戶提供唯一虛擬IP服務(wù)。

比較容易提取出我們關(guān)心的幾個(gè)組件

從圖中可以看到類似于GaussDB的數(shù)據(jù)節(jié)點(diǎn)主從關(guān)系的架構(gòu)，但TDSQL采用了自研的MySQL協(xié)議的異步多線程強(qiáng)同步復(fù)制方案（Multi-thread Asynchronous Replication MAR），性能遠(yuǎn)優(yōu)于Mysql/Mariadb。

詳細(xì)的技術(shù)解釋可以參考《騰訊自主可控?cái)?shù)據(jù)庫(kù)TDSQL的架構(gòu)演進(jìn)》。

達(dá)夢(mèng)DM

達(dá)夢(mèng)數(shù)據(jù)庫(kù)架構(gòu)圖：

圖 7 - 達(dá)夢(mèng)數(shù)據(jù)庫(kù)架構(gòu)圖 （來(lái)源于《DM8大規(guī)模并行處理MPP》）

DM8 MPP不能明顯區(qū)分DBServer和數(shù)據(jù)節(jié)點(diǎn)，MAL類似于Oracle Cache Fusion，將多個(gè)普通DM數(shù)據(jù)庫(kù)融合在一起的。

上圖不包含數(shù)據(jù)節(jié)點(diǎn)的備份，其高可靠環(huán)境中推薦對(duì)EP采用交叉守護(hù)的方式。比較接近GaussDB和TDSQL。

從手冊(cè)中可以看到節(jié)點(diǎn)擴(kuò)展比較復(fù)雜，針對(duì)不同表類型和表進(jìn)行專門的sql進(jìn)行重分發(fā)。參考5.2.2 動(dòng)態(tài)增加節(jié)點(diǎn)。

對(duì)比表格

把上面內(nèi)容做個(gè)表格

總結(jié)

Oracle RAC對(duì)網(wǎng)絡(luò)延時(shí)有嚴(yán)格要求，在現(xiàn)實(shí)中很少見到異地雙活/多活的RAC，而且從Oracle Exadata手冊(cè)中，Infiniband 的最長(zhǎng)的距離是10米，這也導(dǎo)致異地雙活成為不可能。而基于paxos/raft協(xié)議的分布式數(shù)據(jù)庫(kù)是可以的，甚至是兩地三活，n地n活。

在最新版本的Exadata中，Oracle已經(jīng)用100Gb RoCE替代了Infiniband，但異地副本多活并未提及。

在副本顆粒度上而言，Oracle,TiDB 和oceanbase采取的是KV存儲(chǔ)的模式。

這里熟悉Oracle讀者可能比較困惑，Oracle從來(lái)沒有提過KV啊。來(lái)看Oracle中的2個(gè)概念。



再看看TiDB中的Region，存儲(chǔ)數(shù)據(jù)的基本單位是 Region，每個(gè) Region 負(fù)責(zé)存儲(chǔ)一個(gè) Key Range（從 StartKey 到 EndKey 的左閉右開區(qū)間）的數(shù)據(jù)。

簡(jiǎn)單看table的Key：TiDB 對(duì)每個(gè)表分配一個(gè) TableID，每一個(gè)索引都會(huì)分配一個(gè) IndexID，每一行分配一個(gè) RowID（如果表有整數(shù)型的 Primary Key，那么會(huì)用 Primary Key 的值當(dāng)做 RowID），其中 TableID 在整個(gè)集群內(nèi)唯一，IndexID/RowID 在表內(nèi)唯一，這些 ID 都是 int64 類型。

每行數(shù)據(jù)按照如下規(guī)則進(jìn)行編碼成 Key-Value pair： Key： tablePrefix_rowPrefix_tableID_rowID Value: [col1, col2, col3, col4]

這個(gè)key不就是rowid么？

GaussDB/TDSQL/DM副本是DataNode級(jí)別的，它并沒有形成Google論文中分布式存儲(chǔ)的架構(gòu)，這增加單點(diǎn)故障的概率。另外，以DN為單位的副本的設(shè)計(jì)沒有天然分片特性，所以他們都引入了shardkey的建表語(yǔ)法。

GuassDB

create table T1(c1 INT,C2 INT) distribute by hash(c1);

TDSQL

create table test1 ( a int, b int, c char(20),primary key (a,b),unique key u_1(a,c) ) shardkey=a;

DM

CREATE TABLE T1(C1 INT,C2 INT) DISTRIBUTED BY　HASH(C1);

單機(jī)版本和分布式版本建表語(yǔ)法是不一樣的，給用戶遷移到分布式帶來(lái)額外的工作。從達(dá)夢(mèng)的手冊(cè)來(lái)看，增加節(jié)點(diǎn)操作是個(gè)很繁瑣的操作。刪除節(jié)點(diǎn)?只在TiDB文檔中明確提到。

副本的粒度還帶來(lái)分布式事務(wù)實(shí)現(xiàn)的不同。在DN粒度下，任何一個(gè)事務(wù)都可能變成分布式事物，采用兩階段提交，因?yàn)槊總€(gè)DN是作為一個(gè)獨(dú)立的關(guān)系型數(shù)據(jù)庫(kù)存在的。

KV模式是不是更優(yōu)秀，由于本人學(xué)識(shí)有限，不做過多討論，另外有些大名鼎鼎的數(shù)據(jù)庫(kù)MongoDB sharding/Oracle Sharding采用的也是DN方式。

TiDB存儲(chǔ)(TiKV)采用了rocksdb，從Oracle Exadata的發(fā)展來(lái)看，存儲(chǔ)這一層可以做的文章還很多，比如flashcache，flashlog，cell2cell 數(shù)據(jù)傳輸?shù)?。采用racksdb是否放棄了這一層?

Oceanbase集群中只有一個(gè)updateserver，它有可能是一個(gè)瓶頸，而且很容易讓人聯(lián)想到1寫n讀這種架構(gòu)，希望未來(lái)可以擴(kuò)展。

華為的優(yōu)勢(shì)在于軟硬件都有，它的GuassDB在鯤鵬芯片上應(yīng)該運(yùn)行得最好，能一站式滿足自研可控需求。

TDSQL和GuassDB有類似的主備同步問題，但這2家公司都是有自主的分布式存儲(chǔ)產(chǎn)品，是否可以用來(lái)解決主備存儲(chǔ)節(jié)點(diǎn)強(qiáng)一致的缺點(diǎn)。

DM是一家傳統(tǒng)的國(guó)產(chǎn)數(shù)據(jù)庫(kù)企業(yè)，圈外人對(duì)其了解不多，但它其實(shí)是政企圈內(nèi)的老大。分布式產(chǎn)品成熟度有待檢驗(yàn)，文檔是國(guó)內(nèi)數(shù)據(jù)庫(kù)廠商中最完整最誠(chéng)實(shí)的。

題外話，本人并未有國(guó)產(chǎn)數(shù)據(jù)庫(kù)使用經(jīng)驗(yàn)，在網(wǎng)上翻來(lái)覆去找到最多的是各個(gè)廠商的宣傳資料，而對(duì)產(chǎn)品運(yùn)維開發(fā)這些方面討論很少。產(chǎn)品好壞只是一方面，另一方面是生態(tài)的培養(yǎng)建立。希望當(dāng)大家真正使用上國(guó)產(chǎn)數(shù)據(jù)庫(kù)的時(shí)候，尋找資料會(huì)像Oracle，MySQL，PG那樣方便。

關(guān)鍵詞：對(duì)比,數(shù)據(jù),分布,國(guó)產(chǎn)

74
73
25
news

版權(quán)所有? 億企邦 1997-2025 保留一切法律許可權(quán)利。

為了最佳展示效果，本站不支持IE9及以下版本的瀏覽器，建議您使用谷歌Chrome瀏覽器。 點(diǎn)擊下載Chrome瀏覽器
關(guān)閉