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

作者：黃東旭

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

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

在 SQL 層這邊，TiDB 選擇了 MySQL 的協議兼容，一方面持續的加強語法兼容性，另一方面選擇自研優化器和執行器，帶來的好處就是沒有任何歷史負擔持續優化。回顧今年最大的一個工作應該是重構了執行器框架，TiDB的 SQL 層還是經典的 Volcano 模型，我們引入了新的內存數據結構 Chunk 來批量處理多行數據，并對各個算子都實現了基于 Chunk 的迭代器接口，這個改進對于 OLAP 請求的改進非常明顯，在 TiDB 的 TPC-H 測試集上能看出來（https://github.com/pingcap/docs-cn/blob/master/benchmark/tpch.md），Chunk 的引入為我們全面的向量化執行和 CodeGen 支持打下了基礎。目前在 TiKV 內部對于下推算子的執行還沒有使用 Chunk 改造，不過這個已經在計劃中，在 TiKV 中這個改進，預期對查詢性能的提升也將非常顯著。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Make it right before making it fast.（穩定，先做穩，再做快。）

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

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

這個方法有以下好處：

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

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

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

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

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

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

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

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

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

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