TechWeb

2017-06-24 03:02

【51CTO.com原創(chuàng)稿件】著名的開(kāi)源分布式緩存服務(wù) Codis 的作者，PingCAP 聯(lián)合創(chuàng)始人& CTO ，資深 infrastructure 工程師的黃東旭，擅長(zhǎng)分布式存儲(chǔ)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)，開(kāi)源狂熱分子的技術(shù)大神級(jí)別人物。即使在互聯(lián)網(wǎng)如此繁榮的今天，在數(shù)據(jù)庫(kù)這片邊界模糊且不確定地帶，他還在努力尋找確定性的實(shí)踐方向。

在數(shù)據(jù)庫(kù)的平行世界里，黃東旭以不同的方式在追隨著自己的內(nèi)心。他認(rèn)為，通常傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)無(wú)法滿足海量數(shù)據(jù)處理和分析時(shí)，新一輪的窗口期也隨之需求開(kāi)啟，但是各類劣勢(shì)架構(gòu)、內(nèi)存架構(gòu)、 NoSQL 等方案都不能滿足自己理想的解決方案，這些都不夠美，很少能夠把分布式事務(wù)與彈性擴(kuò)展做到完美。

絕對(duì)的理性與感性，在黃東旭的身上看似矛盾，直到 2012 年底，他看到 Google 發(fā)布的兩篇論文，如同棱鏡般，折射出他自己內(nèi)心微爍的光彩。這兩篇論文描述了 Google 內(nèi)部使用的一個(gè)海量關(guān)系型數(shù)據(jù)庫(kù) F1/Spanner ，解決了關(guān)系型數(shù)據(jù)庫(kù)、彈性擴(kuò)展以及全球分布的問(wèn)題，并在生產(chǎn)中大規(guī)模使用?！叭绻@個(gè)能實(shí)現(xiàn)，對(duì)數(shù)據(jù)存儲(chǔ)領(lǐng)域來(lái)說(shuō)將是顛覆性的”，黃東旭為完美方案的出現(xiàn)而興奮， PingCAP 的 TiDB 在此基礎(chǔ)上誕生了。

當(dāng)然，每向前進(jìn)一步，都需要付出巨大的努力。在啟動(dòng) TiDB 項(xiàng)目之前，黃東旭先完成了一個(gè)開(kāi)源分布式的 Redis 集群方案 Codis ，這個(gè)項(xiàng)目完成以后讓他們覺(jué)得雖然緩存的水平擴(kuò)展問(wèn)題有了解決方案，但是底層的關(guān)系型數(shù)據(jù)庫(kù)（主要是 MySQL 為主）并沒(méi)有一個(gè)優(yōu)雅的擴(kuò)展方案。業(yè)界除了在業(yè)務(wù)層分庫(kù)分表，或者使用中間件等折衷方案外，并沒(méi)有其他太多的辦法，有些業(yè)務(wù)可能能遷移到 NoSQL 之上，例如 HBase 、 C* 等，跟很多的業(yè)務(wù)沒(méi)法平滑遷移，幾乎需要重寫(xiě)全部邏輯。如果采用分庫(kù)分表和中間件的方案，擴(kuò)展以及高可用的方案會(huì)帶來(lái)大量額外的運(yùn)維成本，比如無(wú)法使用跨 shard 的 join、子查詢、跨行事務(wù)等。

但是作為一個(gè)基礎(chǔ)軟件工程師的黃東旭他們不希望將這些復(fù)雜度轉(zhuǎn)嫁給業(yè)務(wù)層，所以就開(kāi)始重新審視整個(gè)數(shù)據(jù)庫(kù)，希望從根本上解決 MySQL 的擴(kuò)展問(wèn)題，而不是再造一個(gè)中間件。

“如果創(chuàng)造一個(gè)全新的東西，使它有一天能夠成為生產(chǎn)力，那種感覺(jué)真好！”

在 2012 、 2013 年期間，黃東旭他們就開(kāi)始研究了Google 發(fā)表的一系列關(guān)于新一代分布式數(shù)據(jù)庫(kù) Spanner 和 F1 的論文以及相關(guān)的學(xué)術(shù)界的進(jìn)展，直到 2015 年，他們覺(jué)得基本所有的技術(shù)問(wèn)題和架構(gòu)都已經(jīng)思考得差不多了，于是決定出來(lái)全職去重新開(kāi)始完整的實(shí)現(xiàn)一個(gè)新的數(shù)據(jù)庫(kù)，也就是今天的主角——下一代開(kāi)源 NewSQL 數(shù)據(jù)庫(kù) TiDB 。

當(dāng)然了，創(chuàng)造并不意味著開(kāi)始，它需要面臨的是無(wú)限的投入和無(wú)限的博弈來(lái)適應(yīng)互聯(lián)網(wǎng)的競(jìng)爭(zhēng)和審視，真正做到讓開(kāi)發(fā)者和企業(yè)受益，才是真正的開(kāi)始。

TiDB在整體架構(gòu)基本是參考 Google Spanner 和 F1 的設(shè)計(jì)，上分兩層為 TiDB 和 TiKV 。 TiDB 對(duì)應(yīng)的是 Google F1， 是一層無(wú)狀態(tài)的 SQL Layer ，兼容絕大多數(shù) MySQL 語(yǔ)法，對(duì)外暴露 MySQL 網(wǎng)絡(luò)協(xié)議，負(fù)責(zé)解析用戶的 SQL 語(yǔ)句，生成分布式的 Query Plan，翻譯成底層 Key Value 操作發(fā)送給 TiKV ， TiKV 是真正的存儲(chǔ)數(shù)據(jù)的地方，對(duì)應(yīng)的是 Google Spanner ，是一個(gè)分布式 Key Value 數(shù)據(jù)庫(kù)，支持彈性水平擴(kuò)展，自動(dòng)的災(zāi)難恢復(fù)和故障轉(zhuǎn)移（高可用），以及 ACID 跨行事務(wù)。值得一提的是 TiKV 并不像 HBase 或者 BigTable 那樣依賴底層的分布式文件系統(tǒng)，在性能和靈活性上能更好，這個(gè)對(duì)于在線業(yè)務(wù)來(lái)說(shuō)是非常重要。

▲ TiDB 整體架構(gòu)

這群理想很豐沛，這不被骨感現(xiàn)實(shí)所惑的人。在 TiDB 研發(fā)語(yǔ)言的選擇過(guò)程中，放棄了 Java 而采用 Go 。

TiDB整個(gè)項(xiàng)目分為兩層，TiDB 作為 SQL 層，采用 Go 語(yǔ)言開(kāi)發(fā)， TiKV 作為下邊的分布式存儲(chǔ)引擎，采用 Rust 語(yǔ)言開(kāi)發(fā)。在架構(gòu)上確實(shí)類似 FoundationDB，也是基于兩層的結(jié)構(gòu)。 FoundationDB 的 SQL Layer 采用 Java ，底層是 C ，不過(guò)在去年，被 Apple 收購(gòu)了。

在選擇編程語(yǔ)言并沒(méi)有融入太多的個(gè)人喜好偏向， SQL 層選擇 Go 相對(duì) Java 來(lái)說(shuō)：

第一是 他們團(tuán)隊(duì)的背景使用 Go 的開(kāi)發(fā)效率更高，而且性能尚可，尤其對(duì)于高并發(fā)程序而言，可以使用 goroutine / channel 等工具用更少的代碼寫(xiě)出正確的程序；

第二是 在標(biāo)準(zhǔn)庫(kù)中很多包對(duì)網(wǎng)絡(luò)程序開(kāi)發(fā)非常友好，這個(gè)對(duì)于一個(gè)分布式系統(tǒng)來(lái)說(shuō)非常重要；

第三是 在存儲(chǔ)引擎底層對(duì)于性能要求很高，Go 畢竟是一個(gè)帶有 GC 和 Runtime 的語(yǔ)言，在 TiKV 層可以選擇的方案并不多，過(guò)去基本只有 C 或 C ，不過(guò)近兩年隨著 Rust 語(yǔ)言的成熟，又在經(jīng)過(guò)長(zhǎng)時(shí)間的思考和大量實(shí)驗(yàn)，最終他們團(tuán)隊(duì)選擇了 Rust。

Rust 這門靜態(tài)語(yǔ)言的定位是取代 C ，最大的特點(diǎn)是通過(guò)很多語(yǔ)法的限制來(lái)避免開(kāi)發(fā)者寫(xiě)出內(nèi)存泄露和 data race 的程序，將很多問(wèn)題解決在編譯期，使得運(yùn)行時(shí)不需要花費(fèi)額外的代價(jià)進(jìn)行 GC 之類的事情，保證高性能。所以，寫(xiě)出安全的程序，這正是 C 程序的很大的一個(gè)痛點(diǎn)。

雖然在 C 11 中有了很多的改進(jìn)，但是由于歷史包袱太重或者第三方包庫(kù)開(kāi)發(fā)者的水平參差不齊。但是重要的原因不因?yàn)閯e的，正是他們的背后并不是一個(gè) C 背景很深的團(tuán)隊(duì)，所以最后放棄了 C 11 而選擇了 Rust 。

Rust 不僅有安全和高性能的特點(diǎn)，同時(shí)語(yǔ)法更加現(xiàn)代，開(kāi)發(fā)效率更高，另外擁有非常完善的包管理機(jī)制（Cargo），使得在能寫(xiě)出非常高性能且安全的程序同時(shí)，開(kāi)發(fā)效率比起 Go并沒(méi)有下降太多，對(duì)于目前來(lái)說(shuō)是一個(gè)非常正確的選擇。作為 Rust 社區(qū)內(nèi)全球最大的開(kāi)源項(xiàng)目之一，也得到了 Rust 語(yǔ)言官方團(tuán)隊(duì)的很大支持，黃東旭表示，包括一些他們需要的第三方庫(kù)，Rust team 都會(huì)放在很高優(yōu)先級(jí)上去開(kāi)發(fā)或者在社區(qū)里推進(jìn)。另外 Rust 早已發(fā)布 1.0，語(yǔ)法也早已穩(wěn)定，是一個(gè)非常有前途的系統(tǒng)編程語(yǔ)言。

輪番在Google中刷出了存在感后，還一直在沒(méi)有盡頭的草原上奔跑，黃東旭認(rèn)為只有聚焦，專注，才能擺脫掉令人迷惑的干擾。在不斷的探索后，終于尋找到了實(shí)現(xiàn)事務(wù)模型的方式。

TiDB 的事務(wù)模型通過(guò)參考了 Google 的 Percolator。該論文發(fā)表于 2010 年，是描述 Google 在 BigTable 上的構(gòu)建 ACID 跨行事務(wù)框架用于保證索引更新的一致性。算法的核心思想是兩階段提交，但是傳統(tǒng)的分布式兩階段提交的問(wèn)題是單點(diǎn)的事務(wù)管理器沒(méi)法擴(kuò)展，會(huì)成為整個(gè)系統(tǒng)的瓶頸，Percolator 使用了一個(gè)兩級(jí)鎖的機(jī)制實(shí)現(xiàn)了去中心化的事務(wù)管理器，使得整個(gè)系統(tǒng)的可擴(kuò)展性大大提升。

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

TiDB 將這個(gè)模型應(yīng)用在底層的存儲(chǔ)引擎中，并做了很多工程上的優(yōu)化，黃東旭舉例說(shuō)，通過(guò) batch 和 pipeline 等手段大大提升了授時(shí)服務(wù)的吞吐，使用 Raft RockDB 來(lái)替代原文的 BigTable 性能更好，另外采用樂(lè)觀事務(wù)機(jī)制追求更高的吞吐，不過(guò)是從算法層面，是 Percolator 實(shí)現(xiàn)。

TiDB 對(duì)比 NOSQL

TiDB 對(duì)于這些 NoSQL 來(lái)說(shuō)，最大的特點(diǎn)是編程接口是 SQL，SQL對(duì)于開(kāi)發(fā)者而言是更加靈活的操作數(shù)據(jù)庫(kù)的方式，且對(duì) MySQL 有著極高的兼容性—原業(yè)務(wù)的 MySQL切換到 TiDB 幾乎一行代碼都不用修改就可以完成。TiDB 在支持 SQL 的同時(shí)有沒(méi)有喪失 HBase 這樣的系統(tǒng)的彈性擴(kuò)展能力，業(yè)務(wù)層不需要再去關(guān)心數(shù)據(jù)庫(kù)的容量，不用去考慮分庫(kù)分表，也不用像過(guò)去那樣投入很大的運(yùn)維力量，擴(kuò)容只需簡(jiǎn)單加機(jī)器就好，存儲(chǔ)節(jié)點(diǎn)故障對(duì)業(yè)務(wù)透明，而且數(shù)據(jù)庫(kù)本身具有自我修復(fù)的能力，保證數(shù)據(jù)不會(huì)丟失。

對(duì)于 MongoDB 也是一樣，更重要的是不需要改變用戶已有的習(xí)慣和程序，而且為了定義未來(lái)的云上的數(shù)據(jù)庫(kù)形態(tài)，TiDB 設(shè)計(jì)的目標(biāo)是單集群需要可以 Scale 到 1000 以上物理節(jié)點(diǎn)的規(guī)模，支持 P 級(jí)別容量，萬(wàn)億以上的行的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)，在這個(gè)前提約束下的設(shè)計(jì)和技術(shù)選型和 MongoDB 很不一樣，在大數(shù)據(jù)量的情況下 TiDB 的表現(xiàn)更穩(wěn)定，擴(kuò)展更加平滑。

TiDB 的 SQL 優(yōu)化器是黃東旭他們從頭開(kāi)始實(shí)現(xiàn)的一個(gè)面向分布式存儲(chǔ)設(shè)計(jì)的查詢優(yōu)化器，使用了很多學(xué)術(shù)界很新的查詢優(yōu)化技術(shù)和分布式計(jì)算框架的思想，保證 MySQL 兼容性的前提下比 MySQL 在復(fù)雜查詢下表現(xiàn)要好得多。

傳統(tǒng)數(shù)據(jù)庫(kù)的痛點(diǎn)解決

任何企業(yè)，如果使用傳統(tǒng)的單機(jī)關(guān)系型數(shù)據(jù)庫(kù)，在數(shù)據(jù)量持續(xù)增長(zhǎng)下，或者對(duì)業(yè)務(wù)的可用性有嚴(yán)格要求的情況下，可能都會(huì)面臨單點(diǎn)故障和單點(diǎn)容量限制的問(wèn)題，這個(gè)問(wèn)題最近幾年在互聯(lián)網(wǎng)行業(yè)尤其突出，目前來(lái)說(shuō)除了上面提到的分庫(kù)分表和中間件也并沒(méi)有其他的方案解決，幾乎苦不堪言。

TiDB 基于更先進(jìn)的 Raft 算法來(lái)實(shí)現(xiàn)了存儲(chǔ)層的水平擴(kuò)展基礎(chǔ)上加上了分布式事務(wù)，構(gòu)建了完整的 SQL 查詢層，在保證不喪失 ACID 事務(wù)的前提下，支持 JOIN ，子查詢等復(fù)雜查詢，另外對(duì)外暴露 MySQL 接口，讓用戶幾乎在無(wú)侵入性的前提下，解決大量結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)問(wèn)題?？紤]到傳統(tǒng)行業(yè)和互聯(lián)網(wǎng)行業(yè)的代差大概在 3 年左右，另外這個(gè)時(shí)間在不斷的縮短，最近隨著 TiDB 趨于穩(wěn)定，越來(lái)越多的互聯(lián)網(wǎng)在使用 TiDB ，相信未來(lái)會(huì)成為擴(kuò)展數(shù)據(jù)庫(kù)的一個(gè)新的主流選擇。

TiDB 的應(yīng)用場(chǎng)景

應(yīng)用場(chǎng)景是典型的 OLTP 場(chǎng)景，范圍很大，覆蓋到任何企業(yè)。在關(guān)系型數(shù)據(jù)庫(kù)上遇到擴(kuò)展性問(wèn)題、同時(shí)需要強(qiáng)一致事務(wù)、需要實(shí)現(xiàn)多數(shù)據(jù)中心強(qiáng)一致和高可用，都是 TiDB 的典型用戶。TiDB 對(duì) MySQL 的支持很完善，基于目前使用著 MySQL 的用戶或企業(yè)，希望尋求更優(yōu)雅的水平擴(kuò)展方案，都是非常不錯(cuò)的選擇。

其實(shí)目前在統(tǒng)計(jì)大多數(shù)線上生產(chǎn)環(huán)境中使用的用戶基本都是互聯(lián)網(wǎng)場(chǎng)景，從 MySQL 過(guò)來(lái)。TiDB 目前暫時(shí)不支持存儲(chǔ)過(guò)程和視圖，所以前提條件是已有業(yè)務(wù)中沒(méi)有這類操作。

在項(xiàng)目開(kāi)始第一天就確定了 TiDB 最大兼容 MySQL ，黃東旭坦言， MySQL 是一個(gè)單機(jī)的數(shù)據(jù)庫(kù)，而且查詢優(yōu)化器是針對(duì)單機(jī)場(chǎng)景設(shè)計(jì)，基于這架構(gòu)上去做一個(gè)分布式數(shù)據(jù)庫(kù)的難度很大。

而此時(shí)，他們決定選擇一條更徹底的道路，就是重寫(xiě)整個(gè) SQL Parser 和查詢優(yōu)化引擎。雖然看上去幾乎是不可能完成的事情，但是實(shí)際做下來(lái)他們覺(jué)得在一個(gè)更良好設(shè)計(jì)和復(fù)雜度控制下，反而是一條更輕松的路。而選擇完全的 MySQL 兼容這個(gè)事情帶來(lái)的好處不僅限于對(duì)用戶的友好度，更重要的是能從 MySQL 社區(qū)吸取大量的測(cè)試。這對(duì)于一個(gè)數(shù)據(jù)庫(kù)產(chǎn)品來(lái)說(shuō)，做出來(lái)并不難，如何證明你是對(duì)的，這才是更重要的！黃東旭他們不斷的從 MySQL 社區(qū)收集了千萬(wàn)級(jí)的測(cè)試用例來(lái)保證每個(gè)模塊的正確性，和對(duì) MySQL 行為的一致性。

TiDB 項(xiàng)目開(kāi)源的程度

TiDB 項(xiàng)目是100% 開(kāi)源，致力于做一個(gè)具有國(guó)際水準(zhǔn)的頂級(jí)開(kāi)源項(xiàng)目，從 Github repo 本身其實(shí)很難看出來(lái)這是一個(gè)背后是國(guó)人主導(dǎo)的開(kāi)源項(xiàng)目，所有的提交記錄，所有的協(xié)作，Roadmap ，Issue tracking ，中英文文檔，以及代碼審核都是開(kāi)源的。

而項(xiàng)目已經(jīng)迭代到 Beta 4 版本，從線上用戶的反饋，主要的功能已經(jīng)基本完善穩(wěn)定。黃東旭表示，接下來(lái)重要的工作會(huì)是持續(xù)的性能優(yōu)化和繼續(xù)提升穩(wěn)定性，還有在更大容量，更惡劣嚴(yán)苛的集群環(huán)境下持續(xù)測(cè)試。當(dāng)然周邊工具，部署教程，更多的設(shè)計(jì)文檔也是在持續(xù)的豐富中。

TiDB 的未來(lái)

從更長(zhǎng)遠(yuǎn)的角度，一切東西都會(huì)運(yùn)行在云端，數(shù)據(jù)庫(kù)也不例外。在海量數(shù)據(jù)，大規(guī)模集群的前提下，關(guān)系型數(shù)據(jù)庫(kù)的設(shè)計(jì)和理論還有很多東西需要探索，這種集群規(guī)模之下，一切依賴人工的運(yùn)維都將會(huì)失效，因?yàn)槿耸菦](méi)法 scale ，數(shù)據(jù)庫(kù)需要具有自我修復(fù)和自我擴(kuò)展的能力，也只有這樣，才能更好的利用集群的計(jì)算資源，這也為什么 TiDB 團(tuán)隊(duì)對(duì)自己的定位是要做 Cloud-Native 的數(shù)據(jù)庫(kù)，他們?cè)跒槲磥?lái)做很多基礎(chǔ)性的研究和準(zhǔn)備，包含對(duì) Kubernetes 和分布式數(shù)據(jù)庫(kù)的結(jié)合上也做了很多探索性的工作。

黃東旭希望 TiDB 定義下一代關(guān)系型數(shù)據(jù)庫(kù)，未來(lái)開(kāi)發(fā)者能夠真正專注自己的業(yè)務(wù)，不用在關(guān)心數(shù)據(jù)庫(kù)有多大，并發(fā)可能會(huì)有多高，什么時(shí)候需要擴(kuò)容一下，選哪個(gè) sharding key 好等這些問(wèn)題都應(yīng)該被隱藏在一個(gè)很簡(jiǎn)單的 SQL interface 之下。

TiDB 有了非常不錯(cuò)的開(kāi)頭，他們做到了，在下一代關(guān)系型數(shù)據(jù)庫(kù)里面，每個(gè)人都能感受到這種技術(shù)所帶來(lái)生產(chǎn)力的美好！

開(kāi)源項(xiàng)目地址：https://github.com/pingcap/tidb

PS:黃東旭將在11月26號(hào)出席WOT2016大數(shù)據(jù)技術(shù)峰會(huì)，屆時(shí)在NoSQL實(shí)踐技術(shù)專場(chǎng)分享《NewSQL in action: Patterns and Tools》內(nèi)容，敬請(qǐng)關(guān)注。

WOT2016大數(shù)據(jù)技術(shù)峰會(huì)官網(wǎng)：http://wot.51cto.com/