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

时间 2020-06-07

标签 tidb 4.0 leading real time htap database ready cloud 栏目云服务繁體版

原文原文链接

通过一年多的开发，TiDB 4.0 终于迎来 GA 版本，做为 TiDB「面向将来的数据库」道路上面的一个重要的里程碑，TiDB 4.0 不光在稳定性、易用性、性能、云原生等各个方面都有了巨大的进步，新增的特性也让 TiDB 产品可以支持更多元的业务类型。mysql

架构师面对业务，常常须要回答如下问题：git

业务数据独立离散，互相没有关联，不须要 ACID，容量须要可扩展？用 NoSQL！
业务数据互相关联，须要保证 ACID，存储容量可预测在一个相对范围？用传统关系数据库！
业务数据须要作数据分析，须要关联多表，执行聚合等操做？用分析型数据库！

若是让咱们回答上述问题，咱们的回答只有一个：TiDB 4.0！github

Real-Time HTAP

咱们一直有一个愿望，当用户在使用 TiDB 的时候，并不须要太关注本身的业务究竟是 OLTP 类型的，仍是 OLAP 类型的（由于不少时候，用户本身其实也并不能很好的对业务进行区分），不管怎样的 SQL，都能在 TiDB 上面高效率的执行。这个愿望，在 TiDB 4.0 终于获得了实现，咱们提供了一套 Real-Time 的 Hybrid Transaction/Analytical Processing (HTAP) 架构解决方案：sql

实时的强一致性。在 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 还会有更进一步的提高。以下是在一些通用性能测试场景下面的数据：架构

配置：less

组件	实例类型	数量
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