TiDB 4.0: The Leading Real-Time HTAP Database is Ready for Cloud

通過一年多的開發，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) 架構解決方案：

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

Serverless

在 TiDB 4.0，咱們不光在 Cloud 上面支持了 Real-Time HTAP，也引入了彈性調度系統，真正的讓 TiDB 在 Cloud 上面變成了一個 Serverless 數據庫。

如今，用戶只須要在雲上（或者本身的 K8s 集羣）使用最小規模集羣部署 TiDB 集羣，配置好規則（譬如當 TiDB 的 CPU 超過 50%，自動擴容一臺 TiDB 節點），TiDB 就會根據用戶自身的業務負載，自動作一些事情，包括：

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

這個功能在 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	Google
coprocessor	cireu	Guangdong
scheduling	mantuliu	Hive
tiup	qinzuoyan	Xiaomi
engine	fredchenbj	Yidian
execution	shihongzhi	Youdao

所有貢獻者名單：

SIG name	GitHub ID
coprocessor	Fullstop000
engine	fredchenbj
execution	b41sh
execution	mmyj
execution	js00070
execution	tsthght
execution	shihongzhi
execution	tangwz
raft	Fullstop000
ddl	lysu
ddl	Deardrops
docs	YiniXu9506
docs	juliezhang1112
docs	ericsyh
docs	aylei
docs	weekface
docs	crazycs520
docs	anotherrachel
planner	zz-jason
planner	XuHuaiyu
planner	lamxTyler
planner	SunRunAway
planner	wjhuang2016
planner	imtbkcat
coprocessor	hawkingrei
coprocessor	koushiro
coprocessor	cireu
coprocessor	Renkai
coprocessor	codeworm96
ddl	reafans
ddl	spongedu
ddl	Rustin-Liu
docs	lance6716
docs	xiaojingchen
docs	IzabelWang
execution	erjiaqing
execution	hey-kong
execution	AerysNan
execution	spongedu
execution	pingyu
execution	TennyZhuang
execution	ekalinin
execution	jacklightChen
execution	AndrewDi
execution	Rustin-Liu
k8s	xiaojingchen
k8s	shinnosuke-okada
k8s	mikechengwei
k8s	shonge
planner	foreyes
planner	SeaRise
raft	morefreeze
raft	csmoe
raft	ice1000
raft	hhkbp2
scheduling	mantuliu
tiup	qinzuoyan
docs	gmhdbjd
docs	3pointer
docs	tiancaiamao
docs	lamxTyler
docs	kissmydb
docs	july2993
docs	lysu
docs	kolbe
docs	csuzhangxc
docs	zhouqiang-cl
docs	superlzs0476
docs	Yisaer
docs	zimulala
docs	huangxiuyan
docs	Deardrops
docs	tennix
docs	amyangfei
docs	liubo0127
docs	lichunzhu
docs	tangenta
execution	k-ye
execution	xiekeyi98
k8s	cwen0
planner	tiancaiamao
planner	wshwsh12
planner	lonng
planner	Deardrops
raft	nrc
raft	siddontang
raft	ngaut
raft	disksing
raft	Hoverbear
tiup	c4pt0r
tiup	YangKeao