在上篇文章中，我司 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 解決方案，我們做了更多：
-
實時的強一致性。在 TiDB 裏面更新的數據會實時的同步到 TiFlash，保證 TiFlash 在處理的時候一定能讀取到最新的數據。
-
TiDB 可以智能判斷選擇行存或者列存，以應對各種不同的查詢場景，無需用戶干預。
讓系統更有可觀測性
「我只是想知道哪裏出了問題，爲啥還需要了解 TiDB 原理？」——來自某用戶的吶喊。
在 TiDB 4.0 之前，如何高效的排查系統出現的問題，其實算一件不算容易的事情。DBA 同學需要了解 TiDB 基本的架構，甚至還需要比較熟悉上千個 TiDB 監控指標，而且還得實戰積累一些經驗，才能保證下次在遇到問題的時候比較能高效地解決。爲了解決這個問題，我們在 4.0 提供了內置的 Dashboard ，我們希望大部分問題，都能通過 Dashboard 方便地定位。
我們一直相信**「一圖勝千言」**，很多問題通過可視化的方式就能直接地觀測到。在 Dashboard 裏面，我們提供了：
-
熱點可視化（KeyViz），能讓我們非常直觀的看到一段時間 workload 訪問數據的分佈情況，能讓我們快速診斷出系統是否有讀寫熱點等異常。
-
SQL 語句分析，能讓我們快速地知道到底是哪些 SQL 佔用了系統太多的資源。
-
集羣診斷，能自動地分析集羣現階段的狀態，給出診斷報告，告訴用戶潛在的風險。
百 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 會根據用戶自身的業務負載，自動做一些事情，包括：
-
彈性的擴縮容，當業務高峯來臨，TiDB 會自動增加實例，滿足業務請求，反之也能自動收縮實例。
-
自動分散讀負載高的熱點區域。
-
熱點隔離，將熱點業務數據移動到單獨的實例上面，保證不影響其他業務。
聽起來是不是很酷？我們只需要先用很低的成本來啓動 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 嚐鮮羣」**交流～
