The Overview of TiDB 4.0

在上篇文章中，我司 CTO 黃東旭分享了 咱們對「將來數據庫」的展望，很高興咱們一直走在「寫一個更好的數據庫」的初心之路上。4 月 8 日是 PingCAP 成立五週年的日子，咱們也在這一天發佈了具備里程碑意義的 TiDB 4.0 首個 RC 版本。

在 4.0 裏咱們完成了不少重要的、頗有潛力的特性，本文將從多角度介紹 TiDB 4.0，讓你們從安裝、使用、運維、生態及雲等多個層面有所瞭解，也歡迎你們使用並反饋建議。

一分鐘部署 TiDB 集羣

「在單機部署一個 TiDB 集羣要多久？」

以前，咱們其實很難回答這個問題，但如今能夠很自豪的說「一分鐘」。爲何會這麼快？由於咱們專門爲 TiDB 4.0 作了一個全新的組件管理工具—— TiUP 。

固然咱們要先安裝 TiUP，使用以下命令：

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

裝完以後，控制檯會提示使用 tiup playground 來在單機啓動一個 TiDB 集羣，而後咱們就可使用 MySQL 客戶端鏈接 TiDB 集羣，而且愉快地開始測試了。

上面只是單機測試的狀況，真的要生產環境上線了，咱們如何部署 TiDB 集羣呢？假設咱們如今有十臺機器，部署一個 TiDB 集羣要多久？以前咱們仍然很難回答這個問題，但如今，答案仍然是「一分鐘」，由於咱們能夠方便地使用 TiUP cluster 功能。

首先咱們準備好部署拓撲，能夠參考 TiUP cluster 的樣例。

而後執行 deploy 命令：

tiup cluster deploy test v4.0.0-rc topology.yaml  -i ~/.ssh/id_rsa

上面咱們就部署好了一個名字叫作 test 的 TiDB 集羣，使用最新的 v4.0.0-rc 版本。而後咱們能夠經過 test 這個名字來運維這個 TiDB 集羣了，譬如使用 tiup cluster start test 來啓動集羣。

是否是很酷？更酷的是，TiUP 會管理 TiDB 整個生態裏面的組件，不管是 TiDB、TiFlash，仍是生態工具，均可以經過 TiUP 來進行管理和使用，用戶也能夠給 TiUP 添加對應的組件工具。

OLTP or OLAP，仍是個難題嗎？

個人業務究竟是 OLTP 仍是 OLAP？咱們相信，不少時候，用戶都不能很清楚的回答出來。但咱們知道，用戶最想要的是「不管個人業務是怎樣的，我要在你的數據庫裏面都能快速的跑出來結果」。

這個需求看似簡單，要知足倒是很是的困難，可是在 TiDB 4.0，咱們終於能夠很自豪的說，離完全搞定這個需求更接近了一步，由於咱們提供一套完備的 Hybrid transaction/analytical processing (HTAP) 解決方案，那就是 TiDB + TiFlash 。

簡單來講，咱們會在 TiDB 裏面處理 OLTP 類型業務，在 TiFlash 裏面處理 OLAP 類型業務，相比於傳統的 ETL 方案，或者其餘的 HTAP 解決方案，咱們作了更多：

1. 實時的強一致性。在 TiDB 裏面更新的數據會實時的同步到 TiFlash，保證 TiFlash 在處理的時候必定能讀取到最新的數據。
2. TiDB 能夠智能判斷選擇行存或者列存，以應對各類不一樣的查詢場景，無需用戶干預。

讓系統更有可觀測性

「我只是想知道哪裏出了問題，爲啥還須要瞭解 TiDB 原理？」——來自某用戶的吶喊。

在 TiDB 4.0 以前，如何高效的排查系統出現的問題，其實算一件不算容易的事情。DBA 同窗須要瞭解 TiDB 基本的架構，甚至還須要比較熟悉上千個 TiDB 監控指標，並且還得實戰積累一些經驗，才能保證下次在遇到問題的時候比較能高效地解決。爲了解決這個問題，咱們在 4.0 提供了內置的 Dashboard ，咱們但願大部分問題，都能經過 Dashboard 方便地定位。

咱們一直相信「一圖勝千言」，不少問題經過可視化的方式就能直接地觀測到。在 Dashboard 裏面，咱們提供了：

1. 熱點可視化（KeyViz），能讓咱們很是直觀的看到一段時間 workload 訪問數據的分佈狀況，能讓咱們快速診斷出系統是否有讀寫熱點等異常。
2. SQL 語句分析，能讓咱們快速地知道究竟是哪些 SQL 佔用了系統太多的資源。
3. 集羣診斷，能自動地分析集羣現階段的狀態，給出診斷報告，告訴用戶潛在的風險。

百 TB+ 集羣快速備份恢復

雖然 TiDB 默認使用三副原本保障數據高可用，但不少用戶，尤爲是在金融、證券等行業的用戶，很是但願能按期的將數據進行按期備份。在早期 TiDB 集羣規模小的時候，咱們還可使用傳統的備份工具進行備份，可是當集羣數據到了幾十 TB 甚至百 TB 規模的時候，咱們就須要考慮另外的方式了。

在 TiDB 4.0 裏面，咱們提供了一個分佈式備份工具 BR（Backup&Restore），它直接對 TiDB 進行分佈式備份，並將數據存放到用戶的共享存儲，或者雲上 S3 等地方。能夠這麼說，集羣規模越大，分佈式效果越好，BR 備份就越快。在咱們內部的測試中，BR 能提供 1GB/s 的備份和恢復速度 。

咱們不光提供了集羣全量備份工具 BR，也同時提供了增量數據變動同步工具 CDC（Change Data Capture），CDC 也是直接對 TiDB 的數據變動進行訂閱，能夠提供秒級別、最快毫秒級別的增量數據變動交付能力。

固然，不光只有 BR 和 CDC，TiDB 4.0 給用戶提供了完整的一套生態工具，不管是上面提到的部署運維工具 TiUP，還有數據遷移工具 DM（Data Migration），數據導入工具 TiDB Lightning 等。經過這些工具，咱們能方便地將 TiDB 與用戶的其餘生態系統整合到一塊兒，給用戶提供更多高價值服務。

你好！Serverless TiDB

咱們一直但願，讓用戶無感知的使用 TiDB，他只須要關注本身的業務就能夠了。TiDB 對於用戶來講就是一種數據庫資源，他能夠按需去使用。這個其實就是在雲服務領域很是重要的一個理念：Serverless。

在 TiDB 4.0 以前，用戶爲了保證 TiDB 集羣能抗住業務高峯請求，會在一開始就規劃好整個集羣規模，但大多數時候，這些資源是處於利用率不高狀態的。但在 4.0 裏面，基於 Kubernetes，咱們實現了彈性調度機制，真正讓 TiDB 在雲上成爲了一個 Serverless 架構。

如今，用戶只須要使用最小規模集羣部署 TiDB 集羣，而後 TiDB 會根據用戶自身的業務負載，自動作一些事情，包括：

1. 彈性的擴縮容，當業務高峯來臨，TiDB 會自動增長實例，知足業務請求，反之也能自動收縮實例。
2. 自動分散讀負載高的熱點區域。
3. 熱點隔離，將熱點業務數據移動到單獨的實例上面，保證不影響其餘業務。

聽起來是否是很酷？咱們只須要先用很低的成原本啓動 TiDB 集羣，後面的成本會隨着業務自動的進行彈性處理，也就是俗稱的「按需付費」。而這一切，均可以在即將推出的 TiDB DBaaS 雲平臺上面去直接體驗。

寫在最後

上面只是列舉了一些 4.0 的特性，固然還有不少特性沒有在這裏一一介紹，你們能夠慢慢地體驗，TiDB 4.0 RC Release Notes 。

另外，這裏放上一個簡單的跑分，讓你們快速感覺一下 TiDB 4.0 的性能提高：

TPC-C （注：測試使用 TiDB DBaaS（AWS） 高配置集羣，其中 TiDB 使用 2 臺 16核 32G 的 c5.4xlarge 實例，TiKV 使用 3 臺 16核 122G 的 i3.4xlarge 實例）

TPC-H 10G （注：TPC-H 單位是秒，數值越小，性能越好，測試 TiDB 使用 2 臺 16 核 32G 的 c5.4xlarge 實例，TiKV 使用 3 臺 16 核 122G 的 i3.4xlarge 實例）

Sysbench 16 table, 10000000 table size （注：測試使用 3 臺 16 核 62G 虛擬機部署 3 TiKV，1 臺 40 核 189G 服務器部署 1 TiDB）

咱們相信，TiDB 4.0 是一個會讓你們很是興奮的版本，也是 TiDB 走在「將來的數據庫」道路上面一個堅固的里程碑。固然，這個幸福的時刻裏面必定少不了支持咱們的用戶，由於有你們，咱們才能走到如今。咱們也相信，將來 TiDB 會變得愈來愈好，能給用戶帶來更多的價值。

最後歡迎感興趣的夥伴嚐鮮並反饋建議，點擊【這裏】添加 TiDB Robot(wechat: tidbai) 爲好友並回復「新特性」便可進入「TiDB 4.0 嚐鮮羣」交流～