摘要：作為一個(gè)企業(yè)級(jí)的分布式數(shù)據(jù)庫，今年完成了商業(yè)化從到的跨越，越來越多的付費(fèi)客戶證明的核心的成熟度已經(jīng)可以委以重任，成立小組也是希望在企業(yè)級(jí)產(chǎn)品方向上繼續(xù)發(fā)力。

作者：黃東旭

2018 年對于 TiDB 和 PingCAP 來說是一個(gè)由少年向成年的轉(zhuǎn)換的一年，如果用一個(gè)關(guān)鍵字來概括就是「蛻變」。在這一年很欣喜的看到 TiDB 和 TiKV 在越來越多的用戶使用在了越來越廣泛的場景中，作為一個(gè)剛剛 3 歲多的開源項(xiàng)目，沒有背后強(qiáng)大的社區(qū)的話，是沒有辦法取得這樣的進(jìn)展的。
同時(shí)在技術(shù)上，2018 年我覺得也交出了一份令人滿意的答卷，TiDB 的幾個(gè)主要項(xiàng)目今年一共合并了 4380 個(gè)提交，這幾天在整理 2018 年的 Change Log 時(shí)候，對比了一下年初的版本，這 4380 個(gè) Commits 背后代表了什么，這里簡單寫一個(gè)文章總結(jié)一下。

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

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

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

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

說到 TiDB 的底層存儲(chǔ) TiKV 今年也有很多讓人眼前一亮的更新。在 TiKV 的基石——一致性算法 Raft 這邊，大家知道 TiKV 采用的是 Multi-Raft 的架構(gòu)，內(nèi)部通過無數(shù)個(gè) Raft Group 動(dòng)態(tài)的分裂、合并、移動(dòng)以達(dá)到動(dòng)態(tài)伸縮和動(dòng)態(tài)負(fù)載均衡。我們在今年仍然持續(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)下可靠性更高。

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

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

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

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

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

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

今年還做了一件很大的事情，我們成立了一個(gè)新的部門 TEP（TiDB Enterprise Platform）專注于商業(yè)化組件及相關(guān)的交付質(zhì)量控制。作為一個(gè)企業(yè)級(jí)的分布式數(shù)據(jù)庫，TiDB 今年完成了商業(yè)化從0到1的跨越，越來越多的付費(fèi)客戶證明 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)在讓用戶無縫的從上游遷移到 TiDB 上。另一方面，TiDB-Binlog?雖然不是今年的新東西，但是今年這一年在無數(shù)個(gè)社區(qū)用戶的場景中鍛煉，越來越穩(wěn)定。做工具可能在很多人看來并不是那么「高科技」， 很多時(shí)候也確實(shí)是臟活累活，但是這些經(jīng)過無數(shù)用戶場景打磨的周邊工具和生態(tài)才是一個(gè)成熟的基礎(chǔ)軟件的護(hù)城河和競爭壁壘，在 PingCAP 內(nèi)部，負(fù)責(zé)工具和外圍系統(tǒng)研發(fā)的團(tuán)隊(duì)規(guī)模幾乎和內(nèi)核團(tuán)隊(duì)是 1:1 的配比，重要性可見一斑。

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

今年幾個(gè)比較典型的用戶案例，從 美團(tuán) 的橫跨 OLTP 和實(shí)時(shí)數(shù)倉的深度實(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 在這些場景里面都發(fā)光發(fā)熱，甚至有互聯(lián)網(wǎng)公司（轉(zhuǎn)轉(zhuǎn)）都喊出了 All-in TiDB 的口號(hào)，我們非常珍視這份信任，一定盡全力做出漂亮的產(chǎn)品，高質(zhì)量的服務(wù)好我們的用戶和客戶。另一方面，TiDB 也慢慢開始產(chǎn)生國際影響力的，在線視頻巨頭葫蘆軟件（Hulu.com），印度最大的在線票務(wù)網(wǎng)站 BookMyShow，東南亞最大的電商之一 Shopee 等等都在大規(guī)模的使用 TiDB，在北美和歐洲也已經(jīng)不少準(zhǔn)上線和測試中的的巨頭互聯(lián)網(wǎng)公司。

簡單回顧了一下過去的 2018 年，我們看看未來在哪里。

其實(shí)從我們在 2018 年做的幾個(gè)比較大的技術(shù)決策就能看到，2019 年將是上面幾個(gè)方向的延續(xù)。大的方向的幾個(gè)指導(dǎo)思想是：

Predicable. （靠譜，在更廣泛的場景中，做到行為可預(yù)測。）

Make it right before making it fast.（穩(wěn)定，先做穩(wěn)，再做快。）

Ease of use. （好用，簡單交給用戶，復(fù)雜留給自己。）

對于真正的 HTAP 場景來說，最大的挑戰(zhàn)的是如何很好的做不同類型的 workload 隔離和數(shù)據(jù)結(jié)構(gòu)根據(jù)訪問特性自適應(yīng)。我們在這個(gè)問題上給出了自己的答案：通過拓展 Raft 的算法，將不同的副本存儲(chǔ)成異構(gòu)的數(shù)據(jù)結(jié)構(gòu)以適應(yīng)不同類型的查詢。

這個(gè)方法有以下好處：

本身在 Multi-Raft 的層面上修改，不會(huì)出現(xiàn)由數(shù)據(jù)傳輸組件造成的瓶頸（類似 Kafka 或者 DTS），因?yàn)?Multi-Raft 本身就是可擴(kuò)展的，數(shù)據(jù)同步的單位從 binlog，變成 Raft log，這個(gè)效率會(huì)更高，進(jìn)一步降低了同步的延遲。

更好的資源隔離，通過 PD 的調(diào)度，可以真正將不同的副本調(diào)度到隔離的物理機(jī)器上，真正做到互不影響。

在執(zhí)行器方面，我們會(huì)繼續(xù)推進(jìn)向量化，不出意外的話，今年會(huì)完成所有算子的全路徑的向量化執(zhí)行。

這個(gè) HTAP 方案的另一個(gè)關(guān)鍵是存儲(chǔ)引擎本身。2019 年，我們會(huì)引入新的存儲(chǔ)引擎，當(dāng)然第一階段仍然會(huì)繼續(xù)在 RocksDB 上改進(jìn)，改進(jìn)的目標(biāo)仍然是減小 LSM-Tree 本身的寫放大問題。選用的模型是 WiscKey （FAST16，https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf ），WiscKey 的核心思想是將 Value 從 LSM-Tree 中剝離出來，以減少寫放大，如果關(guān)注 TiKV 的朋友，已經(jīng)能注意到我們已經(jīng)在前幾天將一個(gè)新存儲(chǔ)引擎 Titan（PingCAP 的 Titan，很遺憾和美圖那個(gè)項(xiàng)目重名了） 合并到了 TiKV 的主干分支，這個(gè) Titan 是我們在 RocksDB 上的 WiscKey 模型的一個(gè)實(shí)現(xiàn)，除了 WiscKey 的核心本身，我們還加入了對小 KV 的 inline 等優(yōu)化，Titan 在我們的內(nèi)部測試中效果很好，對長度隨機(jī)的 key-value 寫入的吞吐基本能達(dá)到原生 RocksDB 的 2 - 3 倍，當(dāng)然性能提升并不是我最關(guān)注的，這個(gè)引擎對于 TiDB 最大的意義就是，這個(gè)引擎將讓 TiDB 適應(yīng)性更強(qiáng)，做到更加穩(wěn)定，更加「可預(yù)測」。

在 Titan 走向穩(wěn)定的同時(shí)，我們也在調(diào)研從頭構(gòu)建一個(gè)更適合 TiDB 的 OLTP workload 的存儲(chǔ)引擎，前面說到 2018 年做了抽象 TiKV 的本地存儲(chǔ)引擎的事情就是為了這個(gè)打基礎(chǔ)，當(dāng)然我們?nèi)匀粫?huì)走 LSM-Tree 的路線。這里多提一句，其實(shí)很多人都誤解了 LSM-Tree 模型的真正優(yōu)勢，在我看來并不是性能，而是：做到可接受的性能的同時(shí)，LSM-Tree 的實(shí)現(xiàn)非常簡單可維護(hù)，只有簡單的東西才可以依賴，這個(gè)決定和我們在 Raft 與 Paxos 之間的選擇偏好也是一致的。另外 LSM-Tree 的設(shè)計(jì)從宏觀上來說，更加符合「冷熱分層」以適配異構(gòu)存儲(chǔ)介質(zhì)的想法，這個(gè)我相信是未來在存儲(chǔ)硬件上的大趨勢。

至于在 OLAP 的存儲(chǔ)引擎這邊，我們走的就是純列式存儲(chǔ)的路線了，但是會(huì)和傳統(tǒng)的 Columnar 數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)不太一樣，這塊的進(jìn)展，我們會(huì)在 1 月 19 號(hào)的 TiDB DevCon 上首秀，這里先賣個(gè)關(guān)子。

另一個(gè)大的方向是事務(wù)模型，目前來說，TiDB 從誕生起，事務(wù)模型就沒有改變過，走的是傳統(tǒng)的 Percolator 的 2PC。這個(gè)模型的好處是簡單，吞吐也不是瓶頸，但是一個(gè)比較大的問題是延遲，尤其在跨數(shù)據(jù)中心的場景中，這里的延遲主要表現(xiàn)在往 TSO 拿時(shí)間戳的網(wǎng)絡(luò) roundtrip 上，當(dāng)然了，我目前仍然認(rèn)為時(shí)鐘（TSO）是一個(gè)必不可少組件，在不降低一致性和隔離級(jí)別的大前提下也是目前我們的最好選擇，另外 Percolator 的模型也不是沒有辦法對延遲進(jìn)行優(yōu)化，我們其實(shí)在 2018 年，針對 Percolator 本身做了一些理論上的改進(jìn)，減少了幾次網(wǎng)絡(luò)的 roundtrip，也在年中書寫了新的 2PC 改進(jìn)的完整的 TLA+ 的證明（https://github.com/pingcap/tla-plus/blob/master/OptimizedCommitTS/OptimizedCommitTS.tla），證明了這個(gè)新算法的正確性，2019 年在這塊還會(huì)有比較多的改進(jìn)，其實(shí)我們一直在思考，怎么樣能夠做得更好，選擇合適的時(shí)機(jī)做合適的優(yōu)化。另外一方面，在事務(wù)模型這方面，2PC 在理論和工程上還有很多可以改進(jìn)的空間，但是現(xiàn)在的當(dāng)務(wù)之急繼續(xù)的優(yōu)化代碼結(jié)構(gòu)和整體的穩(wěn)定性，這部分的工作在未來一段時(shí)間還是會(huì)專注在理論和證明上。另外一點(diǎn)大家可以期待的是，2019 年我們會(huì)引入安全的 Follower/Learner Read，這對保持一致性的前提下讀的吞吐會(huì)提升，另外在跨數(shù)據(jù)中心的場景，讀的延遲會(huì)更小。

差不多就這些吧，最后放一句我特別喜歡的丘吉爾的一句名言作為結(jié)尾。

Success is not final, failure is not fatal: it is the courage to continue that counts.

成功不是終點(diǎn)，失敗也并非終結(jié)，最重要的是繼續(xù)前進(jìn)的勇氣。