新年伊始，突然發現 tidb 又一次被國際友人頂上了 hackernews 首頁前十，借着這個由頭有友人約稿說想讓我寫一下對于這個資料庫的過去和未來的一些想法和規劃，正好這個周末偷得半日閑，于是趕緊動筆，不過我本人一向懶得總結，同時不太希望做太遠的計劃，是以就想到哪寫到哪了 。
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 篇文章說這個事情，翻翻 pingcap 過去的文章清單就行。
過去就不廢話太多了，今天主要想聊的是未來，前段時間和褚霸聊天提到做資料庫不易，特别對于公有雲來說隻要開了口子，無數使用者就能玩出花來，大量的精力需要花在周邊的各種旁路系統。對于創業的團隊來說，做的又是一個關系型資料庫這樣的東西，能做的或者需要做的東西實在太多，如何控制住自己的欲望，專注在最重要的事情上面我認為是最重要的，這個看起來容易，但是做起來難，比如：
你的團隊都是一些非常聰明的小朋友（老朋友），對于一個技術問題，總能發散出很多想法和特别聰明的解決辦法，有的确實很驚豔，但是大多數時候，這樣的方案并非最簡潔同時最容易正确實作的，這時候就需要站出來狠狠拍掉，記住 make it right before making it faster，複雜性才是你最大的敵人。
你的一個客戶說，實作 xx 功能或者接入 xx 系統，可能這個幾百萬的單就拿下了，你做還是不做？
我自認為，過去的一年多，在禁欲方面 tidb 做得還是蠻不錯的，相比友商 cockroachdb 好不少，目前 tidb 已經在 460 個執行個體規模的叢集上高壓力穩定的運作，我們能承諾使用者可以在生産環境安心使用，至少這個是領先友商的，2017 年也要會保持，rc1 的釋出标志着接口和功能的穩定，至少今年技術上的主要目标是進一步的性能優化，更高的相容性以及更好的使用者部署和使用體驗，新功能開發和大規模的重構應該是不會發生的。
在性能優化上的一些想法，其實分兩個比較大的方面，一個是 sql 優化器方面，另一個是 kv 層的吞吐。
先說 sql 優化器方面，其實在分布式 sql 優化器方面，現在 tidb 的優化器架構已經完成了幾次大的重構，基于代價的優化器（cbo）架構已經有了，而且因為沒什麼曆史包袱，是以 smp 方面采用了很多比較新的優化技巧（可以參考 tidb 的子查詢優化，聚合下推等技巧），就目前線上使用者的 case 來看，已經能解決我們目前見到的大部分問題，而且簡單評估了一下現有的分布式資料庫，優化器這邊 tidb 在 sql 上的表現應該是屬于最優秀的集團中。2017 年的目标仍然是提高在 smp 方面的能力，一方面嘗試下推更多的算子，一方面嘗試分布式的 cbo，可能更好的解決索引選擇和 join reordering 的問題；另一方面在執行器方面，其實 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 晶片看看能否有什麼優化的地方。