TiDB是新興的NEWSQL數(shù)據(jù)庫(kù)，由國(guó)內(nèi)的PINGCAP團(tuán)隊(duì)研發(fā)。 有關(guān)于TiDB的架構(gòu)、部署和運(yùn)維，官方有中文的文檔，鏈接是： https://github.com/pingcap/docs-cn

官方還有另外一份文檔，講的是TiDB和TiKV的設(shè)計(jì)思想和技術(shù)細(xì)節(jié)，個(gè)人很喜歡，但是用英文寫(xiě)的。這里提供該文檔的翻譯。 這個(gè)系列共三篇譯文： TiDB 官方設(shè)計(jì)文檔翻譯（一） TiDB 官方設(shè)計(jì)文檔翻譯（二） TiDB 官方設(shè)計(jì)文檔翻譯（三）

原文： https://pingcap.github.io/blog/2016/10/17/how-we-build-tidb/

1 什么是TiDB

TiDB是一個(gè)分布式SQL數(shù)據(jù)庫(kù)，靈感來(lái)自Google的F1和Spanner。TiDB汲取了傳統(tǒng)RDBMS（譯者注：關(guān)系型數(shù)據(jù)庫(kù)）和NoSQL的優(yōu)點(diǎn)。

2 為什么要重新做一個(gè)數(shù)據(jù)庫(kù)

在開(kāi)始介紹之前，我們回到原點(diǎn)，問(wèn)自己一個(gè)問(wèn)題：為什么要重新做一個(gè)數(shù)據(jù)庫(kù)。我們都知道，已經(jīng)有很多成熟的數(shù)據(jù)庫(kù)了，例如傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)和NoSQL。為什么我們不采用這些方案？ - 關(guān)系型數(shù)據(jù)庫(kù)，例如MySQL，Oracle，PostgreSQL等，伸縮性很差。盡管我們可以有分片的解決方案，例如Youtube的vitness，MySQL代理，但是他們都不能滿足分布式事務(wù)和跨節(jié)點(diǎn)的連接（join）。 - NoSQL，例如HBase，Mongo DB和Cassandra，伸縮性不錯(cuò)，但是不支持SQL和一致性事務(wù)。 - NewSQL，代表是Google Spanner和F1，和NoSQL系統(tǒng)一樣具有良好的伸縮性，也保留了ACID事務(wù)。這才是我們所需要的。受到Google Spanner和F1的啟發(fā)，我們決定做一款開(kāi)源的NewSQL數(shù)據(jù)庫(kù)。

3 做怎樣的數(shù)據(jù)庫(kù)

我們要做的NewSQL數(shù)據(jù)庫(kù)，必須有下面的功能： - 首先，支持SQL。我們用SQL很多年了，而且許多應(yīng)用都是基于SQL的，棄之可惜，代價(jià)也太大； - 第二，必須有良好的伸縮性。只需要加入更多的機(jī)器，就可以增加性能或者實(shí)現(xiàn)負(fù)載均衡； - 第三，支持ACID事務(wù)，這是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)最大的優(yōu)點(diǎn)之一。有了強(qiáng)一致性保證，開(kāi)發(fā)者可以用更少的代碼保證邏輯的正確； - 最后，滿足高可用，機(jī)器故障，甚至是整個(gè)數(shù)據(jù)中心宕機(jī)，都應(yīng)該可以自動(dòng)恢復(fù)。

總之，我們要做一個(gè)分布式、一致性、可伸縮的SQL數(shù)據(jù)庫(kù)，取名為TiDB。

4 如何設(shè)計(jì)？

現(xiàn)在我們弄清了要做一個(gè)怎樣的數(shù)據(jù)庫(kù)，下一步是如何設(shè)計(jì)、開(kāi)發(fā)和測(cè)試。

接下來(lái)一節(jié)中，首先介紹如何設(shè)計(jì)TiDB，包括設(shè)計(jì)原則、架構(gòu)和決策。

4.1 設(shè)計(jì)原則

在開(kāi)始設(shè)計(jì)之前，必須清楚一些設(shè)計(jì)原則：

4.1.1 容災(zāi)

首要的設(shè)計(jì)原則是建立一個(gè)數(shù)據(jù)不會(huì)丟失的數(shù)據(jù)庫(kù)。 為了確保數(shù)據(jù)的安全，我們發(fā)現(xiàn)多個(gè)副本是不夠的，我們?nèi)匀恍枰赟QL層和key-value層維護(hù)Binlog（二進(jìn)制日志）。 當(dāng)然，我們必須確保有一個(gè)備份，以防整個(gè)集群崩潰。

4.1.2 易于使用

第二個(gè)設(shè)計(jì)原則是關(guān)于可用性。 經(jīng)過(guò)多年在不同的解決方案之間的權(quán)衡，我們完全意識(shí)到用戶的痛點(diǎn)。 因此，當(dāng)我們?cè)O(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)時(shí)，我們將使它易于使用，并且應(yīng)該沒(méi)有令人頭疼的分片鍵，沒(méi)有分區(qū)，沒(méi)有明確的手工本地索引或全局索引，并使讓系統(tǒng)伸縮對(duì)用戶完全透明。

4.1.3 跨平臺(tái)

這個(gè)數(shù)據(jù)庫(kù)還需要跨平臺(tái)。 數(shù)據(jù)庫(kù)可以在本地設(shè)備上運(yùn)行。 下圖展示了TiDB運(yùn)行在有20個(gè)節(jié)點(diǎn)的樹(shù)莓派集群。

它還可以支持流行的容器，如Docker。 我們正在與Kubernetes合作。 當(dāng)然，它也可以在任何云平臺(tái)上運(yùn)行，無(wú)論是公共的，私有的還是融合的。

4.1.4 社區(qū)和軟件生態(tài)

下一個(gè)設(shè)計(jì)原則是關(guān)于社區(qū)和軟件生態(tài)。 我們想站在巨人的肩膀上，而不是創(chuàng)造出全新的令人陌生的產(chǎn)品。 TiDB支持MySQL協(xié)議，與大多數(shù)MySQL驅(qū)動(dòng)程序（ODBC，JDBC）、SQL語(yǔ)法、MySQL客戶端、ORM、下列MySQL管理和bench工具兼容。 - etcd——etcd是一個(gè)偉大的項(xiàng)目。 在我們的鍵值存儲(chǔ)TiKV中（后面會(huì)詳細(xì)介紹），我們一直與etcd團(tuán)隊(duì)密切合作。 我們共享Raft實(shí)現(xiàn)，并且互相進(jìn)行Raft模塊代碼審查； - RocksDB——RocksDB也是一個(gè)偉大的項(xiàng)目。 成熟，快速，可調(diào)諧，并廣泛應(yīng)用于大規(guī)模的生產(chǎn)環(huán)境，尤其在Facebook。 TiKV使用RocksDB作為本地存儲(chǔ)。 當(dāng)我們?cè)谙到y(tǒng)中測(cè)試時(shí)，發(fā)現(xiàn)了RocksDB的一些bug。 RocksDB團(tuán)隊(duì)后來(lái)很快地修復(fù)了； - Namazu——幾個(gè)月前，我們需要一個(gè)工具來(lái)模擬速度慢而且不穩(wěn)定的磁盤(pán)，團(tuán)隊(duì)成員發(fā)現(xiàn)了Namazu。 但是那時(shí)候，Namazu不支持hooking fsync。 當(dāng)團(tuán)隊(duì)成員將此請(qǐng)求提交給Namazu的團(tuán)隊(duì)時(shí)，他們立即回復(fù)并在短短幾個(gè)小時(shí)內(nèi)實(shí)現(xiàn)該功能，他們也非常愿意實(shí)現(xiàn)其他功能。 我們對(duì)他們的反饋速度和效率印象深刻； - Rust社區(qū)——Rust社區(qū)是驚人的。 除了使用Rust的良好開(kāi)發(fā)經(jīng)驗(yàn)之外，我們還在Rust中構(gòu)建了PRometheus驅(qū)動(dòng)程序以收集指標(biāo)。我們很高興成為這個(gè)大家庭的一部分。 非常感謝Rust團(tuán)隊(duì)，gRPC，Prometheus和Grafana。 - spark連接器。我們?cè)赥iDB中使用Spark連接器。 TiDB非常適合小型或中型查詢，Spark更適合具有大量數(shù)據(jù)的復(fù)雜查詢。 我們相信我們也可以從Spark社區(qū)學(xué)到很多，當(dāng)然我們希望盡可能多地貢獻(xiàn)。

因此，總體來(lái)說(shuō)，我們希望成為大型開(kāi)源社區(qū)的一員，并愿意參與，貢獻(xiàn)和合作，一起構(gòu)建偉大的開(kāi)源產(chǎn)品。

4.2 低耦合 - 邏輯架構(gòu)

下圖顯示了數(shù)據(jù)庫(kù)的邏輯架構(gòu)。

正如我前面提到的設(shè)計(jì)原則，我們采用松耦合方法。 從圖中我們可以看出TiDB是高度分層的。 我們有TiDB作為MySQL服務(wù)器，TiKV作為分布式Key-Value層。 TiDB內(nèi)部，分為MySQL Server層和SQL層。 在TiKV內(nèi)部，分為事務(wù)，MVCC，Raft和本地鍵值存儲(chǔ)（RocksDB）。

對(duì)于TiKV，我們使用Raft協(xié)議來(lái)保證數(shù)據(jù)一致性和水平伸縮性。 Raft是一個(gè)一致性算法，在容錯(cuò)和性能可以媲美Paxos。 我們從etcd移植了廣泛使用的實(shí)現(xiàn)方法，容易測(cè)試并且高度穩(wěn)定。 稍后將介紹技術(shù)細(xì)節(jié)。

從架構(gòu)中，你也能看到，并沒(méi)有分布式文件系統(tǒng)。我們使用RocksDB作為本地存儲(chǔ)。

4.3 替代方案

在接下來(lái)的幾節(jié)中，我將討論與Spanner和F1相比，使用替代技術(shù)的設(shè)計(jì)決策，以及這些替代方案的利弊。

4.3.1 原子鐘/ GPS時(shí)鐘 VS TimeStamp Allocator

如果閱讀過(guò)Spanner論文，你可能知道Spanner有TrueTime API，它使用原子鐘和GPS接收器來(lái)保持不同數(shù)據(jù)中心之間的時(shí)間一致。

我們選擇的第一種替代技術(shù)是用TimeStamp Allocator替換TrueTime API。 毫無(wú)疑問(wèn)，實(shí)時(shí)性在分布式系統(tǒng)中至關(guān)重要。 但是我們能得到實(shí)時(shí)嗎？ 時(shí)鐘漂移怎么辦？

可悲的是，即使我們使用GPS或原子鐘，因?yàn)闀r(shí)鐘漂移，也不能得到完全準(zhǔn)確的時(shí)間，

在TiDB中，我們沒(méi)有使用原子鐘和GPS時(shí)鐘。 我們使用Percolator（2006年Google發(fā)布的一篇文章）中引入的Timestamp Allocator。

使用Timestamp Allocator的優(yōu)點(diǎn)是易于實(shí)現(xiàn)，并且不依賴于任何硬件。 缺點(diǎn)在于，如果存在多個(gè)數(shù)據(jù)中心，特別是如果這些數(shù)據(jù)中心跨地區(qū)分布，延遲會(huì)很高。

4.3.2 分布式文件系統(tǒng) VS RocksDB

Spanner使用Colossus文件系統(tǒng)作為其分布式文件系統(tǒng)，Colossus是Google文件系統(tǒng)（GFS）的繼承者。 但是在TiKV中，我們不依賴于任何分布式文件系統(tǒng)。 我們使用RocksDB。 RocksDB是一個(gè)可嵌入的快速持久化鍵值存儲(chǔ)。 RocksDB的最大優(yōu)點(diǎn)是其針對(duì)服務(wù)器工作負(fù)載的卓越性能。 很容易調(diào)整讀、寫(xiě)和放大空間。 非常簡(jiǎn)單、快速和容易調(diào)整。 但是，與Kubernetes協(xié)同工作并不容易。

4.3.3 Paxos VS Raft

下一個(gè)選擇是使用Raft一致性算法代替的Paxos。Raft的主要特點(diǎn)是：強(qiáng)有力的領(lǐng)導(dǎo)者，領(lǐng)導(dǎo)者選舉和成員的變化。 我們從etcd移植了Raft實(shí)現(xiàn)方法。 優(yōu)點(diǎn)是易于理解和實(shí)現(xiàn)，廣泛使用并且便于測(cè)試。 至于缺點(diǎn)，目前還沒(méi)發(fā)現(xiàn)。

4.3.4 C ++ VS Go＆Rust

至于編程語(yǔ)言，TiDB使用Go語(yǔ)言，TiKV使用Rust。 我們選擇了Go，因?yàn)樗鼘?duì)快速開(kāi)發(fā)和并發(fā)非常有利，而Rust可以實(shí)現(xiàn)高質(zhì)量和性能保障。 至于缺點(diǎn)，沒(méi)有那么多的第三方庫(kù)。

上文介紹了設(shè)計(jì)TiDB的過(guò)程中，使用替代技術(shù)的原則、架構(gòu)和設(shè)計(jì)決策。 下一步是開(kāi)發(fā)TiDB。

說(shuō)明 如有轉(zhuǎn)載，請(qǐng)注明出處： http://blog.csdn.net/antony9118/article/details/60467256