摘要：日前，我司聯(lián)合創(chuàng)始人兼黃東旭接受了開源中國的開源訪談，公開解讀了的探索之路及未來方向。應(yīng)用場(chǎng)景上在行業(yè)內(nèi)使用更廣泛，目前涉及互聯(lián)網(wǎng)游戲金融政府電信制造業(yè)等多個(gè)領(lǐng)域。目前也與包括騰訊云在內(nèi)的多家公有云平臺(tái)完成了整合，提供公有云數(shù)據(jù)庫服務(wù)。

日前，我司聯(lián)合創(chuàng)始人兼 CTO 黃東旭接受了開源中國的【開源訪談】，公開解讀了 TiDB 的探索之路及未來方向。本文為專訪實(shí)錄~ :)

記者：王練

口述：黃東旭

黃東旭，PingCAP 的聯(lián)合創(chuàng)始人和 CTO，TiDB 的設(shè)計(jì)者和工程師，一直以來從事的基礎(chǔ)軟件和分布式系統(tǒng)的研發(fā)，很小就開始接觸編程和開源，受到開源文化和自由軟件運(yùn)動(dòng)的影響很深，是一個(gè)開源信徒，所以后來基本做東西能開源的盡量都會(huì)開源，比如早期的 Codis，現(xiàn)在的 TiDB。

技術(shù)上主要的難點(diǎn)，比較具體的我記得是在早期決定不復(fù)用 MySQL 代碼的同時(shí)還需要做到 MySQL 文法和網(wǎng)絡(luò)協(xié)議上的兼容，同時(shí)還需要在很短時(shí)間內(nèi)完成一個(gè)可用的查詢優(yōu)化器，雖然技術(shù)本身不是特別難，但是在早期確實(shí)是個(gè)工程上的挑戰(zhàn)；另外底層存儲(chǔ)上我們選用了 Rust 作為開發(fā)語言，作為一個(gè)比較新的語言，我們花了一些時(shí)間和精力幫助 Rust 社區(qū)完善一些第三方庫，比如 gRPC 的 Rust 實(shí)現(xiàn)就是我們貢獻(xiàn)和維護(hù)的。

其實(shí)遇到技術(shù)問題也談不上有什么特別的解決方案，仔細(xì)分析和思考，擁抱和相信社區(qū)，重視測(cè)試，我們的工程師和在 TiDB 社區(qū)活躍的 Committer 的能力都很強(qiáng)，我相信大方向沒問題，遇到的技術(shù)問題都是能解決的。

到現(xiàn)在，因?yàn)榍胺交疽呀?jīng)是無人區(qū)，思考得比較多的是未來數(shù)據(jù)庫的形態(tài)和一些前沿的技術(shù)，比如如何更好利用新時(shí)代的硬件，如何和云更好的整合等等。

另一個(gè)方面是商業(yè)上的難點(diǎn)，我們幾個(gè)創(chuàng)始人都是技術(shù)出身，過去并沒有銷售和市場(chǎng)的經(jīng)驗(yàn)，在早期如何搭建商業(yè)和市場(chǎng)團(tuán)隊(duì)，如何面試這方面的人才，曾經(jīng)讓我們頭疼很久，不過工程師嘛，多聊多總結(jié)，發(fā)揮學(xué)習(xí)新技術(shù)的精神去了解不同行業(yè)的東西，另外我們的投資人也幫了我們不少忙，總體來說，保持一個(gè)開放學(xué)習(xí)的心態(tài)，放低姿態(tài)多和行業(yè)里比較資深的人聊，能學(xué)到不少。

技術(shù)上有幾個(gè)重要的點(diǎn)：

大集群上的多租戶技術(shù)，這部分我們一個(gè)大的用戶 Mobike 的工程師們?yōu)?TiDB 提交了這方面很多重要的特性的實(shí)現(xiàn)和很多寶貴的建議，在這里特別感謝一下。

實(shí)時(shí) OLAP 引擎，TiSpark 項(xiàng)目，TiDB 本身是一個(gè) 100% 的 OLTP 數(shù)據(jù)庫，同時(shí)它的實(shí)時(shí)復(fù)雜分析能力也會(huì)越來越強(qiáng)，1.0 后一個(gè)重要的方向就是我們希望能夠在 HTAP 上更進(jìn)一步，打破數(shù)據(jù)庫和數(shù)據(jù)倉庫之間的界限。

進(jìn)一步減輕用戶的遷移成本，我們內(nèi)部在開發(fā)一些工具能夠極大加速數(shù)據(jù)導(dǎo)入和同步線上 MySQL 的速度，降低用戶的嘗試和使用成本。

擁抱新的硬件，這個(gè)時(shí)代，新的硬件層出不窮，Optane / NvmeSSD / 萬兆網(wǎng)卡的普及，如何設(shè)計(jì)新的數(shù)據(jù)結(jié)構(gòu)，使用新的 SDK，Bypass Kernel 使得更好的適應(yīng)新的硬件。

最后一點(diǎn)，是持續(xù)增強(qiáng)穩(wěn)定性，性能以及測(cè)試，這個(gè)是一個(gè)長(zhǎng)期的工作，優(yōu)化無止境嘛。

其實(shí)這個(gè)是一個(gè)雞生蛋蛋生雞的問題，你需要得有第一批用戶案例，才能吸引更多的用戶，我們選在這個(gè)時(shí)間點(diǎn)發(fā)布 1.0 也是因?yàn)楫a(chǎn)品已經(jīng)完成破冰，我們從 RC （Release Candidate）到 1.0 中間大約經(jīng)過了一年，這一年時(shí)間我們已經(jīng)默默的服務(wù)了很多種子用戶，在他們的生產(chǎn)系統(tǒng)中鍛煉，我們的早期客戶中已經(jīng)有系統(tǒng)穩(wěn)定運(yùn)行 TiDB 大規(guī)模集群超過一年了，在確保產(chǎn)品質(zhì)量和有足夠的用戶背書的情況下，我們這才謹(jǐn)慎的發(fā)布了 1.0，我們隨后也會(huì)持續(xù)的輸出案例，給予社區(qū)更多的信心。

其實(shí)特性需求上差異不大。在中國，大家會(huì)遇到 MySQL 的擴(kuò)展性問題，在美國也會(huì)遇到。所以這兩個(gè)市場(chǎng)對(duì)于我們這種基礎(chǔ)軟件公司來說，不會(huì)像 to C 的產(chǎn)品公司那樣難以在海外復(fù)制，基礎(chǔ)軟件領(lǐng)域是沒有國界限制的，目前我們也在布局海外市場(chǎng)。

CockroachDB 也是一個(gè)很好的項(xiàng)目，在很多人看來，TiDB 和 CockroachDB 都是為了解決關(guān)系型數(shù)據(jù)庫的可擴(kuò)展性問題，并且二者都是受 Google Spanner/F1 的啟發(fā)。 具體細(xì)節(jié)上，有以下幾點(diǎn)不同：

二者兼容性不同，TiDB 是 100% MySQL 協(xié)議兼容，CockroachDB 兼容的是 PostgreSQL 。我們的用戶可以直接使用 MySQL 的客戶端來連接 TiDB ；

架構(gòu)上的區(qū)別，TiDB 產(chǎn)品架構(gòu)是分層的，由分布式 SQL 層（TiDB）和分布式 KV 存儲(chǔ)引擎（TiKV）組成，而 CockroachDB 沒有分層，所有的東西都在一個(gè) binary 里面；

事務(wù)模型不同，雖然 TiDB 與 CockroachDB 都支持 ACID 事務(wù)，但是 TiDB 采用的是 Google Percolator 的模型，這個(gè)模型的關(guān)鍵特性是，它需要一個(gè)獨(dú)立的 timestamp allocator，CockroachDB 所采用的是與 Google 相似的 TrueTime API，但是跟 Spanner 不一樣的是，CockroachDB 并沒有原子鐘和 GPS 時(shí)鐘來保證不同數(shù)據(jù)中心時(shí)間的一致性；

TiDB 是一個(gè) HTAP 數(shù)據(jù)庫，既具備 OLTP 的強(qiáng)大在線交易能力，也具備 OLAP 的在線分析能力。CockroachDB 暫時(shí)不具備 OLAP ；

二者開發(fā)語言不同，CockroachDB 用的 Go 語言，TiDB 整體項(xiàng)目用了兩種語言，SQL 層（TiDB）用的是 Go，KV 層（TiKV）用的是 Rust。

應(yīng)用場(chǎng)景上：TiDB 在行業(yè)內(nèi)使用更廣泛，目前涉及互聯(lián)網(wǎng)、游戲、金融、政府、電信、制造業(yè)等多個(gè)領(lǐng)域。

個(gè)人認(rèn)為從傳統(tǒng)的單機(jī) SQL 到 NoSQL 只是互聯(lián)網(wǎng)公司在面對(duì)大并發(fā)量的新業(yè)務(wù)時(shí)的過度的狀態(tài)，歷史是螺旋上升的，現(xiàn)在 SQL 的回歸是大勢(shì)所趨，畢竟 SQL 是一個(gè)更好的操作數(shù)據(jù)的用戶接口。

在可見的未來，數(shù)據(jù)量會(huì)是一直在膨脹，業(yè)務(wù)會(huì)越來越復(fù)雜。我個(gè)人覺得未來的數(shù)據(jù)庫會(huì)有幾個(gè)趨勢(shì)，這也是 TiDB 項(xiàng)目追求的目標(biāo)：

數(shù)據(jù)庫會(huì)隨著業(yè)務(wù)云化，未來一切的業(yè)務(wù)都會(huì)跑在云端，不管是私有云、公有云還是混合云，運(yùn)維團(tuán)隊(duì)接觸的可能再也不是真實(shí)的物理機(jī)，而是一個(gè)個(gè)隔離的容器或者「計(jì)算資源」。這對(duì)數(shù)據(jù)庫也是一個(gè)挑戰(zhàn)，因?yàn)閿?shù)據(jù)庫天生就是有狀態(tài)的，數(shù)據(jù)總是要存儲(chǔ)在物理的磁盤上，而移動(dòng)數(shù)據(jù)的代價(jià)比移動(dòng)容器的代價(jià)可能大很多。目前 TiDB 也與包括騰訊云、UCloud 在內(nèi)的多家公有云平臺(tái)完成了整合，提供公有云數(shù)據(jù)庫服務(wù)。

多租戶技術(shù)會(huì)成為標(biāo)配，一個(gè)大數(shù)據(jù)庫承載一切的業(yè)務(wù)，數(shù)據(jù)在底層打通，上層通過權(quán)限，容器等技術(shù)進(jìn)行隔離；但是數(shù)據(jù)的打通和擴(kuò)展會(huì)變得異常簡(jiǎn)單，結(jié)合第一點(diǎn)提到的云化，業(yè)務(wù)層可以再也不用關(guān)心物理機(jī)的容量和拓?fù)洌恍枰J(rèn)為底層是一個(gè)無窮大的數(shù)據(jù)庫平臺(tái)即可，不用再擔(dān)心單機(jī)容量和負(fù)載均衡等問題。

OLAP 和 OLTP 會(huì)進(jìn)一步細(xì)分，底層存儲(chǔ)也許會(huì)共享一套，但是 SQL 優(yōu)化器這層的實(shí)現(xiàn)一定是千差萬別的。對(duì)于用戶而言，如果能使用同一套標(biāo)準(zhǔn)的語法和規(guī)則來進(jìn)行數(shù)據(jù)的讀寫和分析，會(huì)有更好的體驗(yàn)。

在未來分布式數(shù)據(jù)庫系統(tǒng)上，主從日志同步這樣落后的備份方式會(huì)被 Multi-Paxos / Raft 這樣更強(qiáng)的分布式一致性算法替代，人工的數(shù)據(jù)庫運(yùn)維在管理大規(guī)模數(shù)據(jù)庫集群時(shí)是不可能的，所有的故障恢復(fù)和高可用都會(huì)是高度自動(dòng)化的。

最后就是我前面說過的要擁抱新的硬件，要跟上新硬件的迭代速度，配合設(shè)計(jì)新的數(shù)據(jù)結(jié)構(gòu)來適應(yīng)新的硬件。