1 什么是TiDB
# 0 什么是TiDB
TiDB 是一个分布式 NewSQL 数据库,它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议,具有数据强一致的高可用特性,是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。
TiDB (opens new window) 是 PingCAP (opens new window) 公司自主设计、研发的开源分布式关系型数据库,是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP)的融合型分布式数据库产品,具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
# 1 什么是NewSQL
数据库发展至今已经有3代了:
- SQL,传统关系型数据库,例如 MySQL
- NoSQL,例如 MongoDB,Redis
- NewSQL
# 1 传统SQL的问题
互联网在本世纪初开始迅速发展,互联网应用的用户规模、数据量都越来越大,并且要求7X24小时在线。
传统关系型数据库在这种环境下成为了瓶颈,通常有2种解决方法:
# 1 升级服务器硬件
虽然提升了性能,但总有天花板。
# 2 数据分片
使用分布式集群结构
对单点数据库进行数据分片,存放到由廉价机器组成的分布式的集群里,可扩展性更好了,但也带来了新的麻烦。
以前在一个库里的数据,现在跨了多个库,应用系统不能自己去多个库中操作,需要使用数据库分片中间件。
分片中间件做简单的数据操作时还好,但涉及到跨库join、跨库事务时就很头疼了,很多人干脆自己在业务层处理,复杂度较高。
# 2 NoSQL 的问题
后来 NoSQL 出现了,放弃了传统SQL的强事务保证和关系模型,重点放在数据库的高可用性和可扩展性。
# 2.1 优点
- 高可用性和可扩展性,自动分区,轻松扩展
- 不保证强一致性,性能大幅提升
- 没有关系模型的限制,极其灵活
# 2.2 缺点
- 不保证强一致性,对于普通应用没问题,但还是有不少像金融一样的企业级应用有强一致性的需求。
- 不支持 SQL 语句,兼容性是个大问题,不同的 NoSQL 数据库都有自己的 api 操作数据,比较复杂。
# 3 NewSQL 特性
NewSQL 提供了与 NoSQL 相同的可扩展性,而且仍基于关系模型,还保留了极其成熟的 SQL 作为查询语言,保证了ACID事务特性。
简单来讲,NewSQL 就是在传统关系型数据库上集成了 NoSQL 强大的可扩展性。
传统的SQL架构设计基因中是没有分布式的,而 NewSQL 生于云时代,天生就是分布式架构。
# 3.1 NewSQL 的主要特性:
- SQL 支持,支持复杂查询和大数据分析。
- 支持 ACID 事务,支持隔离级别。
- 弹性伸缩,扩容缩容对于业务层完全透明。
- 高可用,自动容灾。
# 4 三种SQL的对比
# 2 TiDB怎么来的
著名的开源分布式缓存服务 Codis 的作者,PingCAP联合创始人& CTO ,资深 infrastructure 工程师的黄东旭,擅长分布式存储系统的设计与实现,开源狂热分子的技术大神级别人物。即使在互联网如此繁荣的今天,在数据库这片边界模糊且不确定地带,他还在努力寻找确定性的实践方向。
直到 2012 年底,他看到 Google 发布的两篇论文,如同棱镜般,折射出他自己内心微烁的光彩。这两篇论文描述了 Google 内部使用的一个海量关系型数据库 F1/Spanner ,解决了关系型数据库、弹性扩展以及全球分布的问题,并在生产中大规模使用。“如果这个能实现,对数据存储领域来说将是颠覆性的”,黄东旭为完美方案的出现而兴奋, PingCAP 的 TiDB 在此基础上诞生了。
公司历史可以参考下PingCAP (opens new window)
# 3 TiDB社区版和企业版
TiDB分为社区版以及企业版,企业版收费提供服务以及安全性的支持
# 4 TIDB核心特性
# 4.1 水平弹性扩展
通过简单地增加新节点即可实现 TiDB 的水平扩展,按需扩展吞吐或存储,轻松应对高并发、海量数据场景
得益于 TiDB 存储计算分离的架构的设计,可按需对计算、存储分别进行在线扩容或者缩容,扩容或者缩容过程中对应用运维人员透明。
# 4.2 分布式事务支持
TiDB 100% 支持标准的 ACID 事务
# 4.3 金融级高可用
相比于传统主从 (M-S) 复制方案,基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证,且在不丢失大多数副本的前提下,可以实现故障的自动恢复 (auto-failover),无需人工介入
数据采用多副本存储,数据副本通过 Multi-Raft 协议同步事务日志,多数派写入成功事务才能提交,确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。
# 4.4 实时 HTAP
TiDB 作为典型的 OLTP 数据库,同时兼具强大的 OLAP 性能,配合 TiSpark,可提供一站式 HTAP 解决方案,一份存储同时处理 OLTP & OLAP 无需传统繁琐的 ETL 过程
提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎,TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据,确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器,解决 HTAP 资源隔离的问题。
# 4.5 云原生的分布式数据库
TiDB 是为云而设计的数据库,同 Kubernetes 深度耦合,支持公有云、私有云和混合云,使部署、配置和维护变得十分简单。TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景,更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。 TiDB 对业务没有任何侵入性,能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题,专注于业务开发,极大的提升研发的生产力
# 4.6 高度兼容 MySQL
兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态,应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。
提供丰富的数据迁移工具帮助应用便捷完成数据迁移,大多数情况下,无需修改代码即可从 MySQL 轻松迁移至 TiDB,分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
# 5 OLTP&OLAP
# 5.1 OLTP(联机事务处理)
OLTP(Online Transactional Processing) 即联机事务处理,OLTP 是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,记录即时的增、删、改、查,比如在银行存取一笔款,就是一个事务交易
联机事务处理是事务性非常高的系统,一般都是高可用的在线系统,以小的事务以及小的查询为主,评估其系统的时候,一般看其每秒执行的Transaction以及Execute SQL的数量。在这样的系统中,单个数据库每秒处理的Transaction往往超过几百个,或者是几千个,Select 语句的执行量每秒几千甚至几万个。典型的OLTP系统有电子商务系统、银行、证券等,如美国eBay的业务数据库,就是很典型的OLTP数据库。
# 5.2 OLAP(联机分析处理)
OLAP(Online Analytical Processing) 即联机分析处理,是数据仓库的核心部心,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。典型的应用就是复杂的动态报表系统
在这样的系统中,语句的执行量不是考核标准,因为一条语句的执行时间可能会非常长,读取的数据也非常多。所以,在这样的系统中,考核的标准往往是磁盘子系统的吞吐量(带宽),如能达到多少MB/s的流量。
# 5.3 特性对比
OLTP和OLAP的特性对比
--- | OLTP | OLAP |
---|---|---|
实时性 | OLTP 实时性要求高,OLTP 数据库旨在使事务应用程序仅写入所需的数据,以便尽快处理单个事务 | OLAP 的实时性要求不是很高,很多应用顶多是每天更新一下数据 |
数据量 | OLTP 数据量不是很大,一般只读 / 写数十条记录,处理简单的事务 | OLAP 数据量大,因为 OLAP 支持的是动态查询,所以用户也许要通过将很多数据的统计后才能得到想要知道的信息,例如时间序列分析等等,所以处理的数据量很大 |
用户和系统的面向性 | OLTP 是面向顾客的,用于事务和查询处理 | OLAP 是面向市场的,用于数据分析 |
数据库设计 | OLTP 采用实体 - 联系 ER 模型和面向应用的数据库设计 | OLAP 采用星型或雪花模型和面向主题的数据库设计 |
# 5.4 设计角度区别
--- | OLTP | OLAP |
---|---|---|
用户 | 操作人员,低层管理人员 | 决策人员,高级管理人员 |
功能 | 日常操作处理 | 分析决策 |
主要工作 | 增、删、改 | 查询 |
DB 设计 | 面向应用 | 面向主题 |
数据 | 当前的,最新的细节,二维的,分立的 | 历史的,聚集的,多维集成的,统一的 |
存取 | 读/写数十条记录 | 读上百万条记录 |
工作单位 | 简单的事务 | 复杂的查询 |
用户数 | 上千个 | 上百个 |
DB 大小 | 100MB-GB | 100GB-TB |