隨著大數(shù)據(jù)這個(gè)概念的興起以及真實(shí)需求在各個(gè)行業(yè)的落地，很多人都熱衷于討論分布式數(shù)據(jù)庫，今天就這個(gè)話題，主要分為三部分：第一部分講一下分布式數(shù)據(jù)庫的過去和現(xiàn)狀，希望大家能對這個(gè)領(lǐng)域有一個(gè)全面的了解；第二部分講一下TiDB的架構(gòu)以及最近的一些進(jìn)展；最后結(jié)合我們開發(fā)TiDB過程中的一些思考講一下分布式數(shù)據(jù)庫未來可能的趨勢。
一、分布式數(shù)據(jù)庫的歷史和現(xiàn)狀
1、從單機(jī)數(shù)據(jù)庫說起
關(guān)系型數(shù)據(jù)庫起源自1970年代，其最基本的功能有兩個(gè)：
把數(shù)據(jù)存下來；
滿足用戶對數(shù)據(jù)的計(jì)算需求。
第一點(diǎn)是最基本的要求，如果一個(gè)數(shù)據(jù)庫沒辦法把數(shù)據(jù)安全完整存下來，那么后續(xù)的任何功能都沒有意義。當(dāng)滿足第一點(diǎn)后，用戶緊接著就會(huì)要求能夠使用數(shù)據(jù)，可能是簡單的查詢，比如按照某個(gè)Key來查找Value；也可能是復(fù)雜的查詢，比如要對數(shù)據(jù)做復(fù)雜的聚合操作、連表操作、分組操作。往往第二點(diǎn)是一個(gè)比第一點(diǎn)更難滿足的需求。
在數(shù)據(jù)庫發(fā)展早期階段，這兩個(gè)需求其實(shí)不難滿足，比如有很多優(yōu)秀的商業(yè)數(shù)據(jù)庫產(chǎn)品，如Oracle/DB2。在1990年之后，出現(xiàn)了開源數(shù)據(jù)庫MySQL和PostgreSQL。這些數(shù)據(jù)庫不斷地提升單機(jī)實(shí)例性能，再加上遵循摩爾定律的硬件提升速度，往往能夠很好地支撐業(yè)務(wù)發(fā)展。
接下來，隨著互聯(lián)網(wǎng)的不斷普及特別是移動(dòng)互聯(lián)網(wǎng)的興起，數(shù)據(jù)規(guī)模爆炸式增長，而硬件這些年的進(jìn)步速度卻在逐漸減慢，人們也在擔(dān)心摩爾定律會(huì)失效。在此消彼長的情況下，單機(jī)數(shù)據(jù)庫越來越難以滿足用戶需求，即使是將數(shù)據(jù)保存下來這個(gè)最基本的需求。
2、分布式數(shù)據(jù)庫
所以2005年左右，人們開始探索分布式數(shù)據(jù)庫，帶起了NoSQL這波浪潮。這些數(shù)據(jù)庫解決的首要問題是單機(jī)上無法保存全部數(shù)據(jù)，其中以HBase/Cassadra/MongoDB為代表。為了實(shí)現(xiàn)容量的水平擴(kuò)展，這些數(shù)據(jù)庫往往要放棄事務(wù)，或者是只提供簡單的KV接口。存儲(chǔ)模型的簡化為存儲(chǔ)系統(tǒng)的開發(fā)帶來了便利，但是降低了對業(yè)務(wù)的支撐。
（1）NoSQL的進(jìn)擊
HBase是其中的典型代表。HBase是Hadoop生態(tài)中的重要產(chǎn)品，Google BigTable的開源實(shí)現(xiàn)，所以這里先說一下BigTable。
BigTable是Google內(nèi)部使用的分布式數(shù)據(jù)庫，構(gòu)建在GFS的基礎(chǔ)上，彌補(bǔ)了分布式文件系統(tǒng)對于小對象的插入、更新、隨機(jī)讀請求的缺陷。HBase也按照這個(gè)架構(gòu)實(shí)現(xiàn)，底層基于HDFS。HBase本身并不實(shí)際存儲(chǔ)數(shù)據(jù)，持久化的日志和SST file存儲(chǔ)在HDFS上，Region Server通過 MemTable 提供快速的查詢，寫入都是先寫日志，后臺(tái)進(jìn)行Compact，將隨機(jī)寫轉(zhuǎn)換為順序?qū)?。?shù)據(jù)通過 Region 在邏輯上進(jìn)行分割，負(fù)載均衡通過調(diào)節(jié)各個(gè)Region Server負(fù)責(zé)的Region區(qū)間實(shí)現(xiàn)，Region在持續(xù)寫入后，會(huì)進(jìn)行分裂，然后被負(fù)載均衡策略調(diào)度到多個(gè)Region Server上。
前面提到了，HBase本身并不存儲(chǔ)數(shù)據(jù)，這里的Region僅是邏輯上的概念，數(shù)據(jù)還是以文件的形式存儲(chǔ)在HDFS上，HBase并不關(guān)心副本個(gè)數(shù)、位置以及水平擴(kuò)展問題，這些都依賴于HDFS實(shí)現(xiàn)。和BigTable一樣，HBase提供行級的一致性，從CAP理論的角度來看，它是一個(gè)CP的系統(tǒng)，并且沒有更進(jìn)一步提供 ACID 的跨行事務(wù)，也是很遺憾。
HBase的優(yōu)勢在于通過擴(kuò)展Region Server可以幾乎線性提升系統(tǒng)的吞吐，及HDFS本身就具有的水平擴(kuò)展能力，且整個(gè)系統(tǒng)成熟穩(wěn)定。但HBase依然有一些不足。首先，Hadoop使用Java開發(fā)，GC延遲是一個(gè)無法避免問題，這對系統(tǒng)的延遲造成一些影響。另外，由于HBase本身并不存儲(chǔ)數(shù)據(jù)，和HDFS之間的交互會(huì)多一層性能損耗。第三，HBase和BigTable一樣，并不支持跨行事務(wù)，所以在Google內(nèi)部有團(tuán)隊(duì)開發(fā)了MegaStore、Percolator這些基于BigTable的事務(wù)層。Jeff Dean承認(rèn)很后悔沒有在BigTable中加入跨行事務(wù)，這也是Spanner出現(xiàn)的一個(gè)原因。
（2）RDMS的救贖
除了NoSQL之外，RDMS系統(tǒng)也做了不少努力來適應(yīng)業(yè)務(wù)的變化，也就是關(guān)系型數(shù)據(jù)庫的中間件和分庫分表方案。做一款中間件需要考慮很多，比如解析 SQL，解析出ShardKey，然后根據(jù)ShardKey分發(fā)請求，再合并結(jié)果。另外在中間件這層還需要維護(hù)Session及事務(wù)狀態(tài)，而且大多數(shù)方案并不支持跨shard的事務(wù)，這就不可避免地導(dǎo)致了業(yè)務(wù)使用起來會(huì)比較麻煩，需要自己維護(hù)事務(wù)狀態(tài)。此外，還有動(dòng)態(tài)的擴(kuò)容縮容和自動(dòng)的故障恢復(fù)，在集群規(guī)模越來越大的情況下，運(yùn)維和DDL的復(fù)雜度是指數(shù)級上升。
國內(nèi)開發(fā)者在這個(gè)領(lǐng)域有過很多的著名的項(xiàng)目，比如阿里的Cobar、TDDL，后來社區(qū)基于Cobar改進(jìn)的MyCAT，360開源的Atlas等，都屬于這一類中間件產(chǎn)品。在中間件這個(gè)方案上有一個(gè)知名的開源項(xiàng)目是Youtube的Vitess，這是一個(gè)集大成的中間件產(chǎn)品，內(nèi)置了熱數(shù)據(jù)緩存、水平動(dòng)態(tài)分片、讀寫分離等，但這也造成了整個(gè)項(xiàng)目非常復(fù)雜。