帶你遨遊銀河系的 10 種分佈式數據庫

回覆分佈式領取資料 node

這是悟空的第 107 篇原創文章
web

做者 | 悟空聊架構算法

來源 | 悟空聊架構（ID：PassJava666）sql

轉載請聯繫受權（微信ID：PassJava）

你們好，我是悟空。數據庫

上一篇講到了 MySQL 和 NoSQL 的區別和優缺點：數組

《有了 MySQL，爲何要用 NoSQL》安全

此次咱們來聊下分佈式場景下的數據庫。服務器

首先咱們仍是來看下關係型和非關係型的數據庫的區別和特色。微信

1、關係型 vs 非關係型

1.1 關係型

1.1.1 什麼是關係型？

關係型數據庫指的是使用關係模型（二維表格模型）來組織數據的數據庫，由二維表及其之間的聯繫所組成的一個數據組織。網絡

1.1.2 常見關係型數據庫

常見關係型數據庫管理系統（ORDBMS）：Oracle、MySql、Microsoft SQL Server、SQLite、PostgreSQ、IBM DB2。

1.1.3 關係型的優點

採用二維表結構很是貼近正常開發邏輯。
支持通用的SQL（結構化查詢語言）語句。
豐富的完整性大大減小了數據冗餘和數據不一致的問題。
能夠用SQL句子多個表之間作很是繁雜的查詢；
關係型數據庫提供對事務的支持。

1.1.4 關係型的不足之處

（1）存儲的是行記錄。

不能存儲數組、嵌套字段等格式的數據。

（2）擴展表結構不方便。

操做不存在的列會報錯，而增長列又須要執行 SQL 語句才行。並且修改時須要特別注意，由於更新表時會長時間鎖表，這對線上環境可能形成嚴重影響。

（3）佔用內存高。

關係型數據庫在對大量數據的表進行統計之類的運算時，佔用內存會很高，由於它即便只針對某一列進行運算，也會將整行數據從存儲設備讀入內存。

（4）全文搜索性能差

相似於 MySQL 的關係型數據庫，只能用 like 進行整表掃描的匹配，效率很低。現現在，有不少場景須要支持模糊匹配，並且必須支持高效查找。好比查詢包含關鍵字的日誌信息，又或者是根據某個商品關鍵字查詢商品列表。

1.2 非關係型

1.2.1 什麼是非關係型？

NoSQL(NoSQL = Not Only SQL )，意即"不只僅是SQL"。

非關係型數據庫嚴格上不是一種數據庫，應該是一種數據結構化存儲方法的集合，能夠是文檔或者鍵值對等。

1.2.2 常見非關係型數據庫

鍵值數據庫：Redis、Memcached、Riak。
列式數據庫：Bigtable、HBase、Cassandra。
文檔數據庫：MongoDB、CouchDB、MarkLogic。
圖形數據庫：Neo4j、InfoGrid。

1.2.3 非關係型的優點

格式靈活：存儲數據的格式能夠是key,value形式、文檔形式、圖片形式等等，文檔形式、圖片形式等等，使用靈活，應用場景普遍，而關係型數據庫則只支持基礎類型。
速度快：NoSQL 可使用硬盤或者內存來存儲，而關係型數據庫只能使用硬盤；
高擴展性；
成本低：nosql數據庫部署簡單，基本都是開源軟件。

1.2.4 非關係型的不足之處

不提供sql支持，學習和使用成本較高；
無事務處理。MongoDB 4.0 已支持事務。
數據結構相對複雜，複雜查詢方面稍欠。

2、分佈式數據庫

2.1 分佈式數據庫的定義

分佈式數據庫其實沒有一個官方的定義，只是咱們技術人員提出的一個約定俗成的說法。

在數據庫領域，當產品不斷演進逐漸被你們認識和承認後，就會成了一個標準，好比說微軟的 SQL Server 數據庫，其餘數據庫都喜歡拿它做爲對比，那 SQL Server 數據庫就會成爲一個標準。

可是分佈式數據庫也是最近幾年才被你們提出，仍是比較新的，也沒有參照。不過咱們能夠經過這些大廠大牛們總結的經驗來認識分佈式數據庫。

分佈式數據庫就是用分佈式架構實現的數據庫。

2.2 分佈式數據庫的優點

分佈式一直是我研究的一個話題，如今不少流行的技術都用上了分佈式架構，好比微服務、消息隊列。

那爲何咱們要用分佈式架構呢？簡單來講，就是用多機（機器）來橫向擴展單機的性能，另一個很重要的緣由就是分佈式的可靠性，好比多機備份、容災等。

那數據庫是否是也須要提高性能和保證可靠性呢？答案是確定的。

哪些大廠在用分佈式數據庫？

每一年雙 11，阿里就喜歡 show 一波交易戰績，其分佈式數據庫 OceanBase 功不可沒。頭部大廠如騰訊、字節跳動、美團也開始使用分佈式數據庫，還有各大銀行也上線了分佈式數據庫。

因此說分佈式數據庫是一種趨勢，若是業務場景要求高性能和高可靠，就能夠考慮使用分佈式架構下的數據庫了。

2.3 分佈式數據庫的特色

首先咱們來看下數據庫按照交易類型區分的兩大場景：

聯機交易（OLTP）

OLTP 是面向交易的處理過程，單筆交易的數據量小，可是要在很短的時間內給出結果，典型場景包括購物、繳費、轉帳等；
聯機分析（OLAP）

OLAP 場景一般是基於大數據集的運算，典型場景包括生成我的年度帳單和企業財務報表等。

OLTP 的特色是寫多讀少、低延時、高併發，那麼數據庫+分佈式在 OLTP 場景下會具備哪些特色呢？

特色：

在寫多讀少的場景很強大。
低延時的響應。
支持高併發。
支持海量存儲。
高可靠性。

3、10 種分佈式數據庫

3.1 PingCAP 的 TiDB

開源 + 良好的社區運營，擁有超高人氣。

定義：是一款同時支持在線事務處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分佈式數據庫產品，具有水平擴容或者縮容、金融級高可用、實時 HTAP、雲原生的分佈式數據庫、兼容 MySQL 5.7 協議和 MySQL 生態等重要特性。目標是爲用戶提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解決方案。TiDB 適合高可用、強一致要求較高、數據規模較大等各類應用場景。

TIDB 採用分層架構，有三種角色：

TIDB：做爲 SQL 引擎。
TiKV：做爲底層分佈式鍵值存儲。
PD：承擔元數據管理和全局時鐘的職責。

TiDB 的衍生項目：

Ti-Binlog、Ti-CDC 支持數據導出。
Ti-Operator 更方便地實現容器雲部署。
Chaos Mesh 支持混沌工程。

缺點：不支持全球化部署，這爲跨地域大規模集羣應用 TiDB 設置了障礙。

3.2 Google 的 Spanner

Spanner是谷歌公司研發的、可擴展的、多版本、全球分佈式、同步複製數據庫。它支持外部一致性的分佈式事務。

F1 主要做爲 SQL 引擎

Spanner 主要負責事務一致性、複製機制、可擴展存儲等。

Spanner 架構中的核心處理模塊是 Spanserver，

Spanserver 的核心工做有三部分：

基於 Paxos 協議的數據複製。Paxos 協議能夠看我以前寫的一篇文章：《用三國殺講分佈式算法，溫馨了吧？》
基於 Tablet 的分片管理。
基於 2PC 的事務一致性管理。2PC 協議能夠看我以前寫的一篇文章：《用太極拳講分佈式理論，真舒服！》

2017 年，F1 和 Spanner 被拆分了，再也不是綁定關係。原理如以下：

3.3 CockroachDB 蟑螂數據庫

CockroachDB (蟑螂數據庫）是一個可伸縮的、支持地理位置處理、支持事務處理的數據存儲系統。

爲何叫作蟑螂？

由於這個數據庫只要損壞的節點不超過總數一半，那麼集羣仍然能夠正常工做，生命力超強。

經過分佈式一致性算法實例來調節確保一致性，它所選擇使用Raft一致性算法。全部的一致性狀態存在於RocksDB中。

Cockroach 是一個分佈式的 SQL 數據庫。首要設計目標就是 可擴展性，強一致性，可存活性，就像它的名字同樣。Cockroach 的目標是在無人工干預的狀況下，以極小的中斷時間容忍磁盤，主機，機架甚至 數據中心災難 。Cockroach 的節點是對等的，其中一個設計目標是以最少配置加無依賴，部署去中心化的對等節點。中文社區地址：cockroachdb-cn。

CockroachDB 提供兩種不一樣的的事務特性，包括快照隔離（snapshot isolation，簡稱SI）和順序的快照隔離（SSI）語義，後者是默認的隔離級別。

CockroachDB 是一個分佈式的K/V數據倉庫，支持ACID事務，多版本值存儲是其首要特性。主要的設計目標是全球一致性和可靠性，從蟑螂的命名上是就能看出這點。蟑螂數據庫能處理磁盤、物理機器、機架甚至數據中心失效狀況下最小延遲的服務中斷；整個失效過程無需人工干預。蟑螂的節點是均衡的，其設計目標是同質部署（只有一個二進制包）且最小配置。

CockroachDB 和 TiDB、YugabyteDB 都公開聲稱設計靈感來自 Spanner，因此每每會被認爲是同構的產品。CockroachDB 和 TiDB，常常會被你們拿來比較。

區別：

CockroachDB 採用了標準的 P2P 架構，只要損壞的節點不超過總數一半，那麼集羣仍然能夠正常工做。
CockroachDB 支持全球化部署，由於它採用了混合邏輯時鐘（HLC），因此可以在全球物理範圍下作到數據一致性。
分片管理機制的不一樣。

3.4 YugabyteDB

在架構上和 CockroachDB 有不少類似之處，好比支持全球化部署，採用混合邏輯時鐘（HLC），基於 Percolator 的事務模型，兼容 PostgreSQL 協議。

因爲高度的類似性，YugabyteDB 與 CockroachDB 的競爭表現得很是激烈。

Yugabyte 採用兩層架構：查詢層和存儲層。不過這個架構僅僅是邏輯上的，部署結構中，這兩層都位於 TServer 進程中。這一點和 TiDB 不一樣。

Yugabyte 的查詢層支持同時 SQL 和 CQL 兩種 API，其中 CQL 是兼容 Cassandra 的一種方言語法，對應於文檔數據庫的存儲模型；而 SQL API 是直接基於 PostgresQL 魔改的，能比較好地兼容 PG 語法，

Yugabyte 的存儲層纔是重頭戲。其中 TServer 負責存儲 tablet，每一個 tablet 對應一個 Raft Group，分佈在三個不一樣的節點上，以此保證高可用性。Master 負責元數據管理，除了 tablet 的位置信息，還包括表結構等信息。Master 自己也依靠 Raft 實現高可用。

3.5 阿里OceanBase

OceanBase是由螞蟻集團徹底自主研發的金融級分佈式關係數據庫，始創於2010年。OceanBase具備數據強一致、高可用、高性能、在線擴展、高度兼容SQL標準和主流關係數據庫、低成本等特色。

3.6 騰訊的 TDSQL

TDSQL 的節點都是用的 MySQL。它是採用分佈式集羣架構（以下圖），這種集羣架構具備較高的靈活性，簡化了各個節點之間的通訊機制，也簡化了對於硬件的需求。這不只意味着 TDSQL 的關係型實例、分布式實例、分析性實例能夠混合部署在同一集羣中，也意味着即便是簡單的 x86 服務器，也能夠搭建出相似於小型機、共享存儲等同樣穩定可靠的數據庫。

3.7 中興通信的 GoldenDB

GoldenDB 幾乎是國內銀行業應用規模最大的分佈式數據庫，和 TDSQL 一樣在數據節點上選擇了 MySQL，但全局時鐘節點的增長使它稱爲一個標準的 PGXC 架構。

3.8 騰訊的 TBase

TBase 是騰訊數據平臺團隊在開源的 PostgreSQL 基礎上研發的企業級分佈式 HTAP 數據庫管理系統：

具有高性能可擴展的分佈式事務能力，支持 RC 和 RR 兩種隔離級別；
經過安全、管理、審計三權分立體系，提供全方位的數據安全保證機制；
支持高性能分區表，可以使得數據檢索效率成倍提高；
SQL 方面兼容 2003 標準、PostgreSQL 語法和經常使用 Oracle 函數&數據類型、窗口函數等；
提供大小商戶數據分離、冷熱數據分離等高效的數據治理能力

集羣中有三種節點類型，各自承擔不一樣的功能，經過網絡鏈接成爲一個系統。這三種節點類型分別是：

**Coordinator：**協調節點，對外提供接口，負責數據的分發和查詢規劃，多個節點位置對等，每一個節點都提供相同的數據庫視圖，CN 存儲系統的全局元數據。
**Datanode：**處理存儲本節點相關的元數據，每一個節點還存儲數據的一個分片。在功能上，DN 節點負責完成執行協調節點分發的執行請求。
GTM: 全局事務管理器(Global transaction manager.)，負責管理集羣事務信息，同時管理集羣的全局對象，好比序列，除此以外 GTM 上不提供其餘的功能。

3.9 VoltDB

VoltDB 官網提供的簡介：VoltDB是全球最快的內存型數據庫，它繼承了傳統關係數據庫的強一致性要求，又提供了互聯網雲上部署的能力和分佈式數據庫的橫向擴展能力。VoltDB經過將數據庫所有保存在內存中的方法，消除了大量的數據和日誌的磁盤存取操做，經過單線程的方式，消除了磁盤鎖和記錄鎖；經過數據庫分片技術，讓數據庫支持高併發請求；經過分佈式集羣支持數據庫橫向擴展。其查詢速度達到傳統數據庫的100倍以上。

2019 年正式閉源，變爲純商業化產品。而同時，VoltDB 在國內也沒有創建完備的服務支持體系，這在很大程度上影響到它的推廣。