帶你遨游銀河系的 10 種分布式數(shù)據(jù)庫
大家好，我是悟空。
上一篇講到了 MySQL 和 NoSQL 的區(qū)別和優(yōu)缺點：
這次我們來聊下分布式場景下的數(shù)據(jù)庫。
首先我們還是來看下關系型和非關系型的數(shù)據(jù)庫的區(qū)別和特點。
一、關系型 vs 非關系型
1.1 關系型
1.1.1 什么是關系型?
關系型數(shù)據(jù)庫指的是使用關系模型(二維表格模型)來組織數(shù)據(jù)的數(shù)據(jù)庫，由二維表及其之間的聯(lián)系所組成的一個數(shù)據(jù)組織。
1.1.2 常見關系型數(shù)據(jù)庫
常見關系型數(shù)據(jù)庫管理系統(tǒng)(ORDBMS)：Oracle、MySql、Microsoft SQL Server、SQLite、PostgreSQ、IBM DB2。
1.1.3 關系型的優(yōu)勢
- 采用二維表結構非常貼近正常開發(fā)邏輯。
- 支持通用的SQL(結構化查詢語言)語句。
- 豐富的完整性大大減少了數(shù)據(jù)冗余和數(shù)據(jù)不一致的問題。
- 可以用SQL句子多個表之間做非常繁雜的查詢;
- 關系型數(shù)據(jù)庫提供對事務的支持。
1.1.4 關系型的不足之處
(1)存儲的是行記錄。
不能存儲數(shù)組、嵌套字段等格式的數(shù)據(jù)。
(2)擴展表結構不方便。
操作不存在的列會報錯，而增加列又需要執(zhí)行 SQL 語句才行。而且修改時需要特別注意，因為更新表時會長時間鎖表，這對線上環(huán)境可能造成嚴重影響。
(3)占用內(nèi)存高。
關系型數(shù)據(jù)庫在對大量數(shù)據(jù)的表進行統(tǒng)計之類的運算時，占用內(nèi)存會很高，因為它即使只針對某一列進行運算，也會將整行數(shù)據(jù)從存儲設備讀入內(nèi)存。
(4)全文搜索性能差
類似于 MySQL 的關系型數(shù)據(jù)庫，只能用 like 進行整表掃描的匹配，效率很低。現(xiàn)如今，有很多場景需要支持模糊匹配，而且必須支持高效查找。比如查詢包含關鍵字的日志信息，又或者是根據(jù)某個商品關鍵字查詢商品列表。
1.2 非關系型
1.2.1 什么是非關系型?
NoSQL
NoSQL(NoSQL = Not Only SQL )，意即"不僅僅是SQL"。
非關系型數(shù)據(jù)庫嚴格上不是一種數(shù)據(jù)庫，應該是一種數(shù)據(jù)結構化存儲方法的集合，可以是文檔或者鍵值對等。
1.2.2 常見非關系型數(shù)據(jù)庫
- 鍵值數(shù)據(jù)庫：Redis、Memcached、Riak。
- 列式數(shù)據(jù)庫：Bigtable、HBase、Cassandra。
- 文檔數(shù)據(jù)庫：MongoDB、CouchDB、MarkLogic。
- 圖形數(shù)據(jù)庫：Neo4j、InfoGrid。
1.2.3 非關系型的優(yōu)勢
- 格式靈活：存儲數(shù)據(jù)的格式可以是key,value形式、文檔形式、圖片形式等等，文檔形式、圖片形式等等，使用靈活，應用場景廣泛，而關系型數(shù)據(jù)庫則只支持基礎類型。
- 速度快：NoSQL 可以使用硬盤或者內(nèi)存來存儲，而關系型數(shù)據(jù)庫只能使用硬盤;
- 高擴展性;
- 成本低：nosql數(shù)據(jù)庫部署簡單，基本都是開源軟件。
1.2.4 非關系型的不足之處
- 不提供sql支持，學習和使用成本較高;
- 無事務處理。MongoDB 4.0 已支持事務。
- 數(shù)據(jù)結構相對復雜，復雜查詢方面稍欠。
二、分布式數(shù)據(jù)庫
2.1 分布式數(shù)據(jù)庫的定義
分布式數(shù)據(jù)庫其實沒有一個官方的定義，只是我們技術人員提出的一個約定俗成的說法。
在數(shù)據(jù)庫領域，當產(chǎn)品不斷演進逐漸被大家認識和認可后，就會成了一個標準，比如說微軟的 SQL Server 數(shù)據(jù)庫，其他數(shù)據(jù)庫都喜歡拿它作為對比，那 SQL Server 數(shù)據(jù)庫就會成為一個標準。
但是分布式數(shù)據(jù)庫也是最近幾年才被大家提出，還是比較新的，也沒有參照。不過我們可以通過這些大廠大牛們總結的經(jīng)驗來認識分布式數(shù)據(jù)庫。
分布式數(shù)據(jù)庫就是用分布式架構實現(xiàn)的數(shù)據(jù)庫。
2.2 分布式數(shù)據(jù)庫的優(yōu)勢
分布式一直是我研究的一個話題，現(xiàn)在很多流行的技術都用上了分布式架構，比如微服務、消息隊列。
那為什么我們要用分布式架構呢?簡單來說，就是用多機(機器)來橫向擴展單機的性能，另外一個很重要的原因就是分布式的可靠性，比如多機備份、容災等。
那數(shù)據(jù)庫是不是也需要提升性能和保證可靠性呢?答案是肯定的。
哪些大廠在用分布式數(shù)據(jù)庫?
每年雙 11，阿里就喜歡 show 一波交易戰(zhàn)績，其分布式數(shù)據(jù)庫 OceanBase 功不可沒。頭部大廠如騰訊、字節(jié)跳動、美團也開始使用分布式數(shù)據(jù)庫，還有各大銀行也上線了分布式數(shù)據(jù)庫。
所以說分布式數(shù)據(jù)庫是一種趨勢，如果業(yè)務場景要求高性能和高可靠，就可以考慮使用分布式架構下的數(shù)據(jù)庫了。
2.3 分布式數(shù)據(jù)庫的特點
首先我們來看下數(shù)據(jù)庫按照交易類型區(qū)分的兩大場景：
- 聯(lián)機交易(OLTP)
OLTP 是面向交易的處理過程，單筆交易的數(shù)據(jù)量小，但是要在很短的時間內(nèi)給出結果，典型場景包括購物、繳費、轉(zhuǎn)賬等;
- 聯(lián)機分析(OLAP)
OLAP 場景通常是基于大數(shù)據(jù)集的運算，典型場景包括生成個人年度賬單和企業(yè)財務報表等。
OLTP 的特點是寫多讀少、低延時、高并發(fā)，那么數(shù)據(jù)庫+分布式在 OLTP 場景下會具有哪些特點呢?
特點：
- 在寫多讀少的場景很強大。
- 低延時的響應。
- 支持高并發(fā)。
- 支持海量存儲。
- 高可靠性。
三、10 種分布式數(shù)據(jù)庫
3.1 PingCAP 的 TiDB
開源 + 良好的社區(qū)運營，擁有超高人氣。
定義：是一款同時支持在線事務處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP)的融合型分布式數(shù)據(jù)庫產(chǎn)品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、云原生的分布式數(shù)據(jù)庫、兼容 MySQL 5.7 協(xié)議和 MySQL 生態(tài)等重要特性。目標是為用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數(shù)據(jù)規(guī)模較大等各種應用場景。
TiDB 架構圖
TIDB 采用分層架構，有三種角色：
- TIDB：作為 SQL 引擎。
- TiKV：作為底層分布式鍵值存儲。
- PD：承擔元數(shù)據(jù)管理和全局時鐘的職責。
TiDB 的衍生項目：
- Ti-Binlog、Ti-CDC 支持數(shù)據(jù)導出。
- Ti-Operator 更方便地實現(xiàn)容器云部署。
- Chaos Mesh 支持混沌工程。
缺點：不支持全球化部署，這為跨地域大規(guī)模集群應用 TiDB 設置了障礙。
3.2 Google 的 Spanner
Spanner是谷歌公司研發(fā)的、可擴展的、多版本、全球分布式、同步復制數(shù)據(jù)庫。它支持外部一致性的分布式事務。
Spanner 架構，來自 Google 論文
F1 主要作為 SQL 引擎
Spanner 主要負責事務一致性、復制機制、可擴展存儲等。
Spanner 架構中的核心處理模塊是 Spanserver，
Spanner 的架構，來自 Google 論文
Spanserver 的核心工作有三部分：
基于 Paxos 協(xié)議的數(shù)據(jù)復制。Paxos 協(xié)議可以看我之前寫的一篇文章：《用三國殺講分布式算法，舒適了吧?》
基于 Tablet 的分片管理。
基于 2PC 的事務一致性管理。2PC 協(xié)議可以看我之前寫的一篇文章：《用太極拳講分布式理論，真舒服!》
2017 年，F(xiàn)1 和 Spanner 被拆分了，不再是綁定關系。原理如如下：
來自 Google 論文
3.3 CockroachDB 蟑螂數(shù)據(jù)庫
CockroachDB (蟑螂數(shù)據(jù)庫)是一個可伸縮的、支持地理位置處理、支持事務處理的數(shù)據(jù)存儲系統(tǒng)。
為什么叫做蟑螂?
因為這個數(shù)據(jù)庫只要損壞的節(jié)點不超過總數(shù)一半，那么集群仍然可以正常工作，生命力超強。
通過分布式一致性算法實例來調(diào)節(jié)確保一致性，它所選擇使用Raft一致性算法。所有的一致性狀態(tài)存在于RocksDB中。
Cockroach 是一個分布式的 SQL 數(shù)據(jù)庫。首要設計目標就是 可擴展性，強一致性，可存活性，就像它的名字一樣。Cockroach 的目標是在無人工干預的情況下，以極小的中斷時間容忍磁盤，主機，機架甚至 數(shù)據(jù)中心災難 。Cockroach 的節(jié)點是對等的，其中一個設計目標是以最少配置加無依賴，部署去中心化的對等節(jié)點。中文社區(qū)地址：cockroachdb-cn。
CockroachDB 提供兩種不同的的事務特性，包括快照隔離(snapshot isolation，簡稱SI)和順序的快照隔離(SSI)語義，后者是默認的隔離級別。
CockroachDB 是一個分布式的K/V數(shù)據(jù)倉庫，支持ACID事務，多版本值存儲是其首要特性。主要的設計目標是全球一致性和可靠性，從蟑螂的命名上是就能看出這點。蟑螂數(shù)據(jù)庫能處理磁盤、物理機器、機架甚至數(shù)據(jù)中心失效情況下最小延遲的服務中斷;整個失效過程無需人工干預。蟑螂的節(jié)點是均衡的，其設計目標是同質(zhì)部署(只有一個二進制包)且最小配置。
CockroachDB 和 TiDB、YugabyteDB 都公開聲稱設計靈感來自 Spanner，所以往往會被認為是同構的產(chǎn)品。CockroachDB 和 TiDB，經(jīng)常會被大家拿來比較。
區(qū)別：
- CockroachDB 采用了標準的 P2P 架構，只要損壞的節(jié)點不超過總數(shù)一半，那么集群仍然可以正常工作。
- CockroachDB 支持全球化部署，因為它采用了混合邏輯時鐘(HLC)，所以能夠在全球物理范圍下做到數(shù)據(jù)一致性。
- 分片管理機制的不同。
3.4 YugabyteDB
在架構上和 CockroachDB 有很多相似之處，比如支持全球化部署，采用混合邏輯時鐘(HLC)，基于 Percolator 的事務模型，兼容 PostgreSQL 協(xié)議。
由于高度的相似性，YugabyteDB 與 CockroachDB 的競爭表現(xiàn)得非常激烈。
Yugabyte 采用兩層架構：查詢層和存儲層。不過這個架構僅僅是邏輯上的，部署結構中，這兩層都位于 TServer 進程中。這一點和 TiDB 不同。
Yugabyte 的查詢層支持同時 SQL 和 CQL 兩種 API，其中 CQL 是兼容 Cassandra 的一種方言語法，對應于文檔數(shù)據(jù)庫的存儲模型;而 SQL API 是直接基于 PostgresQL 魔改的，能比較好地兼容 PG 語法，
Yugabyte 的存儲層才是重頭戲。其中 TServer 負責存儲 tablet，每個 tablet 對應一個 Raft Group，分布在三個不同的節(jié)點上，以此保證高可用性。Master 負責元數(shù)據(jù)管理，除了 tablet 的位置信息，還包括表結構等信息。Master 本身也依靠 Raft 實現(xiàn)高可用。
YugabyteDB 架構
3.5 阿里OceanBase
OceanBase是由螞蟻集團完全自主研發(fā)的金融級分布式關系數(shù)據(jù)庫，始創(chuàng)于2010年。OceanBase具有數(shù)據(jù)強一致、高可用、高性能、在線擴展、高度兼容SQL標準和主流關系數(shù)據(jù)庫、低成本等特點。
3.6 騰訊的 TDSQL
TDSQL 的節(jié)點都是用的 MySQL。它是采用分布式集群架構(如下圖)，這種集群架構具有較高的靈活性，簡化了各個 節(jié)點之間的通信機制，也簡化了對于硬件的需求。這不僅意味著 TDSQL 的關系型實例、分 布式實例、分析性實例可以混合部署在同一集群中，也意味著即使是簡單的 x86 服務器，也 可以搭建出類似于小型機、共享存儲等一樣穩(wěn)定可靠的數(shù)據(jù)庫。
TDSL 架構
3.7 中興通訊的 GoldenDB
GoldenDB 幾乎是國內(nèi)銀行業(yè)應用規(guī)模最大的分布式數(shù)據(jù)庫，和 TDSQL 同樣在數(shù)據(jù)節(jié)點上選擇了 MySQL，但全局時鐘節(jié)點的增加使它稱為一個標準的 PGXC 架構。
3.8 騰訊的 TBase
TBase 是騰訊數(shù)據(jù)平臺團隊在開源的 PostgreSQL 基礎上研發(fā)的企業(yè)級分布式 HTAP 數(shù)據(jù)庫管理系統(tǒng)：
- 具備高性能可擴展的分布式事務能力，支持 RC 和 RR 兩種隔離級別;
- 通過安全、管理、審計三權分立體系，提供全方位的數(shù)據(jù)安全保證機制;
- 支持高性能分區(qū)表，可使得數(shù)據(jù)檢索效率成倍提升;
- SQL 方面兼容 2003 標準、PostgreSQL 語法和常用 Oracle 函數(shù)&數(shù)據(jù)類型、窗口函數(shù)等;
- 提供大小商戶數(shù)據(jù)分離、冷熱數(shù)據(jù)分離等高效的數(shù)據(jù)治理能力
集群中有三種節(jié)點類型，各自承擔不同的功能，通過網(wǎng)絡連接成為一個系統(tǒng)。這三種節(jié)點類型分別是：
- **Coordinator：**協(xié)調(diào)節(jié)點，對外提供接口，負責數(shù)據(jù)的分發(fā)和查詢規(guī)劃，多個節(jié)點位置對等，每個節(jié)點都提供相同的數(shù)據(jù)庫視圖，CN 存儲系統(tǒng)的全局元數(shù)據(jù)。
- **Datanode：**處理存儲本節(jié)點相關的元數(shù)據(jù)，每個節(jié)點還存儲數(shù)據(jù)的一個分片。在功能上，DN 節(jié)點負責完成執(zhí)行協(xié)調(diào)節(jié)點分發(fā)的執(zhí)行請求。
- GTM: 全局事務管理器(Global transaction manager.)，負責管理集群事務信息，同時管理集群的全局對象，比如序列，除此之外 GTM 上不提供其他的功能。
3.9 VoltDB
VoltDB 官網(wǎng)提供的簡介：VoltDB是全球最快的內(nèi)存型數(shù)據(jù)庫，它繼承了傳統(tǒng)關系數(shù)據(jù)庫的強一致性要求，又提供了互聯(lián)網(wǎng)云上部署的能力和分布式 數(shù)據(jù)庫的橫向擴展能力。VoltDB通過將數(shù)據(jù)庫全部保存在內(nèi)存中的方法，消除了大量的數(shù)據(jù)和日志的磁盤存取操作，通過單線程的方式，消除了磁盤鎖和記錄鎖;通過數(shù)據(jù)庫分片技術，讓數(shù)據(jù)庫支持高并發(fā)請求;通過分布式集群支持數(shù)據(jù)庫橫向擴展。其查詢速度達到傳統(tǒng)數(shù)據(jù)庫的100倍以上。
2019 年正式閉源，變?yōu)榧兩虡I(yè)化產(chǎn)品。而同時，VoltDB 在國內(nèi)也沒有建立完備的服務支持體系，這在很大程度上影響到它的推廣。
3.10 巨杉 SequoiaDB
SequoiaDB 巨杉數(shù)據(jù)庫是一款開源的金融級分布式關系型數(shù)據(jù)庫，主要面對高并發(fā)聯(lián)機交易型場景提供高性能、可靠穩(wěn)定以及無限水平擴展的數(shù)據(jù)庫服務。
邏輯架構
用戶可以在 SequoiaDB 巨杉數(shù)據(jù)庫中創(chuàng)建多種類型的數(shù)據(jù)庫實例，以滿足上層不同應用程序各自的需求。
SequoiaDB 巨杉數(shù)據(jù)庫支持 MySQL、PostgreSQL、SparkSQL 和 MariaDB 四種關系型數(shù)據(jù)庫實例、類 MongoDB 的 JSON 文檔類數(shù)據(jù)庫實例、以及 S3 對象存儲與 POSIX 文件系統(tǒng)的非結構化數(shù)據(jù)實例。
支持七種不同的實例類型
SequoiaDB 巨杉數(shù)據(jù)庫存儲引擎采用分布式架構。集群中的每個節(jié)點為一個獨立進程，節(jié)點之間采用 TCP/IP 協(xié)議進行通訊。
同一個操作系統(tǒng)可以部署多個節(jié)點，節(jié)點之間采用不同的端口進行區(qū)分。
數(shù)據(jù)庫存儲引擎邏輯架構
好了，對于分布式數(shù)據(jù)庫，如果你也有分布式數(shù)據(jù)庫的使用經(jīng)驗，歡迎留言～
參考資料：
https://docs.pingcap.com/zh/tidb/stable
http://vldb.org/pvldb/vol11/p1835-samwel.pdf
http://ericfu.me/yugabyte-db-introduction/
https://blog.csdn.net/duan_zhihua/article/details/88549173
https://www.voltdb.com/
https://www.zhihu.com/question/24225007/answer/1707736658
https://www.zhihu.com/question/24225007/answer/1326259742
https://time.geekbang.org/column/article/296558
本文轉(zhuǎn)載自微信公眾號「悟空聊架構」，可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系悟空聊架構公眾號。
