摘要：我司申礫在上分享了產品進化過程中的思考與未來規劃。第一點是對整個聚合框架做了優化，就是從一行一行處理的聚合模式，變成了一批一批數據處理的聚合模式，另外我們還在哈希聚合算子上做了并行。

我司 Engineering VP 申礫在 TiDB DevCon 2019  上分享了 TiDB 產品進化過程中的思考與未來規劃。本文為演講實錄上篇，重點回顧了 TiDB 2.1 的特性，并分享了我們對「如何做一個好的數據庫」的看法。

感謝這么多朋友的到場，今天我會從我們的一些思考的角度來回顧過去一段時間做了什么事情，以及未來的半年到一年時間內將會做什么事情，特別是「我們為什么要做這些事情」。

TiDB 這個產品，我們從 2015 年年中開始做，做到現在，三年半，將近四年了，從最早期的 Beta 版的時候就開始上線，到后來 RC 版本，最后在 2017 年終于發了 1.0，開始鋪了一部分用戶，到 2.0 的時候，用戶數量就開始漲的非?？?。然后我們最近發了 2.1，在 2.1 之后，我們也和各種用戶去聊，跟他們聊一些使用的體驗，有什么樣的問題，包括對我們進行吐嘈。我們就在這些實踐經驗基礎之上，設計了 3.0 的一些特性，以及我們的一些工作的重點。現在我們正在朝 3.0 這個版本去演進，到今天早上已經發了?3.0 Beta 版本。

首先我們來講 2.1，2.1 是一個非常重要的版本，這個版本我們吸取了很多用戶的使用場景中看到的問題，以及特別多用戶的建議。在這里我跟大家聊一聊它有哪些比較重要的特性。

首先我們兩個核心組件：存儲引擎和計算引擎，在這兩方面，我們做了一些非常重要的改進，當然這些改進有可能是用戶看不到的?；蛘哒f這些改進其實我們是不希望用戶能看到的，一旦你看到了，注意到這些改進的話，說明你的系統遇到這些問題了。

大家都知道 Raft 會有 Leader 和 Follower 這兩個概念，Leader 來負責讀寫，Follower 來作為 Backup，然后隨時找機會成為新的 Leader。如果你想加一個新的節點，比如說在擴容或者故障恢復，新加了一個 Follower 進來，這個時候 Raft Group 有 4 個成員， Leader、Follower 都是 Voter，都能夠在寫入數據時候對日志進行投票，或者是要在成員變更的時候投票的。這時一旦發生意外情況，比如網絡變更或者出現網絡分區，假設 2 個被隔離掉的節點都在一個物理位置上，就會導致 4 個 Voter 中 2 個不可用，那這時這個 Raft Group 就不可用了。

大家可能覺得這個場景并不常見，但是如果我們正在做負載均衡調度或者擴容時，一旦出現這種情況，就很有可能影響業務。所以我們加了 Learner 這個角色，Learner 的功能也是我們貢獻給 etcd 這個項目的。有了 Learner 之后，我們在擴容時不會先去加一個 Follower（也就是一個 Voter），而是增加一個 Learner 的角色，它不是 Voter，所以它只會同步數據不會投票，所以無論在做數據寫入還是成員變更的時候都不會算上它。當同步完所有數據時（因為數據量大的時候同步時間會比較長），拿到所有數據之后，再把它變成一個 Voter，同時再把另一個我們想下線的 Follower 下掉就好了。這樣就能極大的縮短同時存在 4 個 Voter 的時間，整個 Raft Group 的可用性就得到了提升。

其實增加 Learner 功能不只是出于提升 Raft Group 可用性，或者說出于安全角度考慮，實際上我們也在用 Learner 來做更多的事情。比如，我們可以隨便去加 Learner，然后把 Learner 變成一個只讀副本，很多很重的分析任務就可以在 Learner 上去做。TiFlash 這個項目其實就是用 Learner 這個特性來增加只讀副本，同時保證不會影響線上寫入的延遲，因為它并不參與寫入的時候投票。這樣的好處是第一不影響寫入延遲，第二有 Raft 實時同步數據，第三我們還能在上面快速地做很復雜的分析，同時線上 OLTP 業務有物理上的隔離。

除了 Learner 之外，我們 2.1 中默認開啟了 PreVote 這個功能。

我們考慮一種意外情況，就是在 Raft group 中出現了網絡隔離，有 1 個節點和另外 2 個節點隔離掉了，然后它現在發現「我找不到 Leader 了，Leader 可能已經掛掉了」，然后就開始投票，不斷投票，但是因為它和其他節點是隔離開的，所以沒有辦法選舉成功。它每次失敗，都會把自己的 term 加 1，每次失敗加 1，網絡隔離發生一段時間之后，它的 term 就會很高。當網絡分區恢復之后，它的選舉消息就能發出去了，并且這個選舉消息里面的 term 是比較高的。根據 Raft 的協議，當遇到一個 term 比較高的時候，可能就會同意發起選舉，當前的 Leader 就會下臺來參與選舉。但是因為發生網絡隔離這段時間他是沒有辦法同步數據的，此時它的 Raft Log 一定是落后的，所以即使它的 term 很高，也不可能被選成新的 Leader。所以這個時候經過一次選舉之后，它不會成為新 Leader，只有另外兩個有機會成為新的 Leader。

大家可以看到，這個選舉是對整個 Raft Group 造成了危害：首先它不可能成為新的 Leader，第二它把原有的 Leader 趕下臺了，并且在這個選舉過程中是沒有 Leader 的，這時的 Raft Group 是不能對外提供服務的。雖然這個時間會很短，但也可能會造成比較大的抖動。

所以我們有了 PreVote 這個特性。具體是這樣做的（如圖 3）：在進行選舉之前，先用 PreVote 這套機制來進行預選舉，每個成員把自己的信息，包括 term，Raft Log Index 放進去，發給其它成員，其它成員有這個信息之后，認為「我可以選你為 Leader」，才會發起真正的選舉。

有了 PreVote 之后，我們就可以避免這種大規模的一個節點上很多數據、很多 Raft Group、很多 Peer 的情況下突然出現網絡分區，在恢復之后造成大量的 Region 出現選舉，導致整個服務有抖動。 因此 PreVote 能極大的提升穩定性。

當然除了 Raft 這幾個改進之外，TiDB 2.1 中還有一個比較大的改進，就是在 DDL 模塊。這是我們 2.1 中一個比較顯著的特性。

在 2.1 之前的 DDL 整套機制是這樣的（如圖 4）：用戶將 DDL 提交到任何一個 TiDB Server，發過來一個 DDL 語句，TiDB Server 經過一些初期的檢查之后會打包成一個 DDL Job，扔到 TiKV 上一個封裝好的隊列中，整個集群只有一個 TiDB Server 會執行 DDL，而且只有一個線程在做這個事情。這個線程會去隊列中拿到隊列頭的一個 Job，拿到之后就開始做，直到這個 Job 做完，即 DDL 操作執行完畢后，會再把這個 Job 扔到歷史隊列中，并且標記已經成功，這時 TiDB Sever 能感知到這個 DDL 操作是已經結束了，然后對外返回。前面的 Job 在執行完之前，后面的 DDL 操作是不會執行的，因而會造成一個情況： 假設前面有一個 AddIndex，比如在一個百億行表上去 AddIndex，這個時間是非常長的，后面的 Create Table 是非常快的，但這時 Create Table 操作會被 AddIndex 阻塞，只有等到 AddIndex 執行完了，才會執行 Create Table，這個給有些用戶造成了困擾，所以我們在 TiDB 2.1 中做了改進。

在 TiDB 2.1 中 DDL 從執行層面分為兩種（如圖 5）。一種是 AddIndex 操作，即回填數據（就是把所有的數據掃出來，然后再填回去），這個操作耗時是非常長的，而且一些用戶是線上場景，并發度不可能調得很高，因為在回寫數據的時候，可能會對集群的寫入造成壓力。

另外一種是所有其他 DDL 操作，因為不管是 Create Table 還是加一個 Column 都是非常快的，只會修改 metadata 剩下的交給后臺來做。所以我們將 AddIndex 的操作和其他有 DDL 的操作分成兩個隊列，每種 DDL 語句按照分類，進到不同隊列中，在 DDL 的處理節點上會啟用多個線程來分別處理這些隊列，將比較慢的 AddIndex 的操作交給多帶帶的一個線程來做，這樣就不會出現一個 AddIndex 操作阻塞其他所有 Create Table 語句的問題了。

這樣就提升了系統的易用性，當然我們下一步還會做進一步的并行， 比如在 AddIndex 時，可以在多個表上同時 AddIndex，或者一個表上同時 Add 多個 Index。我們也希望能夠做成真正并行的一個 DDL 操作。

除了剛剛提到的穩定性和易用性的提升，我們在 TiDB 2.1 中，也對分析能力做了提升。我們在聚合的算子上做了兩點改進。 ?第一點是對整個聚合框架做了優化，就是從一行一行處理的聚合模式，變成了一批一批數據處理的聚合模式，另外我們還在哈希聚合算子上做了并行。

為什么我們要優化聚合算子？因為在分析場景下，有兩類算子是非常重要的，是 Join 和聚合。Join 算子我們之前已經做了并行處理，而 TiDB 2.1 中我們進一步對聚合算子做了并行處理。在哈希聚合中，我們在一個聚合算子里啟用多個線程，分兩個階段進行聚合。這樣就能夠極大的提升聚合的速度。

圖 7 是 TiDB 2.1 發布的時候，我們做了一個 TPC-H Benchmark。實際上所有的 Query 都有提升，其中 Q17 和 Q18 提升最大。因為在 TiDB 2.0 測試時，Q17、Q18 還是一個長尾的 Query，分析之后發現瓶頸就在于聚合算子的執行。整個機器的 CPU 并不忙，但就是時間很長，我們做了 Profile 發現就是聚合的時間太長了，所以在 TiDB 2.1 中，對聚合算子做了并行，并且這個并行度可以調節。

TiDB 2.1 發布的時我們還發布了兩個工具，分別叫 TiDB-DM 和?TiDB-Lightning。

TiDB-DM 全稱是 TiDB Data Migration，這個工具主要用來把我們之前的 Loader 和以及 Syncer 做了產品化改造，讓大家更好用，它能夠做分庫分表的合并，能夠只同步一些表中的數據，并且它還能夠對數據做一些改寫，因為分庫分表合并的時候，數據合到一個表中可能會沖突，這時我們就需要一種非常方便、可配置的工具來操作，而不是讓用戶手動的去調各種參數。

TiDB-Lightning 這個工具是用來做全量的數據導入。之前的 Loader 也可以做全量數據導入，但是它是走的最標準的那套 SQL 的流程，需要做 SQL 的解析優化、 兩階段提交、Raft 復制等等一系列操作。但是我們覺得這個過程可以更快。因為很多用戶想遷移到 TiDB 的數據不是幾十 G 或者幾百 G，而是幾 T、幾十 T、上百 T 的數據，通過傳統導入的方式會非常慢。現在 TiDB-Lightning 可以直接將本地從 MySQL 或者其他庫中導出的 SQL 文本，或者是 CSV 格式的文件，直接轉成 RocksDB 底層的 SST file ，然后再注入到 TiKV 中，加載進去就導入成功了，能夠極大的提升導入速度。當然我們還在不斷的優化，希望這個速度能不斷提升，將 1TB 數據的導入，壓縮到一兩個小時。這兩個工具，有一部分用戶已經用到了（并且已經正式開源）。

我們有相當多的用戶正在使用 TiDB，我們在很多的場景中見到了各種各樣的 Case，甚至包括機器壞掉甚至連續壞掉的情況。見了很多場景之后，我們就在想之后如何去改進產品，如何去避免在各種場景中遇到的「坑」，于是我們在更深入地思考一個問題：如何做一個好的數據庫。因為做一個產品其實挺容易的，一個人兩三個月也能搞一套數據庫，不管是分庫分表，還是類似于在 KV 上做一個 SQL，甚至做一個分布式數據庫，都是可能在一個季度甚至半年之內做出來的。但是要真正做一個好的數據庫，做一個成熟的數據庫，做一個能在生產系統中大規模使用，并且能夠讓用戶自己玩起來的數據庫，其實里面有非常多工作要做。

首先數據庫最基本的是要「有用」，就是能解決用戶問題。而要解決用戶問題，第一點就是要知道用戶有什么樣的問題，我們就需要跟各類用戶去聊，看用戶的場景，一起來分析，一起來獲得使用場景中真實存在的問題。所以最近我們有大量的同事，不管是交付的同事還是研發的同事，都與用戶做了比較深入的訪談，聊聊用戶在使用過程中有什么的問題，有什么樣的需求，用戶也提供各種各樣的建議。我們希望 TiDB 能夠很好的解決用戶場景中存在的問題，甚至是用戶自己暫時還沒有察覺到的問題，進一步的滿足用戶的各種需求。

第二點是「易用性」。就好像一輛車，手動擋的大家也能開，但其實大家現在都想開自動擋。我們希望我們的數據庫是一輛自動擋的車，甚至未來是一輛無人駕駛的車，讓用戶不需要關心這些事情，只需要專注自己的業務就好了。所以我們會不斷的優化現有的解決方案，給用戶更多更好的解決方案，下一步再將這些方案自動化，讓用戶用更低的成本使用我們的數據庫。

最后一點「穩定性」也非常重要，就是讓用戶不會用著用著擔驚受怕，比如半夜報警之類的事情。而且我們希望 TiDB 能在大規模數據集上、在大流量上也能保持穩定。

未完待續...

下篇將于明日推送，重點介紹 TiDB 3.0 Beta 在穩定性、易用性和功能性上的提升，以及 TiDB 在 Storage Layer 和 SQL Layer 方面的規劃。