數據庫作為基礎軟件中的重要一環有著很深的技術含量，在這樣的大背景下國產數據庫廠商開始發力，這其中分布式數據庫如雨后春筍般出現，良性的競爭環境使它們都得到了長足的發展，其中不乏優秀的產品，本文主要挑選目前幾個相對成熟數據庫進行架構特點介紹。
作者：張小海來源：51CTO
【51CTO.com原創稿件】行業背景
隨著全球經濟下行壓力增大，中美貿易摩擦愈演愈烈，美國一系列的經濟制裁和技術封鎖使得我們有種被扼住咽喉的感覺，數據庫作為基礎軟件中的重要一環有著很深的技術含量，在這樣的大背景下國產數據庫廠商開始發力，這其中分布式數據庫如雨后春筍般出現，良性的競爭環境使它們都得到了長足的發展，其中不乏優秀的產品，本文主要挑選目前幾個相對成熟數據庫進行架構特點介紹。
分布式數據庫總體架構
分布式數據庫總體設計有兩個思路和方向，一個是基于共享存儲的架構(share everything)，另一個是基于數據分片的架構(share nothing)。
共享存儲的架構特點是底層存儲共用一份數據池子，上層數據庫server層可以彈性擴展，典型的案例像DB2 pureScale，Oracle RAC，阿里云PolarDB等，這種架構的好處是天然適合做云數據庫，比如阿里云，上層的SQL引擎可以是MySQL也可以是PG，而且可以無限擴展，底層的存儲其實是一起的，用戶申請只是申請幾個上層的MySQL或者PG server同時在底層存儲開辟一塊空間給用戶，這樣的話可以做到資源的彈性伸縮。這種架構的數據庫嚴格意義上不能稱之為分布式數據庫。
數據分片架構的特點是底層數據通過一定的規則比如hash或者range讓數據打散分別分布到不同的數據節點上，計算時底層多個節點共同參與計算，可以算是一種mpp并行計算的架構，同時數據節點可以擴展，上層由協調節點進行SQL解析和轉發，這是目前典型的分布式數據庫架構，也是本文討論的重點。
目前分布式數據庫的總體架構設計基本都和下圖相差不大，每種產品在不同組件的實現上存在差異，但大體架構上類似。
從圖中可以看到分布式數據庫三大組件：協調節點、數據節點、全局事務管理器。協調節點負責SQL解析轉發，充當的是類似proxy的角色，數據節點負責計算和數據存儲，全局事務管理器負責全局事務讀一致性的保證。
下面分別介紹一下目前主流的分布式數據庫的架構以及設計差異。
1.TiDB
TiDB是目前在互聯網界風靡的一款分布式數據庫，由PingCAP公司研發，由三大組件構成，底層TiKV Server是Github開源組件，是一個分布式的kv存儲引擎，做數據存儲，對應數據節點;上層TiDB Server由PingCAP公司研發，用作SQL解析和轉發，對應協調節點;PD Server復制全局時間戳分配，對應全局事務管理器。下面列舉了它的架構特點：
①輕量化，深受互聯網公司喜愛，適合與容器進行集成，當前PingCAP公司也在做TiDB operator，將TiDB容器化。
②部署簡便，基于Ansible Playbook實現自動化部署。
③實現了基于Region級別的raft復制，將數據表拆分成一個個的Region，Region一主兩備基于raft協議做復制，同時Region還會根據負載情況進行合并和分裂，由PD Server進行負載均衡調度。
④使用隱藏列作為分布列，分布列不占用真實列，這樣在進行數據修改時數據不需要進行重分布，大致原理是使用表名和主鍵前面加上前綴信息作為隱藏列，再使用該列進行hash分布。
⑤TiDB Server總體兼容MySQL語法，這個兼容并不是將MySQL Server直接拿過來使用，因為TiKV底層是kv的存儲模型，所以TiDB在執行sql的時候需要做sql到kv的映射。
⑥TiKV可以看成一個大的數據池子，在物理機層面不存在哪個機器是主，哪個是備，所有機器都是主節點，熱點數據會自動進行動態負載均衡，數據是動態移動的。
⑦總體借鑒了Google spanner f1和bigtable的論文，PD Server實現了邏輯上的時間戳，谷歌論文也提出了原子鐘的概念，從物理上保證事務號全局有序。
2.OceanBase
OceanBase是螞蟻金服自研的分布式數據庫，號稱代碼從第一行完全自研。最近ob也屢屢刷新新聞頭條，刷榜TPCC官網測試結果，刷新天貓交易額和tps記錄，不過金融行業比如銀行的應用案例并不多，也許是銀行和支付寶可能天然有鴻溝吧。ob架構比較特殊，下面介紹一下它的架構特點：
①最底層是ob server，每個ob server集成了總控服務、sql引擎、存儲引擎和數據分區。
②上層是ob proxy，實現sql的路由，這個不止是應用到observer的路由，也有observer之間的路由。
③數據拆成一個個分區，每個分區做paxos復制，保證強一致，主分區宕機不可用會自動切換到備分區。
④checkpoint時間改變，將checkpoint周期拉長為1天，所有交易都落在內存，然后每天夜里去刷一次盤，redo日志實時記錄，這樣避免了隨機寫的性能損耗，只有順序寫，更像內存數據庫，性能更好，這樣也帶來一些問題，比如宕機后恢復時間變長，還有查詢剛剛做的修改需要先查基礎數據，再去應用redo條目，得到最新數據。
⑤兩階段提交并不使用ob proxy節點充當協調者，而是將ob proxy路由到的第一個主數據分區作為協調者，同時兩階段提交的prepare和commit等信息會進行持久化，如果寫協調節點宕機，那么備分區會啟用，同時讀取持久化信息，這個設計和一般的分布式數據庫不太一樣。
⑥集群維護一個partition cache，分區的分布信息會通過ob proxy在不同ob server間傳遞。
⑦ob最早的時候曾經開源過一段時間，隨后基于它也誕生了cbase、obase這些產品。
3.GaussDB
華為GaussDB分為三個產品線，Gauss100前身是華為自研的內存數據庫gmdb，目前已經開源，Gauss200是基于pgxc架構研發的OLAP分析型數據庫，Gauss300是在200的基礎上繼續研發的HTAP數據庫，這里主要介紹Gauss300數據庫，Gauss300就是上圖中典型的架構：
①協調節點負責sql解析、轉發的同時也充當了兩階段提交的協調者的角色，協調節點上面存儲有部分元數據信息，元數據需要在多個協調節點之間進行同步，如果協調節點宕機，會影響ddl相關操作，還可能造成兩階段提交的殘留信息，需要有兩階段殘留清理機制。
②數據節點通過quorum-based流復制實現高可用，主備數據節點是實例級別的，一個主節點就是一個主PG實例，一臺機器可以有多個主數據節點。
③GTM復制分配全局事務id，GTM一主多備，GTM主備之間要同步gxid信息，而且是強同步，那么帶來一個問題，備GTM節點宕機會造成主GTM不可用，造成全局可用性問題，這塊華為將GTM的高可用轉移到etcd中，將GTM生成的xid寫入到etcd中，etcd自身就是一個高可用強一致的集群，這樣就保證了GTM的高可用，主GTM宕機那么備GTM會接替，然后繼續從etcd集群中讀寫事務號。
④GTM的事務號是批量分配的，如果在高并發的情況下，gxid如果一條一條分配則會有性能瓶頸，華為將事務號改為一次分配幾萬甚至幾十萬，避免了GTM事務號分配的瓶頸。
⑤事務id由32位改為64位。PG的事務號是32位的，最大到42億，所以事務號在PG中是很珍貴的資源，用完了就會循環使用，循環使用會帶來很多嚴重問題，華為將事務號由32位改為了64位，這樣事務號根本不可能用盡，那么一次分配幾十萬也不足為奇了。
⑥為了提升性能，華為也正在研發gtm-lite功能，該功能可以實現本地事務不走GTM，因為生產環境大部分是本地事務，因而能大大提升性能。
⑦Gauss300是基于pgxc架構演進而來的，類似基于pgxc的還有亞信AntDB、騰訊TBase。
4.SequoiaDB
SequoiaDB是巨杉自主研發的分布式數據庫，最初的應用場景主要是歷史數據歸檔和非結構化數據存檔，但是近期來巨杉也在積極開發oltp功能，包括研發GTM，支持MySQL協議等。下面介紹一下它的架構特點：
①包括協調節點、編目節點、數據節點、PG節點等。協調節點負責sql轉發，編目節點存儲元數據，數據節點存儲真實數據，PG節點做sql引擎。
②巨杉數據庫底層存儲是NoSQL的，數據都是JSON格式進行存儲，優點類似MongoDB。
③PG節點是將PG Server拿過來做sql存儲引擎，支持sql語法，在PG上創建外表，同時創建外部服務器，存取巨杉中的數據，近期也支持了MySQL，將巨杉作為可插拔的存儲引擎嵌入到MySQL中。
④目前巨杉用作交易類場景其實不多，現在最大的一個應用案例是某大行一百多物理節點的巨杉集群，用作數據歸檔和影像管理。
⑤巨杉底層是多模存儲引擎，既支持結構化數據，也支持非結構化數據，實現了統一管理。
當然還有很多分布式數據庫，像達夢、人大金倉、南大通用、萬里開源、中興等企業都有分布式數據庫產品，這里不再一一介紹了。
作者介紹：
張小海，就職于某大型商業銀行，目前主要負責數據庫管理及新技術研究，PostgreSQL技術推廣者，個人公眾號：數據庫架構之美。
