關於 TiDB 2016 技術上的總結和對 2017 年的一些想法

最

近 TiDB 又一次被國際友人頂上了 HackerNews 首頁前十，大家討論得熱火朝天的。

隨即，TiDB RC1 發布的消息被德國最熱的 IT geek 新聞網站 heise.de 報道；與此同時 TiDB 在 GitHub 上被推到了 Go Trending 的頭條。

作為一個中國的數據庫開源項目，這個趨勢很讓我們自豪。本文為 InfoQ 對黃東旭的約稿，復盤 TiDB 並回顧 2016 年的幾個很重要的設計決定和 17 年想要做的方向。

TiDB 的 2016

TiDB 是一個大概開始了兩年的項目，從最早的 3 個人到現在背後目前大約 30 多個活躍開發者，包括周邊的工具和 CI ，可以說是一個凝結了我們大量心血的一個項目。這個項目的開始的起點是很高的，當時的想法是要麽別做，要麽就做到最好，當時（即使到了現在）全球社區內都沒有一個令人滿意的面向 OLTP 的分布式數據庫，所以為什麽不做？首先盡量能徹底的解決 mysql 的擴展性問題，並發展出一個面向雲時代的分布式關系型數據庫的標準。

整個 TiDB 項目群從分布式存儲到 SQL 優化器，除了底層的 RocksDB 外，其他都是以大規模的 Scale-out 為前提重新設計和實現，由於歷史包袱比較小加上早期設計上的一些比較正確的決定，當然最主要也得力於非常強悍的各位 Committers，整個項目以非常驚人的叠代速度演進，2016 年 12 月底，正式發布了 RC1，此時已經達到了相當高的成熟度，也有不少用戶已經將 TiDB 使用在了生產環境，也算是完成了對社區的承諾。回顧過去，最重要的設計決定我之前在我的朋友圈裏也提到過，這裏還是在贅述一下：

MySQL 語法和網絡協議的兼容，這讓我們得以吸收 MySQL 社區大量的測試用例，以保證高速叠代過程中的軟件質量不至於失控，當然這個決定對於用戶的推廣也是很重要的。

高度模塊化，這點可能就是和友商 CockroachDB 非常不一樣的，我其實比較反感各種 P2P 模型，從 Codis 的設計與 Redis Cluster 差異就能看出來，去中心化也不一定就只有 P2P，從更宏觀的抽象上來看，總是可以分層的，而且 P2P 模型帶來的復雜度其實非常難以控制，雖然好處也是比較明顯，就是部署的組件少了點，但是呢，比起後續的升級維護成本，犧牲掉的開發叠代速度來說，這個好處基本不值一提，更何況部署的問題有無數種方法可以解決，比如 TiDB 就有一鍵部署的方案。TiDB 的存儲層每層接口抽象非常薄且清晰，不允許出現跨越層次的調用的情況，主要是為了控制復雜度和提高開發者的並發度。

編程語言的選擇，Go 和 Rust，事後看來是對於我們這個團隊來說最好的選擇，雖然當時做這個決定也很艱難，回頭看看確實也很大膽，但是我覺得我們還是基本做到了不帶有任何個人感情色彩，一切通過數據和試驗做出的判斷。

極端嚴格的 Code Review、自動化測試、CI 流程，這個就不提了，在很多會議上提到過，之前劉奇也發了 3 篇文章說這個事情。（原文鏈接請點擊： 分布式系統測試那些事兒——理念 ； 分布式系統測試那些事兒——錯誤註入 ； 分布式系統測試那些事兒——信心的毀滅與重建 ）

接下來的目標

過去就不廢話太多了，今天主要想聊的是未來，前段時間和褚霸聊天提到做數據庫不易，特別對於公有雲來說只要開了口子，無數用戶就能玩出花來，大量的精力需要花在周邊的各種旁路系統。對於創業的團隊來說，做的又是一個關系型數據庫這樣的東西，能做的或者需要做的東西實在太多，如何控制住自己的欲望，專註在最重要的事情上面我認為是最重要的，這個看起來容易，但是做起來難，比如：

你的團隊都是一些非常聰明的小朋友（老朋友），對於一個技術問題，總能發散出很多想法和特別聰明的解決辦法，有的確實很驚艷，但是大多數時候，這樣的方案並非最簡潔同時最容易正確實現的，這時候就需要站出來狠狠拍掉，記住 make it right before making it faster，復雜性才是你最大的敵人。

你的一個客戶說，實現 xx 功能或者接入 xx 系統，可能這個幾百萬的單就拿下了，你做還是不做？

我自認為，過去的一年多，在禁欲方面 TiDB 做得還是蠻不錯的，目前 TiDB 已經在 469 個實例規模的集群上高壓力穩定的運行，這個社區的友商們應該還沒有能做到的，我們能承諾用戶可以在生產環境安心使用，這個也是領先友商的，2017 年也要會保持，RC1 的發布標誌著接口和功能的穩定，至少今年技術上的主要目標是進一步的性能優化，更高的兼容性以及更好的用戶部署和使用體驗，新功能開發和大規模的重構應該是不會發生的。

在性能優化上的一些想法，其實分兩個比較大的方面，一個是 SQL 優化器方面，另一個是 KV 層的吞吐。

先說 SQL 優化器方面，其實在分布式 SQL 優化器方面，現在 TiDB 的優化器框架已經完成了幾次大的重構，基於代價的優化器（CBO）框架已經有了，而且因為沒什麽歷史包袱，所以 SMP 方面采用了很多比較新的優化技巧（可以參考 TiDB 的子查詢優化，聚合下推等技巧），就目前線上用戶的 case 來看，已經能解決我們目前見到的大部分問題，而且簡單評估了一下現有的分布式數據庫，優化器這邊 TiDB 在 SQL 上的表現應該是屬於最優秀的集團中。

2017 年的目標仍然是提高在 SMP 方面的能力，一方面嘗試下推更多的算子，另一方面嘗試分布式的 CBO，可能更好的解決索引選擇和 join reordering 的問題，當然 CBO 這邊還有很多理論上的問題需要解決，比如傳統的直方圖在分布式場景下就會有一些問題，我們也有一些改進的方法；另一方面在執行器方面，其實 TiDB 的潛力很大，目前在 OLAP 裏面常用的 vectorized 和 codegen 等技巧，其實在 TiDB 裏面還沒有，這部分如果完成，對於大部分掃描，聚合的性能應該還能有若幹倍的提升空間。

另一方面，TiDB 在 MPP 方面還比較謹慎，雖然這個是必經之路，但是我覺得目前還沒有見到非 MPP 不可的場景，另外純粹的 OLAP 場景也不是 TiDB 的目標，就像我一再強調的: TiDB 是一個 100% OLTP + 80% OLAP 的 Hybrid 的數據庫，這 20% 的非得 MPP 解決的問題，我們會嘗試接入 Spark SQL，並非簡單的實現一個 connector, 而是在 TiKV 層面上去實現 Spark SQL 的算子，能讓 Spark 高效的從 TiKV 按需加載數據和下推算子。這步完成後，應該能做到：一份存儲，多個可插拔查詢引擎（TiDB / Spark SQL），這部分完成後相信大部分 Hybrid 場景 TiDB 都能高效的解決，而且和 Spark 的對接能夠讓我們更加順利的融入 OLAP 生態，這個應該會在 2017 年做。

另一方面，KV 層的吞吐提升也包含幾個方面：

▲ Raft 狀態機本身的優化，這個其實我們和 etcd 這邊一直在合作，比如異步 log apply 等，目前已經在 2017 年初合並到 TiKV 主幹，這個做完後，TiKV 的 raft store 的吞吐大概能有 30% 左右的提升。

▲ 事務模型，其實雖然理論上只有 2PC 一種搞法，而且目前來看 Percolator 的模型也沒啥問題，但是針對不同的 Workload 其實還是有優化的空間，對於高並發底沖突的小事務和沖突率比較高的大事務，其實是有不同的優化策略在保證安全的情況下提升吞吐的，在這方面我有一些新的想法，以後有機會單獨寫一下。

▲ RocksDB，選擇 RocksDB 簡直太正確了，RocksDB 5.0 的優化很多都能對 TiKV 的用戶直接受益，但是唯一有點不爽的是 RockDB 的 C API 的更新速度並沒有 C++ 的 API 更新速度快，不過這個問題也不大，TiKV 這邊會加一層 wrapper 來保證能夠使用最新的 C++ API，另外一方面 rust 官方也正在對 C++ library 做更好的兼容。

▲ 硬件，這個是 2017 年我們一個很重要的嘗試，我也會投很多精力在這個方面，軟件層面的優化其實是比較有限的而且是有天花板的，可能費很大的精力換來 10% 的提升就很了不起了，但是現在我們正處於一個硬件快速變革的時間點，SSD、NVMe 、PCIe FPGA 已經進入大家的視野之中，可能硬件上的進步會能帶來數量級的性能提升，這個是純軟件很難做到的。

最近看了一篇論文提到一個新的名詞：In-Stroage Computing，我隱約覺得專有硬件加速可能也是基礎軟件未來的一個重要的趨勢，雖然分布式系統一定是未來，但是性能這種東西是越高越好，也許原來 10 個節點的業務，現在通過硬件上的改進，結果只需要 3 節點就搞定了，也是一個可觀的進步。今年我們會嘗試將一些數據庫邏輯在 FPGA 上實現，通過 PCIe 接口的板子提供針對數據庫的硬件加速，另外我們也在和 Intel 合作，比如針對 Intel 的一些新型號的 CPU 的旁路 FPGA 芯片看看能否有什麽優化的地方。

分布式 NewSQL 數據庫

www.pingcap.com

文章來源：