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 Merge

在性能方面，我們花了很大的精力重構了我們單機上多 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 的開源也是希望能夠借助社區的力量，一起將它做好。

多租戶 TiDB

今年還做了一件很大的事情，我們成立了一個新的部門 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，在北美和歐洲也已經不少準上線和測試中的的巨頭互聯網公司。