本文是劉奇在SDCC 2015數(shù)據(jù)庫(kù)實(shí)踐論壇上分享的《HBase分布式事務(wù)與SQL實(shí)現(xiàn)》主題內(nèi)容。

目前主流的數(shù)據(jù)庫(kù)或者NoSQL要么在CAP里面選擇AP，比較典型的例子是Cassandra，要么選擇CP比如HBase，這兩個(gè)是目前用得非常多的NoSQL的實(shí)現(xiàn)。我們的價(jià)值觀一定認(rèn)為未來(lái)是分布式的，一定是盡量?jī)A向于全部都擁有，大部分情況下取舍都是HA，主流的比較頂級(jí)的數(shù)據(jù)庫(kù)都會(huì)選擇C，分布式系統(tǒng)一定逃不過(guò)P，所以A就只能選擇HA?，F(xiàn)在主要領(lǐng)域是數(shù)據(jù)庫(kù)的開(kāi)發(fā)，完全分布式，主要方向和谷歌的F1方向非常類(lèi)似。

目前看NewSQL代表未來(lái)(Google Spanner、F1、FoundationDB)，HBase在國(guó)內(nèi)有六個(gè)Committer，在目前主流的開(kāi)源數(shù)據(jù)庫(kù)里面幾乎是最強(qiáng)的陣容。大家選型的時(shí)候會(huì)有一個(gè)猶豫，到底應(yīng)該選擇HBase還是選Cassandra。根據(jù)應(yīng)用場(chǎng)景，如果需要一致性，HBase一定是你最好的選擇，我推薦HBase。它始終保持強(qiáng)一致，我們非常喜歡一致性，喪失一致性的時(shí)候有些錯(cuò)誤會(huì)特別詭異，很難查。對(duì)于Push-down特性的設(shè)計(jì)其實(shí)比較好，全局上是一個(gè)巨大的分布式數(shù)據(jù)庫(kù)，但是邏輯上是分成了一個(gè)個(gè)Region，Region在哪臺(tái)機(jī)器上是明確的。

比如要統(tǒng)計(jì)記錄的條數(shù)，假設(shè)數(shù)據(jù)分布在整個(gè)系統(tǒng)里面，對(duì)數(shù)十億記錄做一個(gè)求和操作，就是說(shuō)不同的機(jī)器上都要做一個(gè)sum，把條件告訴他要完成哪些任務(wù)，他給你任務(wù)你再匯總，這是典型的分布式的 MPP，做加速的時(shí)候是非常有效的。

2015年HBaseConf 上面有一句總結(jié): “Nothing is hotter than SQL-on-Hadoop, and now SQL-on- HBase is fast approaching equal hotness status”， 實(shí)際上SQL-on-HBase 也是非?；稹Ｒ?yàn)?Schema Less 沒(méi)有約束其實(shí)是很?chē)樔说囊患虑?，?dāng)然沒(méi)有約束也比較爽，就是后期維護(hù)十分痛苦，規(guī)模進(jìn)一步擴(kuò)大了之后又需要遷移到 SQL。

現(xiàn)在無(wú)論從品質(zhì)還是速度上要求已經(jīng)越來(lái)越高，擁有SQL的同時(shí)還希望有ACID的東西(OLAP一般不追求一致性)。所以TiDB在設(shè)計(jì)時(shí)就強(qiáng)調(diào)這樣的特點(diǎn)：始終保持分布式事務(wù)的支持，兼容MySQL協(xié)議。無(wú)數(shù)公司在SQL遇到Scale問(wèn)題的時(shí)候很痛苦地做出了選擇，比如遷移到HBase，Cassandra MongoDB已經(jīng)看過(guò)太多的公司做這種無(wú)比痛苦的事情，現(xiàn)在不用痛苦了，直接遷過(guò)來(lái)，直接把數(shù)據(jù)導(dǎo)進(jìn)來(lái)就OK了。TiDB最重要的是關(guān)注OLTP，對(duì)于互聯(lián)網(wǎng)業(yè)務(wù)來(lái)說(shuō)通常是在毫秒級(jí)內(nèi)就需要返回一個(gè)結(jié)果。

我們到目前為止開(kāi)發(fā)了六個(gè)月，開(kāi)源了兩個(gè)月。昨天晚上TiDB達(dá)到了第一個(gè)Alpha的階段，現(xiàn)在可以擁有一個(gè)強(qiáng)大的數(shù)據(jù)庫(kù)：支持分布式事務(wù)，始終保持同步的復(fù)制，強(qiáng)大的按需Scale能力，無(wú)阻塞的Schema變更。發(fā)布第一個(gè)Alpha版本的時(shí)候以前的質(zhì)疑都會(huì)淡定下來(lái)，因?yàn)槟憧梢蚤喿x每一行代碼，體驗(yàn)每個(gè)功能。選擇這個(gè)領(lǐng)域也是非常艱難的決定，實(shí)在太Hardcore了，當(dāng)初Google Spanner也做了5年。不過(guò)我們是真愛(ài)，我們就是技術(shù)狂，就是要解決問(wèn)題，就是要挑大家最頭痛的問(wèn)題去解決。好在目前阿里的OceanBase給我們服了顆定心丸，大家也不會(huì)質(zhì)疑分布式關(guān)系型數(shù)據(jù)庫(kù)是否可行。

TiDB名字由來(lái)

為什么叫TiDB？大家起名字的時(shí)候特別喜歡用希臘神話里面的人物，但幾乎所有的希臘神話人物的名字都被別的項(xiàng)目使用了，后來(lái)我們就找了化學(xué)元素周期表（理工科男與生俱來(lái)的特征），化學(xué)元素周期表里找到一個(gè)不俗且又能代表我們數(shù)據(jù)庫(kù)特性的元素-Ti 。Ti是航空航天及航海里面很重要的設(shè)備都會(huì)用到的，特別穩(wěn)定，也比較貴。

TiDB的系統(tǒng)架構(gòu)圖

TiDB怎么支持MySQL這個(gè)協(xié)議？這里會(huì)有一個(gè)協(xié)議解析層，它的作用就是去分析MySQL協(xié)議，轉(zhuǎn)成內(nèi)部可以識(shí)別的分發(fā)給自己的SQL Layer。當(dāng)SQL Layer 拿到這個(gè)語(yǔ)句之后會(huì)把它拆成對(duì)應(yīng)的分布式KV操作，所以這里會(huì)有一個(gè)Transactional KV Storage。接下來(lái)是在KV基礎(chǔ)上增加事務(wù)的支持，再往上是普通的KV操作，理論上KV選什么都可以，如果選的是HBase有一個(gè)好處，它本身就是分布式，省掉分布式的工作。目前我們?cè)谛∶椎腡hemis基礎(chǔ)上做了些優(yōu)化和改進(jìn)，和我們TiDB做了一個(gè)很好的結(jié)合。后期我們有一個(gè)計(jì)劃，準(zhǔn)備自己重寫(xiě)一套底層的分布式KV，把HBase換掉。因?yàn)镠Base對(duì)于Container不友好，加上GC也是讓人比較討厭的問(wèn)題，壓力比較大的時(shí)候GC延遲會(huì)加長(zhǎng)。

Google Percolator實(shí)現(xiàn)方式

HBase上面分布式事務(wù)典型的設(shè)計(jì)，先來(lái)說(shuō)一下Goolge Percolator 內(nèi)部實(shí)現(xiàn)，看架構(gòu)圖：

Goolge Percolator內(nèi)部實(shí)現(xiàn)

分布式事務(wù)基本設(shè)計(jì)是在上面這個(gè) Percolator層，Timestamp Oracle 可以保證嚴(yán)格的遞增。Percolator是在KV上的實(shí)現(xiàn)，它對(duì)于SQL的角度考慮比較少，有一個(gè)隔離級(jí)別的問(wèn)題，很典型的是Snapshot Isolation, SQL 語(yǔ)句落在KV上的實(shí)現(xiàn)，如果只有Snapshot Isolation的話隔離級(jí)別就太低了。此外，這個(gè)模型還有其它的問(wèn)題。比如，它每秒能分配多少個(gè)遞增的Timestamp？Google分享的一個(gè)slides的數(shù)據(jù)，每秒200萬(wàn)，小米也開(kāi)源了自己的實(shí)現(xiàn)，每秒60萬(wàn)，我們前一陣也寫(xiě)了一個(gè)每秒400萬(wàn)，優(yōu)化一下可以達(dá)到800萬(wàn)。因?yàn)門(mén)imestamp業(yè)務(wù)特別簡(jiǎn)單，所以可以做針對(duì)性的優(yōu)化，當(dāng)然很少有業(yè)務(wù)能跑到這個(gè)級(jí)別的事務(wù)。

Yahoo OMID的實(shí)現(xiàn)

雅虎的OMID實(shí)現(xiàn)，架構(gòu)圖如下：

雅虎的OMID實(shí)現(xiàn)

除了Timestamp的職能，TSO還維護(hù)更多信息用于檢測(cè)事務(wù)沖突。TSO是整個(gè)Omid系統(tǒng)的單點(diǎn)，如果一個(gè)系統(tǒng)只需要一個(gè)單點(diǎn)，單點(diǎn)做得越少就能獲得越多的性能，也更容易優(yōu)化。

下圖是它的分布式事務(wù)的執(zhí)行過(guò)程：

假設(shè)現(xiàn)在要發(fā)起一個(gè)分布式事務(wù)，第一個(gè)事情是拿Start TS，再去做你的讀寫(xiě)操作，做讀寫(xiě)操作的時(shí)候會(huì)把Key都記下來(lái)。Commit的時(shí)候要先沖突檢測(cè)，這就是TSO 要做的更多的事情，更具體的細(xì)節(jié)請(qǐng)參考Omid 的論文或者 <<從零開(kāi)始寫(xiě)分布式數(shù)據(jù)庫(kù)>>一書(shū)。

谷歌的Spanner，細(xì)節(jié)非常多，引用的論文有40多篇，很?chē)樔耍行┮玫恼撐囊卜浅＝?jīng)典，很值得一讀。Spanner已經(jīng)不再使用NTP了，需要用一個(gè)有信心的靠譜的方式來(lái)同步時(shí)間。內(nèi)部也說(shuō)不再用NTP做時(shí)間的維護(hù)，GPS是非常簡(jiǎn)單便宜的方式，GPS是大家使用滴滴打車(chē)時(shí)用于得到定位信息的。GPS還給了當(dāng)前精確的時(shí)鐘信息，有軟件可以把這個(gè)檢測(cè)出來(lái)，可以直接使用它的這個(gè)信號(hào)來(lái)同步時(shí)間。使用GPS信號(hào)的好處很明顯，隨便在哪個(gè)山區(qū)都有GPS信號(hào)，但不一定能收到基站的信號(hào)，同時(shí)它的精度也非常高。

TiDB的技術(shù)選型

再來(lái)說(shuō)說(shuō)TiDB的一些技術(shù)選型的例子。選擇MySQL協(xié)議后會(huì)做一些取舍，有些地方不完全按Google F1去做設(shè)計(jì)的。Google F1里做的比較好的是非常經(jīng)典的Non-blocking schema changes。比如現(xiàn)在要加一個(gè)索引，如果橫跨數(shù)十臺(tái)機(jī)器，數(shù)十億條記錄，加索引的速度是非常慢的，那么這個(gè)過(guò)程必須是不阻塞的，不影響正在運(yùn)行的業(yè)務(wù)的。因?yàn)樵诮⑺饕耐瑫r(shí)需要修改別的地方，所以要做一個(gè)原子的提交，細(xì)節(jié)上還要處理事務(wù)沖突的錯(cuò)誤。F1有并發(fā)的圖，我們剛才提到HBase里通過(guò)Push-down可以把一些計(jì)算下推到對(duì)應(yīng)的節(jié)點(diǎn)上去。但由于F1依賴(lài)Spanner，而Spanner會(huì)頻繁地做Reblancing，會(huì)把數(shù)據(jù)不斷的移動(dòng)，所以它在上面很難基于range信息一次做最優(yōu)的決策。

SQL如何映射分布式KV？

SQL到底是怎么映射到分布式KV上？現(xiàn)在HBase分層分得更加清楚，SQL層不太關(guān)心下面到底用什么，在乎的是接口。映射的過(guò)程，假設(shè)User Table里面有個(gè)Email，我們存儲(chǔ)的時(shí)候是用ID做它的標(biāo)識(shí)，這有很多的好處，比如刪掉再重新添加一樣的，它要生成不同的ID。在數(shù)十億條記錄的情況下刪除一個(gè)Table，刪除的過(guò)程完全可以由Map-Reduce異步去做。

為什么提供MySQL協(xié)議的支持？如果重新寫(xiě)一個(gè)數(shù)據(jù)庫(kù)會(huì)遇到一個(gè)很大的問(wèn)題，大家憑什么相信你是對(duì)的，數(shù)據(jù)庫(kù)需要時(shí)間需要測(cè)試，好在你接入MySQL協(xié)議，你可以經(jīng)過(guò)和MySQL一樣嚴(yán)謹(jǐn)?shù)臏y(cè)試。但如果是自己完全寫(xiě)一個(gè)，不借用它的協(xié)議，不借用它的語(yǔ)法，沒(méi)有測(cè)試，大家憑什么相信你是對(duì)的。現(xiàn)在這個(gè)時(shí)代沒(méi)有Communit是很可怕的，閉門(mén)造車(chē)很容易走偏。TiDB現(xiàn)在可以讓用戶(hù)一行代碼都不改，跑WordPress等，還支持很多的ORM，這些ORM可以直接用，用戶(hù)的代碼一行不改可以直接遷過(guò)來(lái)，完全擁有水平擴(kuò)展的能力，完全擁有分布式事務(wù)的支持。前TiDB在Github上2800+star。

個(gè)人簡(jiǎn)介：