2018 年對(duì)于 TiDB 和 PingCAP 來(lái)說(shuō)是一個(gè)由少年向成年的轉(zhuǎn)換的一年，如果用一個(gè)關(guān)鍵字來(lái)概括就是「蛻變」。在這一年很欣喜的看到 TiDB 和 TiKV 在越來(lái)越多的用戶(hù)使用在了越來(lái)越廣泛的場(chǎng)景中，作為一個(gè)剛剛 3 歲多的開(kāi)源項(xiàng)目，沒(méi)有背后強(qiáng)大的社區(qū)的話(huà)，是沒(méi)有辦法取得這樣的進(jìn)展的。

同時(shí)在技術(shù)上，2018 年我覺(jué)得也交出了一份令人滿(mǎn)意的答卷，TiDB 的幾個(gè)主要項(xiàng)目今年一共合并了 4380 個(gè)提交，這幾天在整理 2018 年的 Change Log 時(shí)候，對(duì)比了一下年初的版本，這 4380 個(gè) Commits 背后代表了什么，這里簡(jiǎn)單寫(xiě)一個(gè)文章總結(jié)一下。

回想起來(lái)，TiDB 是最早定位為 HTAP 的通用分布式數(shù)據(jù)庫(kù)之一，如果熟悉我們的老朋友一定知道，我們最早時(shí)候一直都是定位 NewSQL，當(dāng)然現(xiàn)在也是。但是 NewSQL 這個(gè)詞有個(gè)問(wèn)題，到底 New 在哪，解決了哪些問(wèn)題，很難一目了然，其實(shí)一開(kāi)始我們就想解決一個(gè) MySQL 分庫(kù)分表的問(wèn)題，但是后來(lái)慢慢隨著我們的用戶(hù)越來(lái)越多，使用的場(chǎng)景也越來(lái)越清晰，很多用戶(hù)的場(chǎng)景已經(jīng)開(kāi)始超出了一個(gè)「更大的 MySQL 」的使用范圍，于是我們從實(shí)驗(yàn)室和學(xué)術(shù)界找到了我們覺(jué)得更加清晰的定義：HTAP，希望能構(gòu)建一個(gè)融合 OLTP 和 OLAP 通用型分布式數(shù)據(jù)庫(kù)。但是要達(dá)成這個(gè)目標(biāo)非常復(fù)雜，我們的判斷是如果不是從***層重新設(shè)計(jì)，很難達(dá)到我們的目標(biāo)，我們認(rèn)為這是一條更困難但是正確的路，現(xiàn)在看來(lái)，這條路是走對(duì)了，而且未來(lái)會(huì)越走越快，越走越穩(wěn)。

在 SQL 層這邊，TiDB 選擇了 MySQL 的協(xié)議兼容，一方面持續(xù)的加強(qiáng)語(yǔ)法兼容性，另一方面選擇自研優(yōu)化器和執(zhí)行器，帶來(lái)的好處就是沒(méi)有任何歷史負(fù)擔(dān)持續(xù)優(yōu)化?；仡櫧衲?**的一個(gè)工作應(yīng)該是重構(gòu)了執(zhí)行器框架，TiDB的 SQL 層還是經(jīng)典的 Volcano 模型，我們引入了新的內(nèi)存數(shù)據(jù)結(jié)構(gòu) Chunk 來(lái)批量處理多行數(shù)據(jù)，并對(duì)各個(gè)算子都實(shí)現(xiàn)了基于 Chunk 的迭代器接口，這個(gè)改進(jìn)對(duì)于 OLAP 請(qǐng)求的改進(jìn)非常明顯，在 TiDB 的 TPC-H 測(cè)試集上能看出來(lái)(https://github.com/pingcap/docs-cn/blob/master/benchmark/tpch.md)，Chunk 的引入為我們?nèi)娴南蛄炕瘓?zhí)行和 CodeGen 支持打下了基礎(chǔ)。目前在 TiKV 內(nèi)部對(duì)于下推算子的執(zhí)行還沒(méi)有使用 Chunk 改造，不過(guò)這個(gè)已經(jīng)在計(jì)劃中，在 TiKV 中這個(gè)改進(jìn)，預(yù)期對(duì)查詢(xún)性能的提升也將非常顯著。

另一方面，一個(gè)數(shù)據(jù)庫(kù)查詢(xún)引擎最核心的組件之一：優(yōu)化器，在今年也有長(zhǎng)足的進(jìn)步。我們?cè)?2017 年就已經(jīng)全面引入了基于代價(jià)的 SQL 優(yōu)化(CBO，Cost-Based Optimization)，我們?cè)诮衲旮倪M(jìn)了我們的代價(jià)評(píng)估模型，加入了一些新的優(yōu)化規(guī)則，同時(shí)實(shí)現(xiàn)了 Join Re-Order 等一系列優(yōu)化，從結(jié)果上來(lái)看，目前在 TPC-H 的測(cè)試集上，對(duì)于所有 Query，TiDB 的 SQL 優(yōu)化器大多已給出了***的執(zhí)行計(jì)劃。CBO 的另一個(gè)關(guān)鍵模塊是統(tǒng)計(jì)信息收集，在今年，我們引入了自動(dòng)的統(tǒng)計(jì)信息收集算法，使優(yōu)化器的適應(yīng)性更強(qiáng)。另外針對(duì) OLTP 的場(chǎng)景 TiDB 仍然保留了輕量的 RBO 甚至直接 Bypass 優(yōu)化器，以提升 OLTP 性能。另外，感謝三星韓國(guó)研究院的幾位工程師的貢獻(xiàn)，他們給 TiDB 引入了 Query Plan Cache，對(duì)高并發(fā)場(chǎng)景下查詢(xún)性能的提升也很明顯。另外在功能上，我們引入了 Partition Table 的支持，對(duì)于一些 Partition 特性很明顯的業(yè)務(wù)，TiDB 能夠更加高效的調(diào)度數(shù)據(jù)的寫(xiě)入讀取和更新。

一直以來(lái)，TiDB 的 SQL 層作為純 Go 語(yǔ)言實(shí)現(xiàn)的最完備的 MySQL 語(yǔ)法兼容層，很多第三方的 MySQL 工具在使用著 TiDB 的 SQL Parser，其中的優(yōu)秀代表比如小米的 Soar(https://github.com/XiaoMi/soar)。為了方便第三方更好的復(fù)用 TiDB Parser，我們?cè)?2018 年將 Parser 從主項(xiàng)目中剝離了出來(lái)，成為了一個(gè)獨(dú)立的項(xiàng)目：pingcap/parser，希望能幫到更多的人。

說(shuō)到 TiDB 的底層存儲(chǔ) TiKV 今年也有很多讓人眼前一亮的更新。在 TiKV 的基石——一致性算法 Raft 這邊，大家知道 TiKV 采用的是 Multi-Raft 的架構(gòu)，內(nèi)部通過(guò)無(wú)數(shù)個(gè) Raft Group 動(dòng)態(tài)的分裂、合并、移動(dòng)以達(dá)到動(dòng)態(tài)伸縮和動(dòng)態(tài)負(fù)載均衡。我們?cè)诮衲耆匀怀掷m(xù)在擴(kuò)展 Multi-Raft 的邊界，我們今年加入了動(dòng)態(tài)的 Raft Group 合并，以減輕元信息存儲(chǔ)和心跳通信的負(fù)擔(dān);給 Raft 擴(kuò)展了 Learner 角色(只同步 Log 不投票的角色) 為 OLAP Read 打下基礎(chǔ);給 Raft 的基礎(chǔ)算法加入了 Pre-Vote 的階段，讓整個(gè)系統(tǒng)在異常網(wǎng)絡(luò)狀態(tài)下可靠性更高。

Raft Group Merge

在性能方面，我們花了很大的精力重構(gòu)了我們單機(jī)上多 Raft Group 的線程模型(https://github.com/tikv/tikv/pull/3568)， 雖然還沒(méi)有合并到 master 分支，在我們測(cè)試中，這個(gè)優(yōu)化帶來(lái)了兩倍以上的吞吐提升，同時(shí)寫(xiě)入延遲降低至現(xiàn)在的版本的 1/2 ，預(yù)計(jì)在這兩周我們會(huì)完成這個(gè)巨大的 PR 的 Code Review，各位同學(xué)可以期待一下 :)

第三件事情是我們開(kāi)始將 TiKV 的本地存儲(chǔ)引擎的接口徹底抽象出來(lái)，目標(biāo)是能做到對(duì) RocksDB 的弱耦合，這點(diǎn)的意義很大，不管是社區(qū)還是我們自己，對(duì)新的單機(jī)存儲(chǔ)引擎支持將變得更加方便。

在 TiKV 社區(qū)這邊，今年的另外一件大事是加入了 CNCF，變成了 CNCF 的托管項(xiàng)目，也是 CNCF 基金會(huì)***個(gè)非結(jié)構(gòu)化數(shù)據(jù)庫(kù)項(xiàng)目。 后來(lái)很多朋友問(wèn)我，為什么捐贈(zèng)的是 TiKV 而不是 TiDB，其實(shí)主要的原因就像我在當(dāng)天的一條 Tweet 說(shuō)的，TiKV 更像是的一個(gè)更加通用的組件，當(dāng)你有一個(gè)可以彈性伸縮的，支持跨行 ACID 事務(wù)的 Key-Value 數(shù)據(jù)庫(kù)時(shí)，你會(huì)發(fā)現(xiàn)構(gòu)建其他很多可靠的分布式系統(tǒng)會(huì)容易很多，這在我們之后的 TiDB Hackathon 中得到了很好的體現(xiàn)。另外社區(qū)已經(jīng)開(kāi)始出現(xiàn)基于 TiKV 構(gòu)建的 Redis 協(xié)議支持，以及分布式隊(duì)列系統(tǒng)，例如meitu/titan 項(xiàng)目。作為一個(gè)基金會(huì)項(xiàng)目，社區(qū)不僅僅可以直接使用，更能夠?qū)⑺鳛闃?gòu)建其他系統(tǒng)的基石，我覺(jué)得更加有意義。類(lèi)似的，今年我們將我們的 Raft 實(shí)現(xiàn)從主項(xiàng)目中獨(dú)立了出來(lái)(pingcap/raft-rs)，也是希望更多的人能從中受益。

“……其 KV與 SQL分層的方式，剛好符合我們提供 NoSQL 存儲(chǔ)和關(guān)系型存儲(chǔ)的需求，另外，PingCAP 的文檔齊全，社區(qū)活躍，也已經(jīng)在實(shí)際應(yīng)用場(chǎng)景有大規(guī)模的應(yīng)用，公司在北京，技術(shù)交流也非常方便，事實(shí)證明，后面提到的這幾個(gè)優(yōu)勢(shì)都是對(duì)的……”

                                                                                                                                                                                                    ——美圖公司 Titan 項(xiàng)目負(fù)責(zé)人任勇全對(duì) TiKV 的評(píng)論

在 TiDB 的設(shè)計(jì)之初，我們堅(jiān)定將調(diào)度和元信息從存儲(chǔ)層剝離出來(lái)(PD)，現(xiàn)在看來(lái)，好處正漸漸開(kāi)始顯示出來(lái)。今年在 PD 上我們花了很大精力在處理熱點(diǎn)探測(cè)和快速熱點(diǎn)調(diào)度，調(diào)度和存儲(chǔ)分離的架構(gòu)讓我們不管是在開(kāi)發(fā)，測(cè)試還是上線新的調(diào)度策略時(shí)效率很高。瞬時(shí)熱點(diǎn)一直是分布式存儲(chǔ)的***敵人，如何快速發(fā)現(xiàn)和處理，我們也有計(jì)劃嘗試將機(jī)器學(xué)習(xí)引入 PD 的調(diào)度中，這是 2019 會(huì)嘗試的一個(gè)事情?？傮w來(lái)說(shuō)，這個(gè)是一個(gè)長(zhǎng)期的課題。

我在幾個(gè)月前的一篇文章提到過(guò) TiDB 為什么從 Day-1 起就 All-in Kubernetes (《十問(wèn) TiDB：關(guān)于架構(gòu)設(shè)計(jì)的一些思考》)，今年很欣喜的看到，Kubernetes 及其周邊生態(tài)已經(jīng)漸漸成熟，已經(jīng)開(kāi)始有很多公司用 Kubernetes 來(lái)運(yùn)行 Mission-critical 的系統(tǒng)，這也佐證了我們當(dāng)年的判斷。2018 年下半年，我們也開(kāi)源了我們的 TiDB Operator(https://github.com/pingcap/tidb-operator)，這個(gè)項(xiàng)目并不止是一個(gè)簡(jiǎn)單的在 K8s 上自動(dòng)化運(yùn)維 TiDB 的工具，在我們的戰(zhàn)略里面，是作為 Cloud TiDB 的重要基座，過(guò)去設(shè)計(jì)一個(gè)完善的多租戶(hù)系統(tǒng)是一件非常困難的事情，同時(shí)調(diào)度對(duì)象是數(shù)據(jù)庫(kù)這種帶狀態(tài)服務(wù)，更是難上加難，TiDB-Operator 的開(kāi)源也是希望能夠借助社區(qū)的力量，一起將它做好。

多租戶(hù) TiDB

今年還做了一件很大的事情，我們成立了一個(gè)新的部門(mén) TEP(TiDB Enterprise Platform)專(zhuān)注于商業(yè)化組件及相關(guān)的交付質(zhì)量控制。作為一個(gè)企業(yè)級(jí)的分布式數(shù)據(jù)庫(kù)，TiDB 今年完成了商業(yè)化從0到1的跨越，越來(lái)越的付費(fèi)客戶(hù)證明 TiDB 的核心的成熟度已經(jīng)可以委以重任，成立 TEP 小組也是希望在企業(yè)級(jí)產(chǎn)品方向上繼續(xù)發(fā)力。從 TiDB-Lightning(MySQL 到 TiDB 高速離線數(shù)據(jù)導(dǎo)入工具)到 TiDB-DM(TiDB-DataMigration，端到端的數(shù)據(jù)遷移-同步工具)能看到發(fā)力的重點(diǎn)在讓用戶(hù)無(wú)縫的從上游遷移到 TiDB 上。另一方面，TiDB-Binlog 雖然不是今年的新東西，但是今年這一年在無(wú)數(shù)個(gè)社區(qū)用戶(hù)的場(chǎng)景中鍛煉，越來(lái)越穩(wěn)定。做工具可能在很多人看來(lái)并不是那么「高科技」， 很多時(shí)候也確實(shí)是臟活累活，但是這些經(jīng)過(guò)無(wú)數(shù)用戶(hù)場(chǎng)景打磨的周邊工具和生態(tài)才是一個(gè)成熟的基礎(chǔ)軟件的護(hù)城河和競(jìng)爭(zhēng)壁壘，在 PingCAP 內(nèi)部，負(fù)責(zé)工具和外圍系統(tǒng)研發(fā)的團(tuán)隊(duì)規(guī)模幾乎和內(nèi)核團(tuán)隊(duì)是 1:1 的配比，重要性可見(jiàn)一斑。

在使用場(chǎng)景上，TiDB 的使用規(guī)模也越來(lái)越大，下面這張圖是我們統(tǒng)計(jì)的我們已知 TiDB 的用戶(hù)，包括上線和準(zhǔn)上線的用戶(hù)，從 1.0 GA 后，幾乎是以一個(gè)指數(shù)函數(shù)的曲線在增長(zhǎng)，應(yīng)用的場(chǎng)景也從簡(jiǎn)單的 MySQL Sharding 替代方案變成橫跨 OLTP 到實(shí)時(shí)數(shù)據(jù)中臺(tái)的通用數(shù)據(jù)平臺(tái)組件。

今年幾個(gè)比較典型的用戶(hù)案例，從 美團(tuán) 的橫跨 OLTP 和實(shí)時(shí)數(shù)倉(cāng)的深度實(shí)踐，到 轉(zhuǎn)轉(zhuǎn) 的 All-in TiDB 的體驗(yàn)，再到 TiDB 支撐的北京銀行的核心交易系統(tǒng)?？梢钥吹?，這些案例從互聯(lián)網(wǎng)公司的離線線數(shù)據(jù)存儲(chǔ)到要求極端 SLA 的傳統(tǒng)銀行核心交易系統(tǒng)，TiDB 在這些場(chǎng)景里面都發(fā)光發(fā)熱，甚至有互聯(lián)網(wǎng)公司(轉(zhuǎn)轉(zhuǎn))都喊出了 All-in TiDB 的口號(hào)，我們非常珍視這份信任，一定盡全力做出漂亮的產(chǎn)品，高質(zhì)量的服務(wù)好我們的用戶(hù)和客戶(hù)。另一方面，TiDB 也慢慢開(kāi)始產(chǎn)生國(guó)際影響力的，在線視頻巨頭葫蘆軟件(Hulu.com)，印度***的在線票務(wù)網(wǎng)站 BookMyShow，東南亞***的電商之一 Shopee 等等都在大規(guī)模的使用 TiDB，在北美和歐洲也已經(jīng)不少準(zhǔn)上線和測(cè)試中的的巨頭互聯(lián)網(wǎng)公司。