干貨！PingCAP劉奇：如何構(gòu)建一個NewSQL數(shù)據(jù)庫

PingCAP 劉奇 NewSQL 數(shù)據(jù)庫

劉奇 | 2016-07-06 14:08

【數(shù)據(jù)猿導(dǎo)讀】近日，在香港主辦、開源社群主導(dǎo)的國際技術(shù)會議上，PingCAP 聯(lián)合創(chuàng)始人兼CEO劉奇應(yīng)邀出席，與大家分享了《How to Build a NewSQL Database》的英文主題演講

干貨！PingCAP劉奇：如何構(gòu)建一個NewSQL數(shù)據(jù)庫

以下為他的演講實錄：

大家好，我是PingCAP CEO劉奇。今天我將和大家分享一下如何構(gòu)建一個NewSQL數(shù)據(jù)庫。

首先，來介紹下我自己。和你們當(dāng)中很多人一樣，我是一名開源Hacker，一名架構(gòu)工程師，并長期致力于創(chuàng)建新一代數(shù)據(jù)庫。我曾投身于以下幾個開源項目的工作，包括TiKV、TiDB 和Codis，這些項目都已在Github上發(fā)布。今天，我的演講將涉及下列話題：

簡要介紹NewSQL；如何建立一個NewSQL數(shù)據(jù)庫；以及roadmap。

為什么我們需要一個新的數(shù)據(jù)庫？

在正式開始前，我先問一個問題：你們熟悉數(shù)據(jù)庫嗎？熟悉的朋友請舉手。謝謝！

另外，有誰知道MySQL嗎？謝謝，比我預(yù)期的人數(shù)要少一些。

那么，現(xiàn)有數(shù)據(jù)庫存在哪些問題呢？

像MySQL、Oracle、PostgreSQL這樣的關(guān)系數(shù)據(jù)庫，它們的問題是很難擴展。盡管我們有分片技術(shù)，還有youtube/vitess和MySQL proxy等,但它們都不支持分布式事務(wù)以及cross-node join連接。

像HBase、 MongoDB以及Redis這樣的NoSQL數(shù)據(jù)庫：它們可擴展，但不支持SQL，同時也舍棄了事務(wù)的一致性。

因此，新一代數(shù)據(jù)庫將會是怎樣的？在我看來，其主要特征應(yīng)該是：

支持SQL；

具有可擴展性；

支持事務(wù)執(zhí)行四要素/ACID Transaction；

高可用。

首先，它必須支持SQL，因為這數(shù)十年來我們一直在使用SQL，而且許多應(yīng)用程序都使用SQL，故而不能輕易將其舍棄。

第二，必須有良好的擴展性，也就是說只需通過接入更多的機器就可以擴展其容量或使之實現(xiàn)負載均衡。

第三，必須支持事務(wù)的ACID屬性，這一點也恰恰是關(guān)系數(shù)據(jù)庫的主要特征之一。有了強大的一致性作保障，開發(fā)者便可以用較短的代碼編寫出正確的程序。

最后，即使是在計算機陷入故障，甚至是整個數(shù)據(jù)中心癱瘓的情況下，它也應(yīng)該能夠保持其較高的可用性。同時，它還應(yīng)當(dāng)可以自動修復(fù)。

總之，新一代數(shù)據(jù)庫應(yīng)該既有很好的可擴展性，又能保留關(guān)系數(shù)據(jù)庫的主要特征。

NewSQL是什么?

你可能會好奇，這樣的數(shù)據(jù)庫真的存在嗎？它聽起來似乎太過完美和理想化了。這個問題的答案是肯定的，這樣的數(shù)據(jù)庫的確存在，它就是NewSQL。那什么是NewSQL數(shù)據(jù)庫？先來看一看維基百科給出的解釋：

NewSQL是指這樣一類新式的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，它針對OLTP實現(xiàn)讀-寫工作負載，追求提供和NoSQL系統(tǒng)相同的擴展性能，且仍然保持傳統(tǒng)數(shù)據(jù)庫支持的ACID特性。

從上述定義來看，我們不難發(fā)現(xiàn)NewSQL的擴展性與NoSQL相當(dāng)，并同時保留了ACID特性。而這恰恰是我們需要的。

建立一個NewSQL數(shù)據(jù)庫

今天我將向大家展示如何建立一個這樣的數(shù)據(jù)庫。我們受到全球最大數(shù)據(jù)庫Google Spanner 和 F1 的啟發(fā)，將其分為兩個層級：

KV層：這一層屬于底層存儲系統(tǒng)，負責(zé)提供跨數(shù)據(jù)中心的同步以及強一致性事務(wù)。

SQL層：這一層使能夠滿足我們對傳統(tǒng)SQL數(shù)據(jù)庫可用性以及功能性的支持。

建立NewSQL數(shù)據(jù)庫

這就是我們在PingCAP所從事的工作，當(dāng)然是開源的。其中，我們的數(shù)據(jù)庫分為兩層，即KV層和SQL層。就KV層來看，我們有TiKV；對于SQL層，則有TiDB。而我將在稍后介紹其中的關(guān)鍵技術(shù)。這里的Ti是Titanium（鈦）的縮寫，我們都知道鈦作為一種抗腐蝕性的化學(xué)元素，被廣泛應(yīng)用于高端科技當(dāng)中。

TiKV的特性

異地備份：我們利用Raft來支持異地備份。Raft是一種一致性算法，它在容錯性和性能方面相當(dāng)于Paxos算法。我們的實現(xiàn)參考應(yīng)用廣泛的etcd，它已經(jīng)通過了廣泛測試并具有較高的穩(wěn)定性。

水平擴展性：由于Raft支持 membership 變更，我們利用其這一特性來實現(xiàn)水平擴展。

一致性的分布式事務(wù)：這種事務(wù)模型的創(chuàng)建是受到了 Google Percolator（來自一篇2006發(fā)表的論文）的啟發(fā)，主要是一個優(yōu)化的兩階段提交協(xié)議。該模型借助一個時間戳分配器來給各項事務(wù)分配單調(diào)遞增的時間戳，因此可檢測到?jīng)_突。

協(xié)處理器支持：與 HBase 類似，我們運用協(xié)處理器架構(gòu)執(zhí)行服務(wù)器代碼來進行分布式計算。

追求更高的性能和更低的延遲，用編程語言 Rust 進行了編寫。你們當(dāng)中有誰知道 Rust 嗎？很不錯。你們應(yīng)該嘗試一下，它真的相當(dāng)有趣。

TiKV架構(gòu)

從上圖中可以看出，它經(jīng)過了高度分層。

從底層往上看。底層是RocksDB，它是一個持久的內(nèi)嵌式KV存儲引擎。RocksDB的最初設(shè)計重點在于其極高的性能，可以輕松對讀放大、寫放大以及空間放大進行優(yōu)化。

上面一層是Raft KV，這一層用來實現(xiàn)分布式。

再往上是MVCC，即多版本并發(fā)控制（Multi-version concurrency control）。我相信你們當(dāng)中很多人對此都很熟悉。TiKV是一個多版本數(shù)據(jù)庫，而MVCC則支持我們的無鎖讀以及事務(wù)的ACID屬性。

接下來的事務(wù)（Transaction）層，我之前已經(jīng)介紹過了。

然后是KV API，這是一組程序接口，它允許開發(fā)者對數(shù)據(jù)的輸入和輸出。

同樣，協(xié)處理器（Coprocesser）在前面也提過了。

最后是Placement Driver，這是一個尤為重要的部分，因為它可協(xié)助進行異地備份，水平擴展以及一致性的分布式事務(wù)。稍后我將對其細節(jié)進行進一步補充。

TiKV 軟件棧

讓我們來看一下軟件棧。首先，我們會發(fā)現(xiàn)客戶端與TiKV相連。同時我們還能看見幾個Node。而在每個Node當(dāng)中都有Store，每一個物理磁盤存一個store。在每個 Store 當(dāng)中，我們又劃出許多Region。而Region是數(shù)據(jù)遷移的基本單位，并且經(jīng)由Raft備份。每個Region都被同步到多個節(jié)點。一個 Raft group 由一個 Region 的數(shù)個備份組成。如你所見，每個 Region 在三個不同的節(jié)點上有三個備份。

驅(qū)動程序配置

PD，又稱 placement driver，這一名稱來源自Spanner的原文。它是集群管理器，提供了該集群的上帝視角。它由兩個部分構(gòu)成：rebalancer和timestamp allocator。PD對Region副本進行周期性檢測，平衡負載，并自動處理數(shù)據(jù)遷移。當(dāng)它檢測到負載過高時，將會重新平衡數(shù)據(jù)。

TiDB

以TiKV為基礎(chǔ)的NewSQL：它將TiKV轉(zhuǎn)變成了一個NewSQL數(shù)據(jù)庫。

異步schema改變：你可以在不停止也不影響正在進行的操作的前提下，添加新的列以及索引。本質(zhì)上看，它是一個多階段協(xié)議。

與MySQL協(xié)議兼容：TiDB服務(wù)器遵從MySQL協(xié)議，并且遵循其SQL語法。換句話說就是在大多情況下，你能夠在不更改任何一行代碼的同時，通過用TiDB替換MySQL來增強你的應(yīng)用。TiDB適用于MySQL應(yīng)用和管理工具，比phpMyAdmin、Navicat以及WordPress。同時，很多ORM也可以在TiDB上很好的工作，例如Hibernate、GORM、ActiveRecord、SQLAlchemy等。

TiDB的架構(gòu)

讓我們來看一下TiDB的架構(gòu)：

MySQL客戶端：頂層是一組MySQL客戶端，這些客戶端向下一層發(fā)送請求。在這里你仍然可以使用你所熟悉的MySQL驅(qū)動程序。

負載平衡器：這一層屬于可選層，例如HAProxy 以及 LVS。

TiDB服務(wù)器：它是無狀態(tài)的，一個客戶端可以同任何一個TiDB服務(wù)器相連接。在TiDB服務(wù)器內(nèi)部，最頂層提供MySQL協(xié)議支持；下一層是SQL Plan層，往往被用以將MySQL請求轉(zhuǎn)換成TiDB SQL Plan；底層則是KV API以及分布式SQL API。如果較底層的存儲引擎支持協(xié)處理器，TiDB SQL層將會使用比KV API更為高效的DistSQL API。TiDB支持插件式存儲引擎，早期支持HBase。同時作為試驗性存儲引擎，我們還支持CockroachDB。但我們推薦TiKV為默認存儲引擎。

TiDB如何使SQL與KV相匹配

讓我們用一個例子來展示一個SQL 表是如何映射成KV對的。

假設(shè)我們的數(shù)據(jù)庫里有一張簡單的用戶表。它有一行三列：nickname、email和age。此處的nickname類型是字符串，且nickname是主鍵。

nickname email age bob bob@gmail.com 30

如果我們映射這張表到KV對，Key就分成了三個部分：table、row key、column。而這時的KV對排列如下：

Key (table/row key/column) Value user/bob/nickname nil user/bob/email bob@gmail.com user/bob/age 30

現(xiàn)在，我們得到了一個典型的SQL statement：按用戶名bob篩選email和age；如果映射為KV操作的話，則表達如下：

email = kv.Get( ” user/bob/email ” )

age = kv.Get( ” user/bob/age ” )

這就是在一個使用字符串的通用KV數(shù)據(jù)庫中的存儲方式。在TiDB內(nèi)部，每個表，每一列都有一個唯一的ID。所以TiDB使用表ID以及列ID來取代字符串。因此在TiDB中，表id是1，nickname列id為2，email列id為3，age列id則為4，而這一TiDB表顯示如下：

Key (table id/row id/column id) Value 1/bob/2 nil 1/bob/3 bob@gmail.com 1/bob/4 30

以上就是我今天演講的全部內(nèi)容。謝謝大家。

來源：CSDN大數(shù)據(jù)

收藏分享

聲明：數(shù)據(jù)猿尊重媒體行業(yè)規(guī)范，相關(guān)內(nèi)容都會注明來源與作者；轉(zhuǎn)載我們原創(chuàng)內(nèi)容時，也請務(wù)必注明“來源：數(shù)據(jù)猿”與作者名稱，否則將會受到數(shù)據(jù)猿追責(zé)。