經過一年多的開發，TiDB 4.0 終於迎來 GA 版本，作爲 TiDB「面向未來的數據庫」道路上面的一個重要的里程碑，TiDB 4.0 不光在穩定性、易用性、性能、雲原生等各個方面都有了巨大的進步，新增的特性也讓 TiDB 產品能夠支持更多元的業務類型。
架構師面對業務，經常需要回答以下問題：
-
業務數據獨立離散，互相沒有關聯，不需要 ACID，容量需要可擴展？用 NoSQL！
-
業務數據互相關聯，需要保證 ACID，存儲容量可預測在一個相對範圍？用傳統關係數據庫！
-
業務數據需要做數據分析，需要關聯多表，執行聚合等操作？用分析型數據庫！
如果讓我們回答上述問題，我們的回答只有一個：TiDB 4.0！
Real-Time HTAP
我們一直有一個願望，當用戶在使用 TiDB 的時候，並不需要太關注自己的業務到底是 OLTP 類型的，還是 OLAP 類型的（因爲很多時候，用戶自己其實也並不能很好的對業務進行區分），無論怎樣的 SQL，都能在 TiDB 上面高效率的執行。這個願望，在 TiDB 4.0 終於得到了實現，我們提供了一套 Real-Time 的 Hybrid Transaction/Analytical Processing (HTAP) 架構解決方案：
-
實時的強一致性。在 TiDB 裏面更新的數據會實時的同步到 TiFlash，保證 TiFlash 在處理的時候一定能讀取到最新的數據。
-
TiDB 的 SQL 計算層可以智能判斷選擇行存或者列存，以應對各種不同的查詢場景，無需用戶干預。
Serverless
在 TiDB 4.0，我們不光在 Cloud 上面支持了 Real-Time HTAP，也引入了彈性調度系統，真正的讓 TiDB 在 Cloud 上面變成了一個 Serverless 數據庫。
現在，用戶只需要在雲上（或者自己的 K8s 集羣）使用最小規模集羣部署 TiDB 集羣，配置好規則（譬如當 TiDB 的 CPU 超過 50%，自動擴容一臺 TiDB 節點），TiDB 就會根據用戶自身的業務負載，自動做一些事情，包括：
-
彈性的擴縮容，當業務高峯來臨，TiDB 會自動增加實例，滿足業務請求，反之也能自動收縮實例；
-
自動分散讀負載高的熱點區域；
-
熱點隔離，將熱點業務數據移動到單獨的實例上面，保證不影響其他業務。
這個功能在 4.0 中第一次亮相，我相信這個功能會成爲未來很多可能性的基石。
Performance
相比於 TiDB 3.0，TiDB 4.0 在性能上面，取得了巨大的進步，在 Sysbench 和 TPC-C 等 OLTP 的 Benchmark 中，大多有 30% ~ 50% 的性能提升，對於類似 TPC-H 類型的查詢，速度也有大幅度的提升，另外對於實時分析類的查詢加上 TiFlash 還會有更進一步的提升。如下是在一些通用性能測試場景下面的數據：
配置：
| 組件 | 實例類型 | 數量 |
|---|---|---|
| PD | AWS m5.xlarge | 3 |
| TiKV | AWS i3.4xlarge | 3 |
| TiDB | AWS c5.4xlarge | 3 |
Sysbench
16 張表，每張表 1000 萬數據
TPC-C
縱軸越高代表性能越好
TPC-H
10G
縱軸越低代表性能越好
Other Major Features and Improvements
TiDB 4.0 還新增了非常多的特性和改進，無論從安全、生態，以及功能增強上面都有了很大的提升。
在安全上面：
-
支持 TLS，並且能動態在線對 Certificate 進行更新。
-
Encryption at Rest，支持數據透明加密，保證數據的可靠和安全。
在 TiDB 生態上面：
-
增加 TiDB 官方的組件管理工具 TiUP，使用 TiUP 用戶可以方便的在 1 分鐘以內部署好 TiDB 集羣，詳細可以參考 tiup.io；
-
在分佈式系統上面進行故障定位是一件很困難的事情，我們在 TiDB 4.0 提供了一個可視化的 Dashboard，讓用戶能方便的對 TiDB 性能瓶頸，故障等進行定位，大家可以閱讀 Key Visualizer: Observe Distributed Databases to Discover the Unknowns 來看一些實際的診斷事例；
-
隨着用戶在 TiDB 存入越來越多數據，如何快速的備份和恢復成了我們的一個很大的挑戰。在 TiDB 4.0，我們提供了分佈式備份工具 - BR(Backup&Restore)，使用 BR，用戶可以非常方便的將 TiDB 數據備份到共享存儲，雲存儲（S3）等地方，詳細可以參考文章：How to Back Up and Restore a 10-TB Cluster at 1+ GB/s；
-
爲了更快速的將業務的數據在 TiDB 內的變更同步給外部系統，TiDB 4.0 提供了 Change Data Capture(CDC) 的支持，大家可以閱讀文章 TiCDC: Replication Latency in Milliseconds for 100+ TB Clusters 來了解 TiCDC 是如何做到毫秒級別延遲的數據同步的。
在 TiDB 功能上面：
-
TiDB 4.0 去掉了之前 100MB 的事務大小限制，現在能支持最多 10GB 的事務，有了這個特性，用戶可以方便的一個事務裏面處理大量的數據，而不用考慮分批處理問題。具體可以參考 Large Transactions in TiDB。另外，TiDB 4.0 也正式將悲觀鎖模式作爲自己的默認事務模型，使用悲觀鎖，TiDB 4.0 能更好的去兼容 MySQL，也能方便用戶更方便的將自己的業務從 MySQL 遷移到 TiDB 中，詳見 Pessimistic Locking: Better MySQL Compatibility, Fewer Rollbacks Under High Load。
-
在 TiDB 長時間運行過程中，隨着數據的變更，優化器可能會選錯索引，出現慢查詢，影響業務。爲了解決這個問題，在 TiDB 4.0，我們引入了 SQL Plan Management(SPM)，通過 SPM，TiDB 能很好的控制查詢優化器儘量選擇最優的執行計劃，用戶也不需要修改代碼去顯示的添加 force index 來控制優化器，詳見： SQL Plan Management: Never Worry About Slow Queries Again。
除了上面提到的特性，TiDB 4.0 還新增了 Sequence，Flashback，Case-Insensitive Collation，Add/Drop primary key 等特性，大家可以在使用 TiDB 4.0 的時候體驗。
總結
作爲一款里程碑產品，我們有理由相信，TiDB 4.0 會給大家帶來更多的驚喜，也歡迎大家開始使用 TiDB 4.0，多給我們反饋，共同完善 TiDB，一起打造面向未來的數據庫產品。
在此，還要特別感謝 TiDB 開發者社區所有小夥伴的貢獻！TiDB 開發者社區以 SIG（Special Interest Groups） 爲單位管理組織開發者。每個模塊都有其固定的 SIG 負責新功能開發，性能優化，穩定性保障等。如果您想要成爲 TiDB 的開發者，加入感興趣的 SIG，與一線工程師面對面討論，無疑是最好的方式。以下是截至 TiDB 4.0 GA 發佈時 ，爲 TiDB 4.0 作出貢獻的 TiDB 社區開發者名單及其對應的 SIG 名稱。
感謝以下組織的社區貢獻者：
| SIG name | GitHub ID | Organization |
|---|---|---|
| raft | ice1000 | JetBrains |
| execution | Rustin-Liu | Morningstar |
| ddl | spongedu | Tencent |
| execution | AerysNan | ThssSE |
| raft | morefreeze | xiaomi |
| coprocessor | hawkingrei | bilibili |
| execution | hey-kong | CS |
| execution | jacklightChen | East |
| coprocessor | Renkai | fordeal.com |
| execution | erjiaqing | |
| coprocessor | cireu | Guangdong |
| scheduling | mantuliu | Hive |
| tiup | qinzuoyan | Xiaomi |
| engine | fredchenbj | Yidian |
| execution | shihongzhi | Youdao |
全部貢獻者名單：
