TiDB是新興的NEWSQL數據庫，由國內的PINGCAP團隊研發。 有關于TiDB的架構、部署和運維，官方有中文的文檔，鏈接是： https://github.com/pingcap/docs-cn

官方還有另外一份文檔，講的是TiDB和TiKV的設計思想和技術細節，個人很喜歡，但是用英文寫的。這里提供該文檔的翻譯。 這個系列共三篇譯文： TiDB 官方設計文檔翻譯（一） TiDB 官方設計文檔翻譯（二） TiDB 官方設計文檔翻譯（三）

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

1 什么是TiDB

TiDB是一個分布式SQL數據庫，靈感來自Google的F1和Spanner。TiDB汲取了傳統RDBMS（譯者注：關系型數據庫）和NoSQL的優點。

2 為什么要重新做一個數據庫

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

3 做怎樣的數據庫

我們要做的NewSQL數據庫，必須有下面的功能： - 首先，支持SQL。我們用SQL很多年了，而且許多應用都是基于SQL的，棄之可惜，代價也太大； - 第二，必須有良好的伸縮性。只需要加入更多的機器，就可以增加性能或者實現負載均衡； - 第三，支持ACID事務，這是傳統的關系型數據庫最大的優點之一。有了強一致性保證，開發者可以用更少的代碼保證邏輯的正確； - 最后，滿足高可用，機器故障，甚至是整個數據中心宕機，都應該可以自動恢復。

總之，我們要做一個分布式、一致性、可伸縮的SQL數據庫，取名為TiDB。

4 如何設計？

現在我們弄清了要做一個怎樣的數據庫，下一步是如何設計、開發和測試。

接下來一節中，首先介紹如何設計TiDB，包括設計原則、架構和決策。

4.1 設計原則

在開始設計之前，必須清楚一些設計原則：

4.1.1 容災

首要的設計原則是建立一個數據不會丟失的數據庫。 為了確保數據的安全，我們發現多個副本是不夠的，我們仍然需要在SQL層和key-value層維護Binlog（二進制日志）。 當然，我們必須確保有一個備份，以防整個集群崩潰。

4.1.2 易于使用

第二個設計原則是關于可用性。 經過多年在不同的解決方案之間的權衡，我們完全意識到用戶的痛點。 因此，當我們設計一個數據庫時，我們將使它易于使用，并且應該沒有令人頭疼的分片鍵，沒有分區，沒有明確的手工本地索引或全局索引，并使讓系統伸縮對用戶完全透明。

4.1.3 跨平臺

這個數據庫還需要跨平臺。 數據庫可以在本地設備上運行。 下圖展示了TiDB運行在有20個節點的樹莓派集群。

它還可以支持流行的容器，如Docker。 我們正在與Kubernetes合作。 當然，它也可以在任何云平臺上運行，無論是公共的，私有的還是融合的。

4.1.4 社區和軟件生態

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

因此，總體來說，我們希望成為大型開源社區的一員，并愿意參與，貢獻和合作，一起構建偉大的開源產品。

4.2 低耦合 - 邏輯架構

下圖顯示了數據庫的邏輯架構。

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

對于TiKV，我們使用Raft協議來保證數據一致性和水平伸縮性。 Raft是一個一致性算法，在容錯和性能可以媲美Paxos。 我們從etcd移植了廣泛使用的實現方法，容易測試并且高度穩定。 稍后將介紹技術細節。

從架構中，你也能看到，并沒有分布式文件系統。我們使用RocksDB作為本地存儲。

4.3 替代方案

在接下來的幾節中，我將討論與Spanner和F1相比，使用替代技術的設計決策，以及這些替代方案的利弊。

4.3.1 原子鐘/ GPS時鐘 VS TimeStamp Allocator

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

我們選擇的第一種替代技術是用TimeStamp Allocator替換TrueTime API。 毫無疑問，實時性在分布式系統中至關重要。 但是我們能得到實時嗎？ 時鐘漂移怎么辦？

可悲的是，即使我們使用GPS或原子鐘，因為時鐘漂移，也不能得到完全準確的時間，

在TiDB中，我們沒有使用原子鐘和GPS時鐘。 我們使用Percolator（2006年Google發布的一篇文章）中引入的Timestamp Allocator。

使用Timestamp Allocator的優點是易于實現，并且不依賴于任何硬件。 缺點在于，如果存在多個數據中心，特別是如果這些數據中心跨地區分布，延遲會很高。

4.3.2 分布式文件系統 VS RocksDB

Spanner使用Colossus文件系統作為其分布式文件系統，Colossus是Google文件系統（GFS）的繼承者。 但是在TiKV中，我們不依賴于任何分布式文件系統。 我們使用RocksDB。 RocksDB是一個可嵌入的快速持久化鍵值存儲。 RocksDB的最大優點是其針對服務器工作負載的卓越性能。 很容易調整讀、寫和放大空間。 非常簡單、快速和容易調整。 但是，與Kubernetes協同工作并不容易。

4.3.3 Paxos VS Raft

下一個選擇是使用Raft一致性算法代替的Paxos。Raft的主要特點是：強有力的領導者，領導者選舉和成員的變化。 我們從etcd移植了Raft實現方法。 優點是易于理解和實現，廣泛使用并且便于測試。 至于缺點，目前還沒發現。

4.3.4 C ++ VS Go＆Rust

至于編程語言，TiDB使用Go語言，TiKV使用Rust。 我們選擇了Go，因為它對快速開發和并發非常有利，而Rust可以實現高質量和性能保障。 至于缺點，沒有那么多的第三方庫。

上文介紹了設計TiDB的過程中，使用替代技術的原則、架構和設計決策。 下一步是開發TiDB。

說明 如有轉載，請注明出處： http://blog.csdn.net/antony9118/article/details/60467256