講師介紹：申礫(VP of Engineering of PingCAP)

• 曾就職於網易有道、360搜尋，從事資訊檢索、資料探勘工作。
• 目前在PingCAP負責TiDB的技術，致力於開發下一代NewSQL資料庫。

主題簡介：

1.分散式資料庫的歷史和現狀

2.TiDB架構和特點

3.分散式資料庫未來趨勢

隨著大資料這個概念的興起以及真實需求在各個行業的落地，很多人都熱衷於討論分散式資料庫，今天就這個話題，主要分為三部分：第一部分講一下分散式資料庫的過去和現狀，希望大家能對這個領域有一個全面的瞭解；第二部分講一下TiDB的架構以及最近的一些進展；最後結合我們開發TiDB過程中的一些思考講一下分散式資料庫未來可能的趨勢。

一、分散式資料庫的歷史和現狀

1、從單機資料庫說起

關係型資料庫起源自1970年代，其最基本的功能有兩個：

1. 把資料存下來；
2. 滿足使用者對資料的計算需求。

第一點是最基本的要求，如果一個數據庫沒辦法把資料安全完整存下來，那麼後續的任何功能都沒有意義。當滿足第一點後，使用者緊接著就會要求能夠使用資料，可能是簡單的查詢，比如按照某個Key來查詢Value；也可能是複雜的查詢，比如要對資料做複雜的聚合操作、連表操作、分組操作。往往第二點是一個比第一點更難滿足的需求。

在資料庫發展早期階段，這兩個需求其實不難滿足，比如有很多優秀的商業資料庫產品，如Oracle/DB2。在1990年之後，出現了開源資料庫MySQL和PostgreSQL。這些資料庫不斷地提升單機例項效能，再加上遵循摩爾定律的硬體提升速度，往往能夠很好地支撐業務發展。

接下來，隨著網際網路的不斷普及特別是移動網際網路的興起，資料規模爆炸式增長，而硬體這些年的進步速度卻在逐漸減慢，人們也在擔心摩爾定律會失效。在此消彼長的情況下，單機資料庫越來越難以滿足使用者需求，即使是將資料儲存下來這個最基本的需求。

2、分散式資料庫

所以2005年左右，人們開始探索分散式資料庫，帶起了NoSQL這波浪潮。這些資料庫解決的首要問題是單機上無法儲存全部資料，其中以HBase/Cassadra/MongoDB為代表。為了實現容量的水平擴充套件，這些資料庫往往要放棄事務，或者是隻提供簡單的KV介面。儲存模型的簡化為儲存系統的開發帶來了便利，但是降低了對業務的支撐。

（1）NoSQL的進擊

HBase是其中的典型代表。HBase是Hadoop生態中的重要產品，Google BigTable的開源實現，所以這裡先說一下BigTable。

BigTable是Google內部使用的分散式資料庫，構建在GFS的基礎上，彌補了分散式檔案系統對於小物件的插入、更新、隨機讀請求的缺陷。HBase也按照這個架構實現，底層基於HDFS。HBase本身並不實際儲存資料，持久化的日誌和SST file儲存在HDFS上，Region Server通過 MemTable 提供快速的查詢，寫入都是先寫日誌，後臺進行Compact，將隨機寫轉換為順序寫。資料通過 Region 在邏輯上進行分割，負載均衡通過調節各個Region Server負責的Region區間實現，Region在持續寫入後，會進行分裂，然後被負載均衡策略排程到多個Region Server上。

前面提到了，HBase本身並不儲存資料，這裡的Region僅是邏輯上的概念，資料還是以檔案的形式儲存在HDFS上，HBase並不關心副本個數、位置以及水平擴充套件問題，這些都依賴於HDFS實現。和BigTable一樣，HBase提供行級的一致性，從CAP理論的角度來看，它是一個CP的系統，並且沒有更進一步提供 ACID 的跨行事務，也是很遺憾。

HBase的優勢在於通過擴充套件Region Server可以幾乎線性提升系統的吞吐，及HDFS本身就具有的水平擴充套件能力，且整個系統成熟穩定。但HBase依然有一些不足。首先，Hadoop使用Java開發，GC延遲是一個無法避免問題，這對系統的延遲造成一些影響。另外，由於HBase本身並不儲存資料，和HDFS之間的互動會多一層效能損耗。第三，HBase和BigTable一樣，並不支援跨行事務，所以在Google內部有團隊開發了MegaStore、Percolator這些基於BigTable的事務層。Jeff Dean承認很後悔沒有在BigTable中加入跨行事務，這也是Spanner出現的一個原因。

（2）RDMS的救贖

除了NoSQL之外，RDMS系統也做了不少努力來適應業務的變化，也就是關係型資料庫的中介軟體和分庫分表方案。做一款中介軟體需要考慮很多，比如解析 SQL，解析出ShardKey，然後根據ShardKey分發請求，再合併結果。另外在中介軟體這層還需要維護Session及事務狀態，而且大多數方案並不支援跨shard的事務，這就不可避免地導致了業務使用起來會比較麻煩，需要自己維護事務狀態。此外，還有動態的擴容縮容和自動的故障恢復，在叢集規模越來越大的情況下，運維和DDL的複雜度是指數級上升。

國內開發者在這個領域有過很多的著名的專案，比如阿里的Cobar、TDDL，後來社群基於Cobar改進的MyCAT，360開源的Atlas等，都屬於這一類中介軟體產品。在中介軟體這個方案上有一個知名的開源專案是Youtube的Vitess，這是一個集大成的中介軟體產品，內建了熱資料快取、水平動態分片、讀寫分離等，但這也造成了整個專案非常複雜。

另外一個值得一提的是PostgreSQL XC這個專案，其整體的架構有點像早期版本的OceanBase，由一箇中央節點來處理協調分散式事務，資料分散在各個儲存節點上，應該是目前PG 社群最好的分散式擴充套件方案，不少人在基於這個專案做自己的系統。

3、NewSQL的發展

2012~2013年Google 相繼發表了Spanner和F1兩套系統的論文，讓業界第一次看到了關係模型和NoSQL的擴充套件性在一個大規模生產系統上融合的可能性。 Spanner 通過使用硬體裝置（GPS時鐘+原子鐘）巧妙地解決時鐘同步的問題，而在分散式系統裡，時鐘正是最讓人頭痛的問題。Spanner的強大之處在於即使兩個資料中心隔得非常遠，也能保證通過TrueTime API獲取的時間誤差在一個很小的範圍內（10ms），並且不需要通訊。Spanner的底層仍然基於分散式檔案系統，不過論文裡也說是可以未來優化的點。

Google的內部的資料庫儲存業務，大多是3~5副本，重要的資料需要7副本，且這些副本遍佈全球各大洲的資料中心，由於普遍使用了Paxos，延遲是可以縮短到一個可以接受的範圍(寫入延遲100ms以上)，另外由Paxos帶來的Auto-Failover能力，更是讓整個叢集即使資料中心癱瘓，業務層都是透明無感知的。F1是構建在Spanner之上，對外提供了SQL介面，F1是一個分散式MPP SQL層，其本身並不儲存資料，而是將客戶端的SQL翻譯成對KV的操作，呼叫Spanner來完成請求。

Spanner和F1的出現標誌著第一個NewSQL在生產環境中提供服務，將下面幾個功能在一套系統中提供：

1. SQL支援
2. ACID事務
3. 水平擴充套件
4. Auto Failover
5. 多機房異地容災

正因為具備如此多的誘人特性，在Google內部，大量的業務已經從原來的 BigTable切換到Spanner之上。相信這對業界的思路會有巨大的影響，就像當年的Hadoop一樣，Google的基礎軟體的技術趨勢是走在社群前面的。

Spanner/F1論文引起了社群的廣泛的關注，很快開始出現了追隨者。第一個團隊是CockroachLabs做的CockroachDB。CockroachDB的設計和Spanner很像，但是沒有選擇TrueTime API ，而是使用HLC（Hybrid logical clock），也就是NTP +邏輯時鐘來代替TrueTime時間戳，另外CockroachDB選用Raft做資料複製協議，底層儲存落地在RocksDB中，對外的介面選擇了PG協議。

CockroachDB的技術選型比較激進，比如依賴了HLC來做事務，時間戳的精確度並沒有辦法做到10ms內的延遲，所以Commit Wait需要使用者自己指定，其選擇取決於使用者的NTP服務時鐘誤差，這點對於使用者來說非常不友好。當然 CockroachDB的這些技術選擇也帶來了很好的易用性，所有邏輯都在一個元件中，部署非常簡單，這個是非常大的優點。

另一個追隨者就是我們做的TiDB。這個專案已經開發了兩年時間，當然在開始動手前我們也準備了很長時間。接下來我會介紹一下這個專案。

二、TiDB的架構和最近進展

TiDB本質上是一個更加正統的Spanner和F1實現，並不CockroachDB那樣選擇將SQL和KV融合，而是像Spanner和F1一樣選擇分離。下面是TiDB的架構圖：

這樣分層的思想也是貫穿整個TiDB專案始終的，對於測試，滾動升級以及各層的複雜度控制會比較有優勢，另外TiDB選擇了MySQL協議和語法的相容，MySQL社群的ORM框架、運維工具，直接可以應用在TiDB上，另外和 Spanner一樣，TiDB是一個無狀態的MPP SQL Layer，整個系統的底層是依賴 TiKV 來提供分散式儲存和分散式事務的支援，TiKV的分散式事務模型採用的是Google Percolator的模型，但是在此之上做了很多優化，Percolator的優點是去中心化程度非常高，整個繼續不需要一個獨立的事務管理模組，事務提交狀態這些資訊其實是均勻分散在系統的各個key的meta中，整個模型唯一依賴的是一個授時伺服器，在我們的系統上，極限情況這個授時伺服器每秒能分配 400w以上個單調遞增的時間戳，大多數情況基本夠用了（畢竟有Google量級的場景並不多見），同時在TiKV中，這個授時服務本身是高可用的，也不存在單點故障的問題。

上面是TiKV的架構圖。TiKV和CockroachDB一樣也是選擇了Raft作為整個資料庫的基礎，不一樣的是，TiKV整體採用Rust語言開發，作為一個沒有GC和 Runtime的語言，在效能上可以挖掘的潛力會更大。不同TiKV例項上的多個副本一起構成了一個Raft Group，PD負責對副本的位置進行排程，通過配置排程策略，可以保證一個Raft Group的多個副本不會儲存在同一臺機器/機架/機房中。

除了核心的TiDB、TiKV之外，我們還提供了不少易用的工具，便於使用者做資料遷移和備份。比如我們提供的Syncer，不但能將單個MySQL例項中的資料同步到TiDB，還能將多個MySQL例項中的資料彙總到一個TiDB叢集中，甚至是將已經分庫分表的資料再合庫合表。這樣資料的同步方式更加靈活好用。

TiDB目前即將釋出RC3版本，預計六月份能夠釋出GA版本。在即將到來的 RC3版本中，對MySQL相容性、SQL優化器、系統穩定性、效能做了大量的工作。對於OLTP場景，重點優化寫入效能。另外提供了許可權管理功能，使用者可以按照MySQL的許可權管理方式控制資料訪問許可權。對於OLAP場景，也對優化器做了大量的工作，包括更多語句的優化、支援SortMergeJoin運算元、IndexLookupJoin運算元。另外對記憶體使用也做了大量的優化，一些場景下，記憶體使用下降75%。

除了TiDB本身的優化之外，我們還在做一個新的工程，名字叫TiSpark。簡單來講，就是讓Spark更好地接入TiDB。現在其實Spark已經可以通過JDBC介面讀取TiDB中的資料，但是這裡有兩個問題：1. 只能通過單個TiDB節點讀取資料且資料需要從TiKV中經過 TiDB 中轉。2. 不能和Spark的優化器相結合，我們期望能和Spark的優化器整合，將Filter、聚合能通過TiKV的分散式計算能力提速。這個專案已經開始開發，預計近期開源，五月份就能有第一個版本。

三、分散式資料庫的未來趨勢

關於未來，我覺得未來的資料庫會有幾個趨勢，也是TiDB專案追求的目標：

1、資料庫會隨著業務雲化，未來一切的業務都會跑在雲端，不管是私有云或者公有云，運維團隊接觸的可能再也不是真實的物理機，而是一個個隔離的容器或者「計算資源」，這對資料庫也是一個挑戰，因為資料庫天生就是有狀態的，資料總是要儲存在物理的磁碟上，而資料移動的代價比移動容器的代價可能大很多。

2、多租戶技術會成為標配，一個大資料庫承載一切的業務，資料在底層打通，上層通過許可權，容器等技術進行隔離，但是資料的打通和擴充套件會變得異常簡單，結合第一點提到的雲化，業務層可以再也不用關心物理機的容量和拓撲，只需要認為底層是一個無窮大的資料庫平臺即可，不用再擔心單機容量和負載均衡等問題。

3、OLAP和OLTP業務會融合，使用者將資料儲存進去後，需要比較方便高效的方式訪問這塊資料，但是OLTP和OLAP在SQL優化器/執行器這層的實現一定是千差萬別的。以往的實現中，使用者往往是通過ETL工具將資料從OLTP資料庫同步到OLAP資料庫，這一方面造成了資源的浪費，另一方面也降低了OLAP的實時性。對於使用者而言，如果能使用同一套標準的語法和規則來進行資料的讀寫和分析，會有更好的體驗。

4、在未來分散式資料庫系統上，主從日誌同步這樣落後的備份方式會被Multi-Paxos / Raft這樣更強的分散式一致性演算法替代，人工的資料庫運維在管理大規模資料庫叢集時是不可能的，所有的故障恢復和高可用都將是高度自動化的。

文章來自微信公眾號:DBAplus社群