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

作者：黃東旭

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這個方法有以下好處：

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

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

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

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

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

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

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

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

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

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