摘要：從版發(fā)布到現(xiàn)在的半年多時間，開源社區(qū)新增了位，其中杜川成為了，他已經(jīng)貢獻(xiàn)了次，還有一些活躍的有希望成為下一批。在這里我們對社區(qū)貢獻(xiàn)者表示由衷的感謝，希望更多志同道合的人能加入進(jìn)來，也希望大家在這個開源社區(qū)能夠有所收獲

TiDB 是由 PingCAP 開發(fā)的分布式關(guān)系型數(shù)據(jù)庫，今天我們很高興地推出 TiDB 2.1 正式版，提供更豐富的功能、更好的性能以及更高的可靠性。

今年 4 月份我們發(fā)布了 TiDB 2.0 版本，提升了穩(wěn)定性、性能以及可運維性，這個版本在接下來的半年中得到了廣泛的關(guān)注和使用。

迄今為止 TiDB 已經(jīng)在 數(shù)百家用戶 的生產(chǎn)環(huán)境中穩(wěn)定運行，涉及互聯(lián)網(wǎng)、游戲、金融、保險、制造業(yè)、銀行、證券等多個行業(yè)，最大集群包含數(shù)百個節(jié)點及數(shù)百 TB 數(shù)據(jù)，業(yè)務(wù)場景包含純 OLTP、純 OLAP 以及混合負(fù)載。另外，既有使用 TiDB 當(dāng)做關(guān)系數(shù)據(jù)庫的場景，也有只用 TiKV 作為分布式 Key Value 存儲的場景。

這幾個月，在這些場景中，我們親歷了跨機(jī)房容災(zāi)需求、親歷了幾十萬級別的高吞吐業(yè)務(wù)、親歷了雙十一的流量激增、親歷了高并發(fā)點查、高并發(fā)寫入與上百行復(fù)雜 SQL 的混合負(fù)載、見到過多次的硬件/網(wǎng)絡(luò)故障、見到過操作系統(tǒng)內(nèi)核/編譯器的 Bug。

簡而言之，我們的世界充滿了未知，而分布式關(guān)系型數(shù)據(jù)庫這樣一種應(yīng)用廣泛、功能豐富且非常關(guān)鍵的基礎(chǔ)軟件，最大的困難就是這些“未知”。在 2.1 版本中，我們引入了不少新的特性來抵御這些未知，適配各種復(fù)雜的場景，提升性能和穩(wěn)定性，幫助我們的用戶更好地支撐復(fù)雜的業(yè)務(wù)。

在 2.1 版本中，我們對 TiDB 的 Cost-based Optimizer 做了改進(jìn)，希望這個優(yōu)化器能夠處理各種復(fù)雜的 Query，盡量少的需要人工介入去處理慢 SQL。例如對 Index Join 選擇索引、外表的優(yōu)化，對關(guān)聯(lián)子查詢的優(yōu)化，顯著地提升了復(fù)雜 SQL 的查詢效率。

當(dāng)然，除了自動的查詢優(yōu)化之外，2.1 也增加了更多的手動干預(yù)機(jī)制，比如對 Join 算子的 Hint、Update/Delete 語句的 Hint。用戶可以在優(yōu)化器沒有指定合適的計劃時，手動干預(yù)結(jié)果或者是用來確保查詢計劃穩(wěn)定。

在 2.1 版本中，我們對部分物理算子的執(zhí)行效率進(jìn)行了優(yōu)化，特別是對 Hash Aggregation 和 Projection 這兩個算子進(jìn)行了并行化改造，另外重構(gòu)了聚合算子的運行框架，支持向量化計算。

得益于這些優(yōu)化，在 TPC-H 這種 OLAP 的測試集上，2.1 比 2.0 版本有了顯著的性能提升，讓 2.1 版本更好的面對 HTAP 應(yīng)用場景。

在 2.1 版本中，我們引入了 Raft PreVote、Raft Learner、Raft Region Merge 三個新特性：

PreVote 是在 Raft Group Member 發(fā)起投票之前，預(yù)先檢查是否能被其他成員所支持，以避免集群中被網(wǎng)絡(luò)隔離的節(jié)點重新接入集群中的時候引發(fā)性能抖動，提升集群穩(wěn)定性。2.1 版本已經(jīng)支持 PreVote 功能，并默認(rèn)打開。

Learner 是只同步數(shù)據(jù)不參與投票的 Raft Group Member。在新加副本的時候，首先增加 Learner 副本，以避免添加副本過程中，部分 TiKV 節(jié)點故障引發(fā)丟失多數(shù)副本的情況發(fā)生，以提升集群的安全性。2.1 版本已經(jīng)支持 Learner 功能，并默認(rèn)打開。

Region Merge 用于將多個過小的 Region 合并為一個大的 Region，降低集群的管理成本，對于長期運行的集群以及數(shù)據(jù)規(guī)模較大的集群的性能、穩(wěn)定性有幫助。2.1 版本已經(jīng)支持 Region Merge 功能，尚未默認(rèn)打開。

這些新特性的引入，有助于提升存儲集群尤其是大規(guī)模集群的穩(wěn)定性和性能。

統(tǒng)計信息的及時性對查詢計劃的正確性非常重要。在 2.1 版本中，我們提供了基于 Query Feedback 的動態(tài)增量更新機(jī)制。

在制定查詢計劃時，會根據(jù)現(xiàn)有的統(tǒng)計信息估算出需要處理的數(shù)據(jù)量；在執(zhí)行查詢計劃時，會統(tǒng)計出真實處理的數(shù)據(jù)量。TiDB 會根據(jù)這兩個值之間的差距來更新統(tǒng)計信息，包括直方圖和 CM-Sketch。在我們的測試中，對于一個完全沒有統(tǒng)計信息的表，經(jīng)過十輪左右的更新，可以達(dá)到統(tǒng)計信息基本穩(wěn)定的狀態(tài)。這對于維持正確的查詢計劃非常重要。

除了動態(tài)增量更新之外，我們對自動全量 Analyze 也提供了更多支持，可以通過 系統(tǒng)變量 指定做自動 Analyze 的時間段。

TiDB 所有的 DDL 操作都是 Online 進(jìn)行，不過在 2.0 以及之前的版本中，所有的 DDL 操作都是串行執(zhí)行，即使 DDL 所操作的表之間沒有關(guān)聯(lián)。比如在對 A 表 Add Index 時候，想創(chuàng)建一個 B 表，需要等待 Add Index 操作結(jié)束。這在一些場景下對用戶使用造成了困擾。

在 2.1 版本中，我們對 DDL 流程進(jìn)行拆分，將 Add Index 操作和其他的 DDL 操作的處理分開。由于在 TiDB 的 DDL 操作中，只有 Add Index 操作需要去回填數(shù)據(jù)，耗時較長，其他的 DDL 操作正常情況下都可以在秒級別完成，所以經(jīng)過這個拆分，可以保證大多數(shù) DDL 操作能夠不需要等待，直接執(zhí)行。

Explain 對于理解查詢計劃至關(guān)重要，2.1 之前的版本，TiDB 追隨 MySQL 的 Explain 輸出格式來展示查詢計劃。但是當(dāng) SQL 比較復(fù)雜時，MySQL 的格式并不利于展示算子之間的層級關(guān)系，不利于用戶定位問題。

2.1 版本中，我們使用縮進(jìn)來展示算子之間的層級關(guān)系，對每個算子的詳細(xì)信息也做了優(yōu)化，希望整個查詢計劃一目了然，幫助用戶盡快定位問題。這篇文檔 可以幫助用戶了解 TiDB 的查詢計劃。

用戶除了通過 Explain 語句查看查詢計劃之外，在 2.1 版本中還可以通過 Explain Analyze 語句查看語句的運行時信息，包括每個算子運行時的處理時間以及處理的數(shù)據(jù)量。這樣可以通過實際的運行結(jié)果，拿到更加精確的信息。

熱點是分布式系統(tǒng)最大的敵人之一，并且用戶的業(yè)務(wù)場景復(fù)雜多變，讓熱點問題捉摸不定，也是最狡猾的敵人。2.1 版本中，我們一方面增強(qiáng)熱點檢測能力，盡可能詳細(xì)地統(tǒng)計系統(tǒng)負(fù)載，更快的發(fā)現(xiàn)熱點；另一方面優(yōu)化熱點調(diào)度策略，用盡可能小的代價，盡快地打散熱點。同時我們也提供了手動分裂 Region 的接口，讓用戶在特殊場景下將單點瓶頸手動分裂開，再由 PD 進(jìn)行負(fù)載均衡。

2.1 版本對 GC（垃圾回收） 模塊進(jìn)行優(yōu)化。一方面減少對線上的寫入的影響，另一方面加快了空間回收速度。在內(nèi)部測試場景中，刪除一個 1TB 的表，新的 GC 機(jī)制能夠在 10 秒內(nèi)回收 99% 左右的空間。

我們針對 OLTP 場景中，點查占多數(shù)的特點進(jìn)行了針對性的優(yōu)化。當(dāng)通過 Unique Key 或者 Primary Key 進(jìn)行數(shù)據(jù)訪問時，在優(yōu)化器和執(zhí)行引擎中都做了改進(jìn)，使得語句的執(zhí)行效率更高，通過 2.1 和 2.0 版本的 Sysbench 對比 可以看到，點查性能提升 50%。

發(fā)布 2.0 的時候，我們同時發(fā)布了在 TPC-H Scale 50 的場景中 2.0 和 1.0 的對比結(jié)果。其中大多數(shù) Query 都有數(shù)量級的提升，部分 Query 在 1.0 中跑不出結(jié)果，在 2.0 中可以順利運行。不過對于 Query17 和 Query18，運行時間依然很長。

我們在相同的場景下，對 2.1 和 2.0 進(jìn)行了 對比測試。從下圖可以看到（縱坐標(biāo)是 Query 的響應(yīng)時間，越低越好），之前的兩個慢 Query 的運行時間大幅縮短，其他的 Query 也有一定程度的提升。這些提升一方面得益于查詢優(yōu)化器以及執(zhí)行引擎的改進(jìn)，另一方面 得益于 TiKV 對連續(xù)數(shù)據(jù)掃描的性能優(yōu)化。

為了讓用戶更方便的使用 TiDB，我們提供了三個工具：

TiDB Lightning 用于將全量數(shù)據(jù)導(dǎo)入到 TiDB 中，這個工具可以提升全量數(shù)據(jù)導(dǎo)入速度，目前內(nèi)部測試場景中，一小時可以導(dǎo)入 100GB 數(shù)據(jù)。

TiDB Binlog 用于將 TiDB 中的數(shù)據(jù)更新實時同步到下游系統(tǒng)中，可以用于做主從集群同步或者是將 TiDB 中的數(shù)據(jù)同步回 MySQL。

TiDB DM（Data-Migration）用于將 MySQL/MariaDB 中的數(shù)據(jù)通過 Binlog 實時同步到 TiDB 集群中，并且提供 Binlog 數(shù)據(jù)轉(zhuǎn)換功能，可以將 Binlog 中的表/庫名稱進(jìn)行修改，或者是對數(shù)據(jù)內(nèi)容本身做修改和裁剪。

上述三個工具可以將 TiDB 和周邊的系統(tǒng)打通，既能將數(shù)據(jù)同步進(jìn) TiDB，又可以將數(shù)據(jù)同步出來。所以無論是遷移、回退還是做數(shù)據(jù)熱備，都有完整的解決方案。

我們相信戰(zhàn)勝“未知”最好的武器就是社區(qū)的力量，基礎(chǔ)軟件需要堅定地走開源路線。為了讓社區(qū)更深入的了解 TiDB 的技術(shù)細(xì)節(jié)并且更好地參與到項目中來，我們今年已經(jīng)完成超過 20 篇源碼閱讀文章，項目的設(shè)計文檔（TiDB 和 TiKV）已經(jīng)在 GitHub 上面公開出來，項目的開發(fā)過程也盡量通過 Github Issue/Project 向社區(qū)展示。一些 Feature 設(shè)計方案的討論也會通過在線視頻會議的方式方便社區(qū)參與進(jìn)來，這里 可以看到會議安排。

從 TiDB 2.0 版發(fā)布到現(xiàn)在的半年多時間，TiDB 開源社區(qū)新增了 87 位 Contributor，其中 杜川 成為了 TiDB Committer，他已經(jīng)貢獻(xiàn)了 76 次 PR，還有一些活躍的 Contributor 有希望成為下一批 Committer。

在這里我們對社區(qū)貢獻(xiàn)者表示由衷的感謝，希望更多志同道合的人能加入進(jìn)來，也希望大家在 TiDB 這個開源社區(qū)能夠有所收獲！