【51CTO.com原創(chuàng)稿件】行業(yè)背景

隨著全球經(jīng)濟下行壓力增大，中美貿(mào)易摩擦愈演愈烈，美國一系列的經(jīng)濟制裁和技術封鎖使得我們有種被扼住咽喉的感覺，數(shù)據(jù)庫作為基礎軟件中的重要一環(huán)有著很深的技術含量，在這樣的大背景下國產(chǎn)數(shù)據(jù)庫廠商開始發(fā)力，這其中分布式數(shù)據(jù)庫如雨后春筍般出現(xiàn)，良性的競爭環(huán)境使它們都得到了長足的發(fā)展，其中不乏優(yōu)秀的產(chǎn)品，本文主要挑選目前幾個相對成熟數(shù)據(jù)庫進行架構特點介紹。

分布式數(shù)據(jù)庫總體架構

分布式數(shù)據(jù)庫總體設計有兩個思路和方向，一個是基于共享存儲的架構(share everything)，另一個是基于數(shù)據(jù)分片的架構(share nothing)。

共享存儲的架構特點是底層存儲共用一份數(shù)據(jù)池子，上層數(shù)據(jù)庫server層可以彈性擴展，典型的案例像DB2 pureScale，Oracle RAC，阿里云PolarDB等，這種架構的好處是天然適合做云數(shù)據(jù)庫，比如阿里云，上層的SQL引擎可以是MySQL也可以是PG，而且可以無限擴展，底層的存儲其實是一起的，用戶申請只是申請幾個上層的MySQL或者PG server同時在底層存儲開辟一塊空間給用戶，這樣的話可以做到資源的彈性伸縮。這種架構的數(shù)據(jù)庫嚴格意義上不能稱之為分布式數(shù)據(jù)庫。

數(shù)據(jù)分片架構的特點是底層數(shù)據(jù)通過一定的規(guī)則比如hash或者range讓數(shù)據(jù)打散分別分布到不同的數(shù)據(jù)節(jié)點上，計算時底層多個節(jié)點共同參與計算，可以算是一種mpp并行計算的架構，同時數(shù)據(jù)節(jié)點可以擴展，上層由協(xié)調(diào)節(jié)點進行SQL解析和轉發(fā)，這是目前典型的分布式數(shù)據(jù)庫架構，也是本文討論的重點。

目前分布式數(shù)據(jù)庫的總體架構設計基本都和下圖相差不大，每種產(chǎn)品在不同組件的實現(xiàn)上存在差異，但大體架構上類似。

從圖中可以看到分布式數(shù)據(jù)庫三大組件：協(xié)調(diào)節(jié)點、數(shù)據(jù)節(jié)點、全局事務管理器。協(xié)調(diào)節(jié)點負責SQL解析轉發(fā)，充當?shù)氖穷愃苝roxy的角色，數(shù)據(jù)節(jié)點負責計算和數(shù)據(jù)存儲，全局事務管理器負責全局事務讀一致性的保證。

下面分別介紹一下目前主流的分布式數(shù)據(jù)庫的架構以及設計差異。

1.TiDB

TiDB是目前在互聯(lián)網(wǎng)界風靡的一款分布式數(shù)據(jù)庫，由PingCAP公司研發(fā)，由三大組件構成，底層TiKV Server是Github開源組件，是一個分布式的kv存儲引擎，做數(shù)據(jù)存儲，對應數(shù)據(jù)節(jié)點;上層TiDB Server由PingCAP公司研發(fā)，用作SQL解析和轉發(fā)，對應協(xié)調(diào)節(jié)點;PD Server復制全局時間戳分配，對應全局事務管理器。下面列舉了它的架構特點：

①輕量化，深受互聯(lián)網(wǎng)公司喜愛，適合與容器進行集成，當前PingCAP公司也在做TiDB operator，將TiDB容器化。

②部署簡便，基于Ansible Playbook實現(xiàn)自動化部署。

③實現(xiàn)了基于Region級別的raft復制，將數(shù)據(jù)表拆分成一個個的Region，Region一主兩備基于raft協(xié)議做復制，同時Region還會根據(jù)負載情況進行合并和分裂，由PD Server進行負載均衡調(diào)度。

④使用隱藏列作為分布列，分布列不占用真實列，這樣在進行數(shù)據(jù)修改時數(shù)據(jù)不需要進行重分布，大致原理是使用表名和主鍵前面加上前綴信息作為隱藏列，再使用該列進行hash分布。

⑤TiDB Server總體兼容MySQL語法，這個兼容并不是將MySQL Server直接拿過來使用，因為TiKV底層是kv的存儲模型，所以TiDB在執(zhí)行sql的時候需要做sql到kv的映射。

⑥TiKV可以看成一個大的數(shù)據(jù)池子，在物理機層面不存在哪個機器是主，哪個是備，所有機器都是主節(jié)點，熱點數(shù)據(jù)會自動進行動態(tài)負載均衡，數(shù)據(jù)是動態(tài)移動的。

⑦總體借鑒了Google spanner f1和bigtable的論文，PD Server實現(xiàn)了邏輯上的時間戳，谷歌論文也提出了原子鐘的概念，從物理上保證事務號全局有序。

2.OceanBase

OceanBase是螞蟻金服自研的分布式數(shù)據(jù)庫，號稱代碼從第一行完全自研。最近ob也屢屢刷新新聞頭條，刷榜TPCC官網(wǎng)測試結果，刷新天貓交易額和tps記錄，不過金融行業(yè)比如銀行的應用案例并不多，也許是銀行和支付寶可能天然有鴻溝吧。ob架構比較特殊，下面介紹一下它的架構特點：

①最底層是ob server，每個ob server集成了總控服務、sql引擎、存儲引擎和數(shù)據(jù)分區(qū)。

②上層是ob proxy，實現(xiàn)sql的路由，這個不止是應用到observer的路由，也有observer之間的路由。

③數(shù)據(jù)拆成一個個分區(qū)，每個分區(qū)做paxos復制，保證強一致，主分區(qū)宕機不可用會自動切換到備分區(qū)。

④checkpoint時間改變，將checkpoint周期拉長為1天，所有交易都落在內(nèi)存，然后每天夜里去刷一次盤，redo日志實時記錄，這樣避免了隨機寫的性能損耗，只有順序寫，更像內(nèi)存數(shù)據(jù)庫，性能更好，這樣也帶來一些問題，比如宕機后恢復時間變長，還有查詢剛剛做的修改需要先查基礎數(shù)據(jù)，再去應用redo條目，得到最新數(shù)據(jù)。

⑤兩階段提交并不使用ob proxy節(jié)點充當協(xié)調(diào)者，而是將ob proxy路由到的第一個主數(shù)據(jù)分區(qū)作為協(xié)調(diào)者，同時兩階段提交的prepare和commit等信息會進行持久化，如果寫協(xié)調(diào)節(jié)點宕機，那么備分區(qū)會啟用，同時讀取持久化信息，這個設計和一般的分布式數(shù)據(jù)庫不太一樣。

⑥集群維護一個partition cache，分區(qū)的分布信息會通過ob proxy在不同ob server間傳遞。

⑦ob最早的時候曾經(jīng)開源過一段時間，隨后基于它也誕生了cbase、obase這些產(chǎn)品。

3.GaussDB

華為GaussDB分為三個產(chǎn)品線，Gauss100前身是華為自研的內(nèi)存數(shù)據(jù)庫gmdb，目前已經(jīng)開源，Gauss200是基于pgxc架構研發(fā)的OLAP分析型數(shù)據(jù)庫，Gauss300是在200的基礎上繼續(xù)研發(fā)的HTAP數(shù)據(jù)庫，這里主要介紹Gauss300數(shù)據(jù)庫，Gauss300就是上圖中典型的架構：

①協(xié)調(diào)節(jié)點負責sql解析、轉發(fā)的同時也充當了兩階段提交的協(xié)調(diào)者的角色，協(xié)調(diào)節(jié)點上面存儲有部分元數(shù)據(jù)信息，元數(shù)據(jù)需要在多個協(xié)調(diào)節(jié)點之間進行同步，如果協(xié)調(diào)節(jié)點宕機，會影響ddl相關操作，還可能造成兩階段提交的殘留信息，需要有兩階段殘留清理機制。

②數(shù)據(jù)節(jié)點通過quorum-based流復制實現(xiàn)高可用，主備數(shù)據(jù)節(jié)點是實例級別的，一個主節(jié)點就是一個主PG實例，一臺機器可以有多個主數(shù)據(jù)節(jié)點。

③GTM復制分配全局事務id，GTM一主多備，GTM主備之間要同步gxid信息，而且是強同步，那么帶來一個問題，備GTM節(jié)點宕機會造成主GTM不可用，造成全局可用性問題，這塊華為將GTM的高可用轉移到etcd中，將GTM生成的xid寫入到etcd中，etcd自身就是一個高可用強一致的集群，這樣就保證了GTM的高可用，主GTM宕機那么備GTM會接替，然后繼續(xù)從etcd集群中讀寫事務號。

④GTM的事務號是批量分配的，如果在高并發(fā)的情況下，gxid如果一條一條分配則會有性能瓶頸，華為將事務號改為一次分配幾萬甚至幾十萬，避免了GTM事務號分配的瓶頸。

⑤事務id由32位改為64位。PG的事務號是32位的，最大到42億，所以事務號在PG中是很珍貴的資源，用完了就會循環(huán)使用，循環(huán)使用會帶來很多嚴重問題，華為將事務號由32位改為了64位，這樣事務號根本不可能用盡，那么一次分配幾十萬也不足為奇了。

⑥為了提升性能，華為也正在研發(fā)gtm-lite功能，該功能可以實現(xiàn)本地事務不走GTM，因為生產(chǎn)環(huán)境大部分是本地事務，因而能大大提升性能。

⑦Gauss300是基于pgxc架構演進而來的，類似基于pgxc的還有亞信AntDB、騰訊TBase。

4.SequoiaDB

SequoiaDB是巨杉自主研發(fā)的分布式數(shù)據(jù)庫，最初的應用場景主要是歷史數(shù)據(jù)歸檔和非結構化數(shù)據(jù)存檔，但是近期來巨杉也在積極開發(fā)oltp功能，包括研發(fā)GTM，支持MySQL協(xié)議等。下面介紹一下它的架構特點：

①包括協(xié)調(diào)節(jié)點、編目節(jié)點、數(shù)據(jù)節(jié)點、PG節(jié)點等。協(xié)調(diào)節(jié)點負責sql轉發(fā)，編目節(jié)點存儲元數(shù)據(jù)，數(shù)據(jù)節(jié)點存儲真實數(shù)據(jù)，PG節(jié)點做sql引擎。

②巨杉數(shù)據(jù)庫底層存儲是NoSQL的，數(shù)據(jù)都是JSON格式進行存儲，優(yōu)點類似MongoDB。

③PG節(jié)點是將PG Server拿過來做sql存儲引擎，支持sql語法，在PG上創(chuàng)建外表，同時創(chuàng)建外部服務器，存取巨杉中的數(shù)據(jù)，近期也支持了MySQL，將巨杉作為可插拔的存儲引擎嵌入到MySQL中。

④目前巨杉用作交易類場景其實不多，現(xiàn)在最大的一個應用案例是某大行一百多物理節(jié)點的巨杉集群，用作數(shù)據(jù)歸檔和影像管理。

⑤巨杉底層是多模存儲引擎，既支持結構化數(shù)據(jù)，也支持非結構化數(shù)據(jù)，實現(xiàn)了統(tǒng)一管理。

當然還有很多分布式數(shù)據(jù)庫，像達夢、人大金倉、南大通用、萬里開源、中興等企業(yè)都有分布式數(shù)據(jù)庫產(chǎn)品，這里不再一一介紹了。

作者介紹：

張小海，就職于某大型商業(yè)銀行，目前主要負責數(shù)據(jù)庫管理及新技術研究，PostgreSQL技術推廣者，個人公眾號：數(shù)據(jù)庫架構之美。

【51CTO原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為51CTO.com】