聊聊主流的分佈式數據庫

單體數據庫時代，隨着系統交易量的不斷上升，數據庫讀寫性能出現了嚴重下降。我們可以藉助分庫分表中間件，比如 mycat、shardingjdbc 來實現分庫分表，緩解單庫的讀寫性能。但是分庫分表中間件並不支持事務，如果要保證數據一致性，就需要藉助於分佈式事務中間件，比如阿里巴巴的 seata。後來分佈式數據庫逐漸成爲解決數據一致性的選擇，目前分佈式數據庫產品已經比較成熟，支持 ACID 事務，本文就來聊一聊分佈式數據庫。

增加代理層

以 mysql 爲例，我們來看一下單體數據庫的邏輯架構，如下圖：

從這個圖我們可以看到，mysql 包括連接器層，server 層，存儲引擎層和數據 / 文件層。單體數據庫場景下，數據庫本身就是支持事務的，我們不用事務做額外的工作。

如果需要分庫分表，這時架構就需要調整，如下圖：

這個架構增加了代理層，它的功能包括客戶端接入、簡單的查詢處理、進程管理和分片信息管理。這時因爲數據分佈在不同的切片上，使用的複雜性也大幅度增加。

如果應用要進行全量分頁查詢、關聯查詢、排序等應用，一個簡單的代理層是很難滿足的，代理層必須支持複雜的運算，這時就基本過度到分佈式數據庫了，而代理層也被叫做了協調節點。

協調節點增加了運算能力，但是要支持分佈式事務的一致性，還是遠遠不夠的。下面我們就看一下一致性問題。

一致性

在分佈式的 CAP 理論中，數據一致性是終極目標。我們來聊一下線性一致性和因果一致性。

先看線性一致性，如下圖：

user1 讀取足球比賽成績，比分 4:2,1 秒之後，user2 讀取比賽成績，但 user2 讀到的成績是 4:1，這樣後讀取的用戶讀取到的數據反而是舊的數據。

發生這個問題的原因就是多副本同步延遲，而線性一致性要解決的問題如下：

線性一致性是分佈式下最強的一致性理論，主流的數據庫產品解決線程一致性的手段是引入全局時鐘，用單點授時的方式，從這個單一節點獲取時間，而且必須保證單一時鐘節點的高可靠性。

線性一致性的問題是全局時鐘的併發問題，如果共用一個物理時鐘，性能必然受到影響。

如果我們在一致性和高性能之間做一個取捨，我們可以降低一些一致性來提高併發性能。這個理論就是因果一致性，它一致性要求低於線性一致性。因爲一致性的基礎是在數據庫的單一切片上，事件肯定是有先後順序的。在不同的切片上，需要通信的話，發送事件肯定早於接收事件。

基於因果一致性，引入了邏輯時鐘的概念。目前也有一些數據庫使用邏輯時鐘來實現因果一致性，雖然比線性一致性弱一些，但是性能更好。

NewSQL 架構

上面我們介紹了傳統關係型數據庫，增加了切片集羣，增加了協調節點，增加了全局時鐘，這樣就演變成了分佈式數據庫。如下圖：

這種數據庫架構被業內稱爲 PGXC 架構，這個名字是 PostgreSQL-XC 的簡稱，它是一種提供寫可靠性，多主節點數據同步，數據傳輸的開源集羣方案。

注意：這種架構被叫做 PGXC，並不是專指 PostgreSQL-XC 這種分佈式數據庫，而是文章上面講的架構風格的一類數據庫。

NewSQL 是由 NoSQL 鍵值數據庫發展而來，它是一類新的數據庫架構方案，不僅具有 NoSQL 對海量數據的存儲管理能力，還保持了傳統數據庫支持 ACID 和 SQL 等特性。它主要有以下特性：

PGXC 數據庫

PGXC 數據庫由傳統關係型數據庫基於分庫分表的技術演化而來，優點是性能比較穩定，缺點是寫入能力有限，這是由架構風格決定的。

我們來介紹幾款主流的 PGXC 數據庫，代表如下：

1.TBase

TBase 是騰訊數據平臺團隊在基於 PostgreSQL 研發的，支持 HTAP(Hybrid Transaction and Analytical Process)，主要由協調節點、數據節點和全局事務管理器 (GTM) 組成。特點如下：

分佈式事務支持 RC 和 RR 兩個隔離級別

支持高性能分區表，數據檢索效率高

SQL 語法兼容 SQL2003 標準、也支持 PostgreSQL 語法和 Oracle 主要語法

開源地址：

https://gitee.com/mirrors/tbase

2.GuassDB 300

GuassDB 300 由華爲研發，也是基於開源 PostgreSQL 研發的，支持 HTAP，支持 SQL92、SQL99 和 SQL2003 語法，並且支持提供存儲過程、觸發器、分頁等。目前在招商銀行、工商銀行和民生銀行有使用。

3.AntDB

由亞信科技開發，基於開源 PostgreSQL 內核研發的，主要特點是對 Oracle 兼容性高，分佈式事務支持 2PC 協議和 MVCC，集羣支持動態擴展。

開源地址：

https://gitee.com/adbsql/antdb

4.GoldenDB

由中興通訊研發，跟前面 3 款不一樣的是，這款數據庫以 mysql 爲內核構建的，按照官方的描述，這款數據庫對金融行業的支持比較好，目前中信銀行的核心業務系統有使用。

5.TDSQL

TDSQL 由騰訊研發，它算不上是完全的 PGXC 架構，因爲沒有全局時鐘。不過它也有自己解決一致性的方案，它的自增長序列爲用戶提供一個全局唯一數字 ID 服務，對全局鎖和 mvcc 都有一定的作用。

NewSQL 數據庫

NewSQL 數據庫有很大的架構上的優勢，但是首先難度也很大，我們來看一下目前主流的數據庫產品。

  1. 谷歌 Spanner

谷歌 Spanner 可以說是 NewSQL 數據庫的鼻祖，後來的好多數據庫都是借鑑了 Spanner 的思想。它有下面幾個特性：

使用 GPS 加原子鐘的方式來實現全局時鐘，這就就是引入了 true time，支持全球化部署

支持線性一致性

2.TiDB

TiDB 也是非常有名的一塊 NewSQL 數據庫，由 PingCAP 研發，支持 HTAP，支持線性一致性，一個亮點是兼容 mysql 協議和生態，github 地址如下：

https://github.com/pingcap

3.Ocean Base

螞蟻集團研發，按照官方說法，2020 年 5 月，OceanBase 以 7.07 億 tpmC 的在線事務處理性能，打破了去年自己創造的 TPC-C 世界紀錄。截止至目前，OceanBase 是第一個也是唯一一個上榜的中國數據庫。

雖然官方說 Ocean Base 高度兼容各種主流關係型數據庫，但是業界普遍認爲對 Oracle 兼容不太好。

採用 Paxos 分佈式選舉算法來實現高可用。

4.SequoiaDB

巨杉金融級分佈式數據庫，它具有如下特性：

完整支持分佈式事務、強一致、多副本高可用，滿足分佈式核心交易業務需求

支持 MySQL、PostgreSQL、SparkSQL 和 MariaDB 四種關係型數據庫實例，100% 兼容 MySQL 語法

支持 HTAP 混合事務 / 分析處理

目前在廣發、民生等金融機構有一定使用。

5.CockroachDB 和 YugabyteDB

這 2 個數據庫放在一起講的原因是它們不支持線性一致性，只支持因果一致性，因爲它們使用的是混合邏輯時鐘 (Hybrid Logical Clocks)，它們的設計思想都是來自 Spanner。

CockroachDB 採用了 Range 分區，每個 range 對應一個 RocksDB 數據庫，同時使用 raft 算法的改進算法 multi raft，讓多分片並行處理提升性能。

YugabyteDB 除了 NewSQL 的特性外，還支持文檔數據庫接口，查詢層支持同時 SQL 和 CQL 兩種 API，SQL API 是基於 postgreSQL 改的，所以對 postgreSQL 的支持非常好。

Aurora 數據庫

Aurora 數據庫是 amazon 推出的雲原生數據庫，它的特點是計算節點垂直擴展，存儲節點可以水平擴展。可見計算節點依然是單節點。Aurora 基於 mysql 引擎構建，100% 支持 mysql。

Aurora 數據緩存在主節點，然後同步到其他從節點，可見跟其他分佈式數據庫相比，從節點不支持寫入，所以不支持多寫，從節點只能分擔讀的壓力。

不過這也是一種風格，目前這個風格的數據庫有阿里的 polarDB，騰訊的 CynosDB 和華爲的 Taurus。

總結

傳統的分庫分表架構不斷演進，增加了協調節點，全局時鐘，就演變成了 PGXC 架構，這是主流分佈式數據庫的一個分支。

在基於 BigTable 鍵值數據庫的基礎上增加事務支持，就演變成了 NewSQL，是分佈式數據庫的另一個分支。

amazon 推出 Aurora 分佈式數據庫並不算是上面 2 種架構的一種，並沒有解決分佈式場景下的寫入壓力，但也是一種分佈式數據庫的風格。

分佈式數據庫的產品已經很成熟，數量也很多，需要結合業務特性來做技術選型。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/cJ2qUow9tQzAixRFzJkuew

猜你喜歡