勢高，則圍廣：TiDB 的架構演進哲學

本文來源 | PingCAP微信公衆號
做者 | PingCAP CEO劉奇，本文根據他在第 100 期 Infra Meetup 上的演講整理，預計閱讀時間爲 30 分鐘，建議先收藏。

你們可能知道我是 PingCAP CEO，可是不知道的是，我也是 PingCAP 的產品經理，應該也是最大的產品經理，是對於產品重大特性具備一票否決權的人。中國有一類產品經理是這樣的，別人有的功能咱們通通都要有，別人沒有的功能，咱們也通通都要有，因此你們看到傳統的國內好多產品就是一個超級巨無霸，功能巨多、巨難用。因此我在 PingCAP 的一個重要職責是排除掉「看起來應該須要但實際上不須要」的那些功能，保證咱們的產品足夠的專一、足夠聚焦，同時又具備足夠的彈性。

01最初的三個基本信念

本次分享題目是《TiDB 的架構演進哲學》，既然講哲學那確定有故事和教訓，不然哲學從哪兒來呢？但從另外的角度來講，通常你們來說哲學就先得有信念。有一個內容特別扯的美劇叫作《美國衆神》，裏面核心的一條思路是「你相信什麼你就是什麼」。其實人類這麼多年來，基本上也是朝這條線路在走的，人類對於未知的東西很難作一個很精確的推導，這時信念就變得很是重要了。

圖 1 最初的基本信念

實際上，咱們開始作 TiDB 這個產品的時候，第一個信念就是相信雲是將來。當年 K8s 還沒火，咱們就堅決的擁抱了 K8s。第二是不依賴特定硬件、特定的雲廠商，也就是說 TiDB 的設計方向是但願能夠 Run 在全部環境上面，包括公有云私有云等等。第三是能支持多種硬件，你們都知道咱們支持 X8六、AMD6四、ARM 等等，可能你們不清楚的是 MIPS，MIPS 典型表明是龍芯，除此以外，TiDB 將來還能夠在 GPU 上跑（TiFlash 的後續工做會支持 GPU）。

02早期用戶故事

一、Make it work

有一句話大概是「眼睛裏面寫滿了故事，臉上沒有一點滄桑」，其實現實是殘酷的，歲月必定會給你滄桑的。咱們早期的時候，也有相對比較難的時候，這時候就有一些故事關於咱們怎麼去經歷、怎麼渡過的。

首先你們作產品以前確定先作用戶調研，這是通用的流程，咱們當初也作過這個事，跟用戶聊。咱們一般會說：「咱們要作一個分佈式數據庫，自動彈性伸縮，能解決分庫分表的問題，你會用嗎？」用戶說「那確定啊，如今的分庫分表太痛苦了。」這是最初咱們獲取需求最普通的方式，也是咱們最容易掉入陷阱的方式，就好像「我有一百萬，你要不要？確定要。」「我有一瓶水，喝了以後就健康無比，延年益壽你要不要？確定要。」很容易就獲得相似的結論。

因此這個一句話結論的代價是咱們進行了長達兩年的開發。在這兩年的時間裏，咱們肯定了不少的技術方向，好比最初 TiDB 就決定是分層的。很顯然一個複雜的系統若是沒有分層，基本上沒有辦法很好的控制規模和複雜度。TiDB 分兩層，一層是 SQL 層，一層是 key-value 層，那麼到底先從哪個層開始寫呢？其實從哪層開始均可以，可是總要有一個前後，如何選擇？

這裏就涉及到 TiDB 的第一條哲學。咱們作一個產品的時候會不斷面臨選擇，那每次選擇的時候核心指導思想是什麼？核心思想是能一直指導咱們持續往前去迭代，因此咱們第一條哲學就是：永遠站在離用戶更近的地方去考慮問題。

爲何咱們會定義這樣一條哲學？由於離用戶越近越能更快的獲得用戶的反饋，更快的驗證你的想法是否是可行的。顯然 SQL 層離用戶更近，因此咱們選擇從 SQL 層寫起。其實一直到如今，絕大多數用戶用 TiDB 的時候根本感覺不到 KV 層的存在，用戶寫的都是 SQL，至於底層存儲引擎換成了別的，或者底層的 RocksDB 作了不少優化和改進，這些變化對於用戶關注的接口來講是不可見的。

選擇從 SQL 層開始寫以後，接下來面臨的問題就是怎麼作測試，怎麼去更好的作驗證，怎麼讓整個架構，先可以完整跑起來。

在軟件開發領域有一條很是經典的哲學：「Make it work, make it right, make it fast」。我想你們每個學軟件開發的人，或者每個學計算機的人可能都聽過這樣一句話。因此當時咱們就作另一個決定，先在已有的 KV 上面構建出一個原形，用最短的時間讓整個系統可以先能 work。

咱們在 2015 年的 9 月份開源了第一個版本，當時是沒有存儲層的，須要接在 HBase 上。當這個系統能跑起來以後，咱們的第一想法是趕忙找到當初調研時說要用的那些用戶，看看他們是什麼想法，儘快的去驗證咱們的想法是否是可行的。由於不少人作產品思惟屬於自嗨型，「我作的東西最厲害，只要一推出去確定一羣人蜂擁而至。」抱有這種想法的人太多了，實際上，只有儘快去驗證纔是惟一的解決之道，避免產品走入誤區。

圖 2 與調研用戶第二次對話

然而當我跟用戶講，你須要先裝一個 Hadoop，可能還要裝一組 Zookeeper，但用戶說：「我只想要一個更強大的 MySQL，可是讓我裝這一堆東西，你是解決問題仍是引入問題？」

這個問題有什麼解決辦法呢？一個辦法是你去解決用戶，能夠經過銷售或者經過某些關係跟用戶聊，顯然這是一個不靠譜的思路。做爲一個產品型的公司，咱們很快就否了這個想法。用戶的本質要求是：你不要給我裝一堆的東西，要真正解決個人問題。因此咱們立刻開始啓動分佈式 KV 的開發工做，完全解決掉這個問題，知足用戶的要求。

圖 3 開發 TiKV 前的技術考量

開始開發 KV 層時候又會面臨不少技術選擇，咱們有不少考量（如圖 3）。

第一點，咱們認爲做爲數據庫最重要的是正確性。假設這個數據庫要用在金融行業，用在銀行、保險、證券，和其餘一些很是關鍵的場合的時候，正確性就是無比重要的東西。沒有人會用一個不正確的數據庫。

第二點是實現簡潔、易用。用戶對於一個不簡潔、不易用的東西是沒法接受的，因此咱們當時的一個想法是必定要作得比 HBase 更加易用，代碼量也要比 HBase 小，因此時至今天 TiDB 代碼量仍然是比 HBase 小得多，大約還不到 HBase 的十分之一。

第三點考慮是擴展性。 TiDB 不只在總體上是分層的，在存儲層 TiKV 內部也是分層的，因此有很是好的擴展性，也支持 Raw KV API、Transaction API，這個設計後來也收穫了不少用戶的支持，好比一點資訊的同窗就是用的 Raw KV API。

第四點就是要求高性能低延遲。你們對於數據庫的性能和延遲的追求是沒有止境的，可是咱們當時並無把太多精力花在高性能低延遲上。剛纔說到咱們有一條哲學是「Make it work, make it right, make it fast」，你們能夠看到這句話裏面 「Fast」是放最後的，這一點也是 TiDB 和其餘產品有很是大的差別的地方。做爲一個技術人員，一般你們看一個產品好很差，就會想：「來，不服跑個分，產品架構、易用性、技術文檔、Community 這些指標都不看，先跑個分讓你們看看行不行」。這個思路真正往市場上去推時是不對的。不少事情的選擇是一個綜合的過程。你可讓你的汽車跑的巨快無比，上面東西全拆了就留一個發動機和四個輪子，那確定也是跑得巨快，重量輕，並且仍是敞篷車，但沒有一我的會在路上用的。一樣的，選擇 Rust 也是綜合考量的結果。咱們看中了 Rust 這個很是具備潛力的語言。當時 Rust 沒有發佈 1.0，還不是一個 stable 版本，但咱們相信它會有 1.0。大概過了幾個月，Rust 就發佈了 1.0 版本，證實咱們的選擇仍是很是正確的。

最後一點就是穩定性。做爲一個分佈式數據庫，每一層的穩定性都很是重要。最底下的一個存儲引擎，咱們選擇了很是穩定的 RocksDB。不事後來咱們也查到幾個 RocksDB 掉數據的 Bug。這也是作數據庫或者說作基礎產品的殘酷性，咱們在作產品的過程當中找到了 Rust 編譯器的 Bug，XFS 掉數據的 Bug，RocksDB 掉數據的 Bug，好像幾大基礎組件的 Bug 都聚在這裏開會。

接着咱們辛辛苦苦幹了三個月，而後就開源了 TiKV，因此這時候看起來沒有那麼多的組件了。咱們也不忘初心，又去找了咱們當初那個用戶，說咱們作了一些改進，你要不要試一試。

圖 4 與調研用戶第三次對話

可是用戶這時候給了一個讓咱們很是傷心很是難受的回答：沒有，咱們不敢上線，雖然大家的產品聽起來挺好的，可是數據庫後面有很大的責任，心理上的擔憂確實是過不去。因而咱們回去開始加班加點寫 TiDB Binlog，讓用戶能夠把 binlog 同步給 MySQL。畢竟用戶須要一個 Backup：萬一 TiDB 掛了怎麼辦，我須要切回 MySQL，這樣才放心，由於數據是核心資產。

圖 5 第一個上線用戶的架構圖

因此最終咱們第一個用戶上線的時候，整個 TiDB 的架構是這樣的（如圖 5）。用戶經過 Client 連上 TiDB，而後 TiDB 後面就經過 Binlog 同步到 MySQL。後來過了一段時間，用戶就把後面的 MySQL 撤了。咱們當時挺好奇爲何撤了，用戶說，第一個緣由是後面 MySQL 撐不起一個集羣給它回吐 Binlog，第二就是用了一段時間以爲 TiDB 挺穩定的，而後就不須要 Binlog 備份了。

其實第一個用戶上線的時候，數據量並不算大，大概 800G 的數據，使用場景是 OLTP 爲主，有少許的複雜分析和運算，但這少許的複雜分析運算是當時他們選擇 TiDB 最重要的緣由。由於當時他們須要每隔幾分鐘算一個圖出來，若是是在 MySQL 上面跑，大約須要十幾分鍾，但他們須要每隔幾分鐘打一個點，後來忽然發現次日才能把前一天的點都打出來，這對於一個實時的系統來講就很不現實了。雖然這個應用實踐只有少部分運算，但也是偏 OLAP，我記得 TiDB 也不算特別快，大概是十幾秒鐘，由於支持了一個並行的 Hash Join。

無論怎樣，這個時候終於有第一個用戶能證實咱們作到了「Make it work」。

二、Make it right

接下來就是「Make it right」。你們可能想象不到作一個保證正確性的數據庫這件事情有多麼難，這是一個巨大的挑戰，也有巨大的工做量，是從理論到實踐的距離。

圖 6 理論到實踐的距離

（1）TLA+ 證實

你們可能會想寫程序跟理論有什麼關係？其實在分佈式數據庫領域是有一套方法論的。這個方法論要求先實現正確性，而實現正確的前提是有一個形式化的證實。爲了保證整個系統的理論正確，咱們把全部的核心算法都用 TLA+ 寫了一遍證實，而且把這個證實開源出去了，若是你們感興趣能夠翻看一下（https://github.com/pingcap/tl...）。之前寫程序的時候，你們不多想到先證實一下算法是對的，而後再把算法變成一個程序，其實今天還有不少數據庫廠商沒有作這件事。

（2）千萬級別測試用例

在理論上保證正確性以後，下一步是在現實中測試驗證。這時只有一個辦法就是用很是龐大的測試用例作測試。你們一般本身作測試的時候，測試用例應該不多能達到十萬級的規模，而咱們如今測試用例的規模是以千萬爲單位的。固然若是以千萬爲單位的測試用例靠純手寫不太現實，好在咱們兼容了 MySQL 協議，能夠直接從 MySQL 的測試用例裏收集一些。這樣就能很快驗證整個系統是否具有正確性。

這些測試用例包括應用、框架、管理工具等等。好比有不少應用程序是依賴 MySQL，那直接拿這個應用程序在 TiDB 上跑一下，就知道 TiDB 跟 MySQL 的兼容沒問題，如 Wordpress、無數的 ORM 等等。還有一些 MySQL 的管理工具能夠拿來測試，好比 Navicat、PHP admin 等。另外咱們把公司內部在用的 Confluence、Jira 後面接的 MySQL 都換成了 TiDB，雖說規模不大，可是咱們是但願在應用這塊有足夠的測試，同時本身「Eat dog food」。

（3）7*24 的錯誤注入測試用例

這些工做看起來已經挺多的了，但實際上還有一塊工做比較消耗精力，叫 7*24 的錯誤注入測試。最先咱們也不知道這個測試這麼花錢，咱們如今測試的集羣已是幾百臺服務器了。若是創業的時候就知道須要這麼多服務器測試，咱們可能就不創業了，好像天使輪的融資都不夠買服務器的。不過好在這個事是一步一步買起來，剛開始咱們也沒有買這麼多測試服務器，後來隨着規模的擴大，不斷的在增長這塊的投入。

你們可能到這兒的時候仍是沒有一個直觀的感覺，說這麼多測試用例，究竟是一個什麼樣的感覺。咱們能夠對比看一下行業巨頭 Oracle 是怎麼幹的。

圖 7 前 Oracle 員工的描述（https://news.ycombinator.com/...）

這是一篇在 HackNews上面的討論，討論的問題是：你以爲這個最壞的、規模最大的代碼是什麼樣子的？下面就有一個 Oracle 的前員工就介紹了 Oracle Database 12.2 這個版本的狀況。他說這個總體的源代碼接近 2500 萬行 C 代碼，可能你們維護 25 萬行 C 代碼的時候就會痛不欲生了，能夠想一想維護這麼多代碼的是一種什麼樣的感覺。到如今爲止，TiDB 的代碼應該還不到 25 萬行。固然 TiDB 的功能遠遠沒有 Oracle 那麼多，Oracle 的功能實際上是不少的，歷史積累一直往上加，加的很兇。

這位 Oracle 前員工介紹了本身在 Oracle 的開發工做的流程，以下圖：

圖 8 Oracle 開發者 fix bug 的過程

好比用戶報了一個 Bug，而後他開始 fix。第一件事是花兩週左右的時間去理解 20 個不一樣的 flag，看看有沒有可能由於內部亂七八糟的緣由來形成這個 Bug。你們可能不知道 MySQL 有多少變量，我剛作 TiDB 的時候也不知道，當時我以爲本身是懂數據庫的，後來去看了一下 MySQL 的 flag 的變量數就驚呆了，但看到 Oracle 的 flag 變量數，那不是驚呆了，是絕望了。你們可能知道開啓 1 個 flag 的時候會對什麼東西有影響，可是要去理解 20 個 flag 開啓時和另外幾個 flag 組合的時候都有什麼影響，可能會崩潰。因此其實精通 Oracle 這件事情，實際上可能比精通 C++ 這件事情更困難的。一個 Oracle 開發者在內部處理這件事情都這麼複雜，更況且是外面的用戶。但 Oracle 確實是功能很強大。

說回這位前 Oracle 員工的描述，他接着添加了更多的 flag 處理一個新的用戶場景的問題，而後增強代碼，最後改完之後會提交一個測試。先在 100 到 200 臺機器上面把這個 Oracle 給 build 出來，而後再對這個 Oracle 去作新的測試。他應該對 Oracle 的測試用例的實際數量了解不深入，我猜他可能不知道 Oracle 有多少個測試，因此寫的是 「millions of tests」，這顯然過低估了 Oracle 的測試數量。一般狀況下，只會看到掛了的測試，看不到所有的測試數量。

下面的步驟更有意思了：Go home，由於整個測試須要 20-30 個小時，跑完以後測試系統反饋了一個報告：掛了 200 多個 test，更茫然的是這 200 tests 他之前都沒見過，這也是 Oracle 很是強大的一個地方，若是一個開發者的代碼提交過去掛掉一兩百個測試，是很正常的事情，由於 Oracle 的測試能 Cover 東西很是多，是這麼多年來很是強大的積累，不停的堆功能的同時就不停的堆測試，固然也不停的堆 flag。因此從另外一個角度來看，限制一個系統的功能數量，對於維護來講是很是重要的。

總之，看完這個回覆以後，我對行業前輩們充滿了敬畏之情。

三、Make it fast

（1）新問題

隨着 TiDB 有用戶開始上線，用戶的數量和規模愈來愈大，這時候就出現了一個頗有意思的事情，一部分用戶把 TiDB 當成了能夠支持事務、擁有良好實時性的數據倉庫在用，和咱們說：咱們把公司 Hadoop 換了，數據量十幾 T。

咱們就一下開始陷入了深深的思考，由於 TiDB 原本設計的目的不是這個方向，咱們想作一個分佈式 OLTP 數據庫，並無想說咱們要作一個 Data Warehouse。可是用戶的理由讓咱們以爲也頗有道理，沒法反駁——TiDB 兼容 MySQL，會 MySQL 的人不少，更好招人，最重要的是 Hadoop 跑得還不夠快。

雖然咱們本身也很吃驚，但這體現了 TiDB 另外一方面的價值，因此咱們繼續問用戶還有什麼痛點。用戶表示還有一部分查詢不夠快，數據沒辦法作到 shuffle，並且之前用 Spark，TiDB 好像沒有 Spark 的支持。

咱們想了想，TiDB 直接連 Spark 也是能夠的，但這樣 Spark 對底下沒有感知，事務跑得巨慢，就跟 Spark 接 MySQL 沒什麼差異。咱們研究了一下，作出了一個新的東西——TiSpark。TiSpark 就開始可以同時在 TiDB 上去跑 OLAP 和 OLTP。

圖 9 出現的新問題

就在咱們準備改進 TiDB 的數據分析能力的時候，忽然又有一大批 TP 用戶上線了，給咱們報了一堆問題，好比執行計劃不許確，選不到最優執行計劃，數據熱點分佈不均勻，Raft store 單線程寫入瓶頸，報表跑的慢等等……因而咱們制定了 1.0 到 2.X 的計劃，先把用戶提的這些問題一一解決。

這裏有另一條哲學：將用戶遇到的問題放在第一優先級。咱們從產品最初設計和以後 Roadmap 計劃永遠是按照這個原則去作的。

首先，執行計劃不許確的問題。最簡單有效的解決辦法是加一個 Index Hint，就像是「你告訴我怎麼執行，我就怎麼執行，我本身不會自做聰明的選擇」。但這不是長久之計，由於用戶多是在一個界面上選擇各類條件、參數等等，最後拼成一個 SQL，他們本身沒辦法在裏面加 Index Hint。咱們不能決定用戶的使用習慣，因此從這時開始，咱們決定從 RBO（Rule Based Optimizer）演進到 CBO（Cost Based Optimizer），這條路也走了很是久，並且還在持續進行。

第二個是熱點數據處理問題。咱們推出了一個熱點調度器，這個可能你們在分佈式數據庫領域第一次據說，數據庫領域應該是 PingCAP 獨創。 熱點調度器會統計、監控整個系統熱點狀況，再把這些熱點作一個快速遷移和平衡，好比整個系統有 10 個熱點，某一個機器上有 6 個熱點，這臺機器就會很卡，這時熱點調度器會開始將熱點打散，快速分散到集羣的其餘機器上去，從而讓整個集羣的機器都處於比較正常的負載狀態。

第三個就是解決 Raft store 單線程瓶頸的問題。爲了改變 Raft store 單線程，咱們大概花了一年多的時間，目前已經在 TiDB 3.0 裏實現了。咱們將 Raft store 線程更多耗時的計算變成異步操做，offload 到其它線程。不知道有沒有人會好奇爲何這個改進會花這麼長時間？咱們一直認爲數據庫的穩定性第一位的。分佈式系統裏面一致性協議自己也複雜，雖說 Raft 是比 Paxos 要簡單，但它實際作起來也很複雜，要在一個複雜系統裏支持多線程，而且還要作優化，儘量讓這個 I/O 能 group 到一塊兒，其實很是耗精力。

第四個就是解決報表跑得慢的問題，這個骨頭特別硬，咱們也是啃到今天還在繼續。首先要大幅提高 TiDB 在分析場景下的能力。你們均可以看到咱們在發佈每個版本的時候，都會給出與上一個版本的 TPC-H 性能對比（TPC-H 是一個有很是多的複雜查詢、大量運算的場景）。其次就是高度並行化，充分利用多核，並提供參數控制，這個特性可能不少用戶不知道，咱們能夠配一下參數，就讓 TiDB 有多個併發在底層作 Scan（https://github.com/pingcap/do...）。

解決完這些問題，咱們終於以爲能夠喘口氣了，但喘氣的時間就不到一個星期，很快又有不少用戶的反饋開始把咱們淹沒了。由於隨着用戶規模的擴大，用戶反饋問題的速度也變得愈來愈快，咱們處理的速度不必定跟的上用戶的增速。

（2）新呼聲

這時候咱們也聽到了用戶的一些「新呼聲」。

有用戶說他們在跑複雜查詢時 OLTP 的查詢延遲變高了，跑一個報表的時候發現 OLTP 開始卡了。這個問題的緣由是在跑複雜查詢的時候，SQL 資源被搶佔。咱們又想有沒有可能將 OLAP 和 OLTP 的 Workload 分開？因而咱們搞了第一個實驗版本，在 TiKV 裏把請求分優先級，放到不一樣隊列裏面去，複雜 Query 放在第一優先級的隊列， OLTP 放在高優先級。而後咱們發現本身是對報表理解不夠深入，這個方案只能解決一部分用戶的問題，由於有的報表跑起來須要幾個小時，致使隊列永遠是滿的，永遠搶佔着系統的資源。還有一部分用戶的報表沒有那麼複雜，只是但願報表跑得更快、更加實時，好比一個作餐飲 SaaS 的用戶，天天晚上須要看一下餐館營收狀況，統計一家餐館時速度還行，若是統計全部餐館的狀況，那就另說了。

另外，報表有一些必需品，好比 View 和 Window Function，沒有這些的話 SQL 寫起來很痛苦，缺少靈活度。

與此同時，用戶關於兼容性和新特性的要求也開始變多，好比但願支持 MySQL 相似的 table partition，還有銀行用戶習慣用悲觀鎖，而 TiDB 是樂觀鎖，遷移過來會形成額外的改形成本（TiDB 3.0 已經支持了悲觀鎖）。

還有用戶有 400T 的數據，沒有一個快速導入的工具很是耗時（固然如今咱們有快速導入工具TiDB Lightning），這個問題有一部分緣由在於用戶的硬件條件限制，好比說千兆網導入數據。

還有些用戶的數據規模愈來愈大，到 100T 以上就開始發現十分鐘已經跑不完 GC 了（TiDB 的 GC 是每十分鐘一次），一個月下來 GC 已經總體落後了很是多。

圖 10 用戶的新呼聲

咱們當時很是頭痛，收到了一堆意見和需求，壓力特別大，而後趕忙彙總了一下，如圖 10 所示。面對這麼多的需求，咱們考慮了兩個點：

哪些是共性需求？
什麼是完全解決之道？

把共性的需求都列在一塊，提供一個在產品層面和技術層面真正的完全的解決辦法。

好比圖 10 列舉的那麼多問題，其實真正要解決三個方面：性能、隔離和功能。性能和隔離兼得好像很困難，可是這個架構有很是獨特的優點，也是能夠作獲得的。那能夠進一步「三者兼得」，同時解決功能的問題嗎？咱們思考了一下，也是有辦法的。TiDB 使用的 Raft 協議裏有一個 Raft Learner 的角色，能夠不斷的從 Leader 那邊複製數據，咱們把數據同步存成了一個列存，剛纔這三方面的問題均可以用一個方案去完全解決了。

首先複雜查詢的速度變快了，衆所周知分析型的數據引擎基本上所有使用的是列存。第二就是強一致性，整個 Raft 協議能夠保證從 Learner 讀數據的時候能夠選擇一致性的讀，能夠從 Leader 那邊拿到 Learner 當前的進度，判斷是否能夠對外提供請求。第三個是實時性能夠保證，由於是經過 streaming 的方式複製的。

因此這些看上去很是複雜的問題用一個方案就能夠解決，而且強化了原來的系統。這個「強化」怎麼講？從用戶的角度看，他們不會考慮 Query 是 OLAP 仍是 OLTP，只是想跑這條 Query，這很合理。用一套東西解決用戶的全部問題，對用戶來講就是「強化」

問題的思考

![圖片上傳中...]

圖 11 成本問題

不少用戶都跟咱們反饋了成本問題，用戶以爲所有部署到 SSD 成本有點高。一開始聽到這個反饋，咱們還不能理解，SSD 已經很便宜了呀，並且在整個系統來看，存儲機器只是成本的一小部分。後來咱們深入思考了一下，其實用戶說得對，不少系統都是有遲早高峯的，若是在幾百 T 數據裏跑報表，只在天天晚上收工時統計今天營業的情況，那爲何要求用戶付出最高峯值的配置呢？這個要求是不合理的，合不合理是一回事，至於作不作獲得、怎麼作到是另一回事。

因而咱們開始面臨全新的思考，這個問題本質上是用戶的數據只有一部分是熱的，可是付出的代價是要讓機器 Handle 全部的數據，因此能夠把問題轉化成：咱們能不能在系統裏面作到冷熱數據分離？能不能支持系統動態彈性的伸縮，伸展熱點數據，用完就釋放？

若是對一個系統來講，峯值時段和非峯值時段的差異在於峯值時段多了 5% 的熱點。咱們有必要去 Handle 全部的數據嗎？因此完全的解決辦法是對系統進行合理的監控，檢測出熱點後，立刻建立一個新的節點，這個新的節點只負責處理熱點數據，而不是把全部的數據作動態的 rebalance，從新搬遷。在峯值時間過去以後就能夠把複製出來的熱點數據撤掉，佔的這個機器能夠直接停掉了，不須要長時間配備很是高配置的資源，而是動態彈性伸縮的。

TiDB 做爲一個高度動態的系統，自己的架構就具備很是強的張力，像海綿同樣，可以知足這個要求，並且能根據系統負載動態的作這件事。這跟傳統數據庫的架構有很大的區別。好比有一個 4T 的 MySQL 數據庫，一主一從，若是主庫很熱，只能立刻搞一個等配的機器重掛上去，而後複製所有數據，但實際上用戶須要的只是 5% 的熱數據。而在 TiDB 裏，數據被切成 64MB 一個塊，能夠很精確的檢測熱數據，很方便的爲熱數據作伸展。這個特性預計在 TiDB 4.0 提供。

這也是一個良好的架構自己帶來的強大的價值，再加上基於 K8s 和雲的彈性架構，就能夠獲得很是多的不同的東西。一樣的思路，若是我要作數據分析，必定是掃所有數據嗎？對於一個多租戶的系統，我想統計某個餐館今天的收入，數據庫裏有成千上萬個餐館，我須要運算的數據只是其中一小塊。若是我要快速作列存計算時，須要把數據所有複製一份嗎？也不須要，只複製我須要的這部分數據就行。這些事情只有一個具備彈性、高度張力的系統才能作到。這是 TiDB 相對於傳統架構有很是不同的地方。時至今天，咱們纔算是把整個系統的架構基本上穩定了，基於這個穩定的架構，咱們還能夠作更多很是具備張力的事情。

因此，用一句話總結咱們解決成本問題的思路是：必定要解決真正的核心的問題，解決最本質的問題。

04關於橫向和縱向發展的哲學

TiDB 還有一條哲學是關於橫向和縱向發展的選擇。

一般業內會給創業公司的最佳建議是優先打「透」一個行業，由於行業內複製成本是最低的，可複製性也是最好的。但 TiDB 從第一天開始就選擇了相反的一條路——「先往通用性發展」，這是一條很是艱難的路，意味着放棄了短期的複製性，但其實咱們換取的是更長時間的複製性，也就是通用性。

由於產品的總體價值取決於總的市場空間，產品的普遍程度會決定產品最終的價值。早期堅決不移的往通用性上面走，有利於儘早感知整個系統是否有結構性缺陷，驗證本身對用戶需求的理解是否具備足夠的廣度。若是隻往一個行業去走，就沒法知道這個產品在其餘行業的適應性和通用性。若是咱們變成了某個行業專用數據庫，那麼再往其餘行業去發展時，面臨的第一個問題是本身的恐懼。這恐懼怎麼講呢？Database 應該是一個通用型的東西，若是在一個行業裏固定了，那麼你要如何肯定它在其餘場景和行業是否具備適應性？

這個選擇也意味着咱們會面臨很是大的挑戰，一上來先作最厲害的、最有挑戰的用戶。若是你們去關注整個 TiDB 發展的用戶案例的狀況，你會注意到 TiDB 有這樣一個特色，TiDB 是先作百億美金以上的互聯網公司，這是一個很是難的選擇。但你們應該知道，百億美金以上的互聯網公司，在選擇一個數據庫等技術產品的時候，是沒有任何商業上的考量的，對這些公司來講，你的實力是第一位的，必定要能解決他們問題，纔會承認你整個系統。但這個也很差作，由於這些公司的應用場景一般都壓力巨大。數據量巨大，QPS 特別高，對穩定性的要求也很是高。咱們先作了百億美金的公司以後，去年咱們有 80% 百億美金以上的公司用 TiDB，除了把咱們當成競爭對手的公司沒有用，其餘所有在用。而後再作 30 億美金以上的公司，今年是 10 億美金以上的用戶，實際上如今是什麼樣規模的用戶都有，甭管多少億美金的，「反正這東西挺好用的，我就用了。」因此咱們如今也有人專門負責在用戶羣裏面回答你們的提問。

其實當初這麼定那個目標主要是考慮數據量，由於 TiDB 做爲一個分佈式系統必定是要處理具備足夠數據量的用戶場景，百億美金以上的公司確定有足夠的數據，30 億美金的公司也會有，由於他們的數據在高速增加，當咱們完成了這些，而後再開始切入到傳統行業，由於在這以前咱們通過了穩定性的驗證，

景的驗證。

![圖片上傳中...]

圖 12 橫向發展與縱向發展

堅持全球化的技術視野也是一個以橫向優先的發展哲學。最厲害的產品必定是全球在用的。這個事情的最大差別在於視野和格局，而格局最終會反映到人才上，最終競爭不是在 PingCAP 這兩百個員工，也不是如今 400 多個 Contributors，將來可能會有上千人參與整個系統的進化迭代，在不一樣的場景下對系統進行打磨，因此競爭本質上是人才和場景的競爭。基於這一條哲學，因此纔有瞭如今 TiDB 在新一代分佈式數據庫領域的全面領先，不管是從 GitHub Star 數、 Contributor 數量來看，仍是從用戶數據的規模、用戶分佈的行業來看，都是領先的。一樣是在作一個數據庫，你們的指導哲學不同會致使產品最終的表現和收穫不同，迭代過程也會徹底不同。咱們在作的方向是「攜全球的人才和全球的場景去競爭」。

關於橫向和縱向發展，並非咱們只取了橫向。

2019 年 TiDB 演進的指導思想是：穩定性排第一，易用性排第二，性能第三，新功能第四。這是我在 2018 年通過思考後，把咱們發展的優先級作了排序。上半年咱們重點關注的是前兩個，穩定性和易用性。下半年會關注縱向發展，「Make it fast」實際上是縱向上精耕細做、釋放潛力的事情。這個指導思想看起來好像又跟其餘廠商想法不太同樣。

咱們前面講的三條哲學裏面，最後一條就是「Make it fast」，若是要修建五百層的摩天大樓，要作的不是搭完一層、裝修一層，立刻給第一層作營業，再去搭第二層。而必定要先把五百層的架構搭好，而後想裝修哪一層均可以。TiDB 就是「摩天大樓先搭架構後裝修」的思路，因此在 TiDB 3.0 發佈以後，咱們開始有足夠的時間去作「裝修」的事情。

05總結與展望

說了這麼多故事，若是要我總結一下 2015 - 2019 年外面的朋友對 TiDB 的感覺，是下圖這樣的：

圖 13 2015-2019 小結

2015 年，當咱們開始作 TiDB 的時候，你們說：啊？這事兒大家也敢幹？由於寫一個數據庫自己很是難，寫一個分佈式數據庫就是無比的難，而後仍是國人自主研發。到 2016 年的時候，你們以爲你好像折騰了點東西，聽到點聲音，但也沒啥。到 201七、2018 年，你們看到有愈來愈多用戶在用。2019 年，能看到更多使用後點讚的朋友了。

我昨天翻了一下 2015 年 4 月 19 日發的一條微博。

圖 14 剛創業時發的微博

當時咱們正準備創業，意氣風發發了一條這樣微博。這一堆話其實不重要，你們看一下閱讀量 47.3 萬，有 101 條轉發，44 條評論，然而我一封簡歷都沒收到。當時你們看到咱們都以爲，這事兒外國人都沒搞，你行嗎？折騰到今天，我想應該沒有人再對這個問題有任何的懷疑。不少國人其實能力很強了，自信也能夠同步跟上來，畢竟咱們擁有全球最快的數據增速，不少廠家擁有最大的數據量，對產品有最佳的打磨場景。

想一想當時我也挺絕望的，想着應該還有很多人血氣方剛，還有不少技術人員是有很是強大的理想的，可是前面我也說了，總有一個從理想到現實的距離，這個距離很長，好在如今咱們能收到不少簡歷。因此不少時候你們也很難想象咱們剛開始作這件事情的時候有多麼的困難，以及中間的每個堅持。只要稍微有一丁點的鬆懈，就可能走了另一條更容易走的路，可是那條更容易走的路，從長遠上看是一條更出路的路。

圖 15 對 2020 年的展望

最後再說一下 2020 年。在擁有行業複製能力的以後，在產品層面咱們要開始向着更高的性能、更低的延遲、更多 Cloud 支持（無論是公有云仍是私有云均可以很好的使用 TiDB）等方向縱向發展。同時也會支持我剛剛說的，熱點根據 Workload 自動伸縮，用極小的成本去扛，僅僅須要處理部分熱點的數據，而不是複製整個數據的傳統主-從思路。

你們去想想，若是整個系統會根據 Workload 自動伸縮，本質上是一個 self-driving 的事情。如今有愈來愈多的用戶把 TiDB 當成一個數據中臺來用，有了 TiDB 行列混存，而且 TiDB 對用戶有足夠透明度，就至關因而握有了 database 加上 ETL，加上 data warehouse，而且是保證了一致性、實時性的。

昨天我寫完 slides 以後想起了之前看的一個電視劇《大秦帝國》。第一部第九集裏有一段關於圍棋的對話。商鞅執黑子先行，先下在了一個應該是叫天元位置，大約在棋盤的中間。你們知道通常下圍棋的時候都是先從角落開始落子居多。商鞅的對手就說，我許你重下，意思就是你不要開玩笑，誰下這兒啊？因而商鞅說這樣一句話，「中樞之地，輻射四極，雄視八荒」，這也是一個視野和格局的事情。而後對手說：「先生招招高位，步步懸空，全無根基實地」，就是看起來好像是都還挺厲害的，一點實際的基礎都沒有，商鞅說：「旦有高位，豈無實地？」，後來商鞅贏了這盤棋，他解釋道：「棋道以圍地爲歸宿，但必以取勢爲根本。勢高，則圍廣」。

這跟咱們作 TiDB 其實很像，咱們一上來就是先作最難最有挑戰的具備最高 QPS 和 TPS、最大數據量的場景，這就是一個「取勢」的思路，由於「勢高，則圍廣」。因此咱們更多時候是像我前面說的那樣，站在哲學層面思考整個公司的運轉和 TiDB 這個產品的演進的思路。這些思路不少時候是你們看不見的，由於不是一個純粹的技術層面或者算法層面的事情。

以上內容來自PingCAP CEO劉奇的分享。

活動推薦

2019年6月21-23日，GIAC全球互聯網架構大會將在深圳舉辦，組委會從互聯網架構最熱門的Cloud-Native、IoT、人工智能等前沿技術、數據及商業智能、大中臺、經典架構、工程文化及管理等領域甄選前沿的有典型表明的技術創新及研發實踐的架構案例，邀請了BAT、美團、滴滴等企業技術專家爲咱們分享最新的技術成果，識別圖中二維碼便可有機會得到大會體驗票一張！