TiDB数据库简介特点与应用场景

Posted 2022-12-16 黑马程序员官方

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了TiDB数据库简介特点与应用场景相关的知识，希望对你有一定的参考价值。

一、了解数据库发展史

1.1 数据库技术发展简史

数据库技术产生于20世纪60年代末70年代初，其主要主要研究如何存储，使用和管理数据。随着计算机硬件和软件的发展，数据库技术也不断地发展。数据库技术在理论研究和系统开发上都取得了辉煌的成就。

从数据管理的角度看，数据库技术到目前共经历了如下三个阶段：

人工管理阶段-数据量小独立,用户直接管理
文件系统阶段-使用文件存取数据,冗余度高,管理维护难
数据库系统阶段-专门的数据库软件系统管理数据,高效方便,易于共享维护

按照数据模型发展的主线，数据库技术的形成过程和发展可分为如下三个阶段：

层次和网状数据库管理系统-可以理解为使用指针来表示数据之间的联系
关系数据库管理系统(RDBMS)-可以理解为理解为使用二维表来表示维护数据间的关系
新一代数据库技术的研究和发展-针对关系型数据库存在数据模型，性能，扩展性，伸缩性等方面的缺点，出现了： ORDBMS:面向对象数据库技术。如：PostGreSQL NoSQL:非结构化数据库技术。如
:键值存储数据库：Redis
:列式储数数据库：HBase
:文档型数据库：MongoDB
:图形数据库：Neo4J

NewSQL:这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。如：TiDB

1.2 从mysql到TiDB

如今的数据库种类繁多，RDBMS（关系型数据库）、NoSQL（Not Only SQL）、NewSQL，在数据库领域均有一席之地，可谓百家争鸣之势。那么我们为什么要学习使用TiDB呢？接下来就从我们最熟悉的MySQL的使用说起！

场景引入

假设现在有一个高速发展的互联网公司,核心业务库MySQL的数据量已经近亿行,且还在不断增长中,公司对于数据资产较为重视,所有数据要求多副本保存至少5年,且除了有对历史数据进行统计分析的离线报表业务外,还有一些针对用户数据实时查询的需求,如用户历史订单实时查询

问题分析

1.MySQL能否满足上述场景需求?

根据以往的MySQL使用经验，MySQL单表在 5000 万行以内时，性能较好，单表超过5000万行后，数据库性能、可维护性都会极剧下降。当然这时候可以做MySQL分库分表,如使用Mycat或Sharding-jdbc

2.分库分表的能否解决问题?

分库分表的优点非常明显，如：

将大表拆分成小表，单表数据量控制在 5000 万行以内，使 MySQL 性能稳定可控。

将单张大表拆分成小表后，能水平扩展，通过部署到多台服务器，提升整个集群的 QPS、TPS、Latency 等数据库服务指标。

但是，此方案的缺点也非常明显：

分表跨实例后，产生分布式事务管理难题，一旦数据库服务器宕机，有事务不一致风险。

分表后，对 SQL 语句有一定限制，对业务方功能需求大打折扣。尤其对于实时报表统计类需求，限制非常之大。事实上，报表大多都是提供给高层领导使用的，其重要性不言而喻。

分表后，需要维护的对象呈指数增长（MySQL实例数、需要执行的 SQL 变更数量等）。

问题解决

基于以上核心痛点，我们需要探索新的数据库技术方案来应对业务爆发式增长所带来的挑战，为业务提供更好的数据库服务支撑。

调研市场上的各大数据库,我们可以考虑选用NewSQL技术来解决,因为NewSQL技术有如下显著特点:

- 无限水平扩展能力

- 分布式强一致性，确保数据 100% 安全

- 完整的分布式事务处理能力与 ACID 特性

而TiDB数据库 GitHub的活跃度及社区贡献者方面都可以算得上是国际化的开源项目,是NewSQL技术中的代表性产品,所以我们可以选择使用TiDB数据库!

1.3 TiDB概述

官网

https://pingcap.com/index.html

TiDB可以理解为是MySQL的加强版/分布式MySQL/MySQLPlus

简介

TiDB 是 PingCAP 公司设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和 NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP (Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。

TiDB数据库具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等核心特性，是大数据时代理想的数据库集群和云数据库解决方案。目前，已被近 1000 家不同行业的领先企业应用在实际生产环境，涉及互联网、游戏、银行、保险、证券、航空、制造业、电信、新零售、政府等多个行业，包括美国、欧洲、日本、东南亚等海外用户。

TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。

TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。

1.4 扩展阅读

数据管理技术发展阶段

人工管理阶段 20世纪50年代以前，计算机主要用于数值计算.从当时的硬件看，外存只有纸带，卡片，磁带，没有直接存取设备；从软件看（实际上，当时还未形成软件的整体概念），没有操作系统以及管理数据的软件；从数据看，数据量小，数据无结构，由用户直接管理，且数据间缺乏逻辑组织，数据依赖于特定的应用程序，缺乏独立性.

文件系统阶段 50年代后期到60年代中期，出现了磁鼓，磁盘等数据存储设备.新的数据处理系统迅速发展起来.这种数据处理系统是把计算机中的数据组织成相互独立的数据文件，系统可以按照文件的名称对其进行访问，对文件中的记录进行存取，并可以实现对文件的修改，插入和删除，这就是文件系统.文件系统实现了记录内的结构化,即给出了记录内各种数据间的关系.但是，文件从整体来看却是无结构的.其数据面向特定的应用程序，因此数据共享性差，且冗余度大，管理和维护的代价也很大.

数据库系统阶段

60年代后期，出现了数据库这样的数据管理技术.数据库的特点是数据不再只针对某一特定应用，而是面向全组织，具有整体的结构性，共享性高，冗余度小，具有一定的程序与数据间的独立性，并且实现了对数据进行统一的控制.

数据库模型发展阶段

第一代数据库系统层次和网状数据库管理系统层次和网状数据库的代表产品是IBM公司在1969年研制出的层次模型数据库管理系统。层次数据库是数据库系统的先驱，而网状数据库则是数据库概念、方法、技术的奠基。
第二代数据库系统关系数据库管理系统(RDBMS) 1970年，IBM公司的研究员E.F.Codd在题为《大型共享数据库数据的关系模型》的论文中提出了数据库的关系模型，为关系数据库技术奠定了理论基础。到了80年代，几乎所有新开发的数据库系统都是关系型的。真正使得关系数据库技术实用化的关键人物是James Gray。Gray在解决如何保障数据的完整性、安全性、并发性以及数据库的故障恢复能力等重大技术问题方面发挥了关键作用。关系数据库系统的出现，促进了数据库的小型化和普及化，使得在微型机上配置数据库系统成为可能。
新一代数据库技术的研究和发展

目前已从多方面发展了现行的数据库系统技术。我们可以从数据模型、新技术内容、应用领域三个方面概括新一代数据库系统的发展。

(1) 面向对象的方法和技术对数据库发展的影响最为深远

80年代，面向对象的方法和技术的出现，对计算机各个领域，包括程序设计语言、软件工程、信息系统设计以及计算机硬件设备等都产生了深远的影响，也给面临新挑战的数据库技术带来了新的机遇和希望。数据库研究人员借鉴和吸收了面向对象的方法和技术，提出了面向对象的数据库模型(简称对象模型)。当前有许多研究是建立在数据库已有的成果和技术上的，针对不同的应用，对传统的DBMS，主要是RDBMS进行不同层次上的扩充，例如建立对象关系(OR)模型和建立对象关系数据库(ORDB)。

(2) 数据库技术与多学科技术的有机结合

数据库技术与多学科技术的有机结合是当前数据库发展的重要特征。计算机领域中其他新兴技术的发展对数据库技术产生了重大影响。传统的数据库技术和其他计算机技术的结合、互相渗透，使数据库中新的技术内容层出不穷。数据库的许多概念、技术内容、应用领域，甚至某些原理都有了重大的发展和变化。建立和实现了一系列新型的数据库，如分布式数据库、并行数据库、演绎数据库、知识库、多媒体库、移动数据库等，它们共同构成了数据库大家族。

(3) 面向专门应用领域的数据库技术的研究

为了适应数据库应用多元化的要求，在传统数据库基础上，结合各个专门应用领域的特点，研究适合该应用领域的数据库技术，如工程数据库、统计数据库、科学数据库、空间数据库、地理数据库、Web数据库等，这是当前数据库技术发展的又一重要特征。同时，数据库系统结构也由主机/终端的集中式结构发展到网络环境的分布式结构，随后又发展成两层、三层或多层客户/服务器结构以及Internet环境下的浏览器/服务器和移动环境下的动态结构。多种数据库结构满足了不同应用的需求，适应了不同的应用环境。

SQL，NoSQL，NewSQL

关系型数据库(RDBMS,即SQL数据库) 商业软件： Oracle，DB2 开源软件：MySQL，PostgreSQL 单机版本已经很难满足海量数据的需求
NoSQL

NoSQL = Not Only SQL，意即“不仅仅是SQL，提倡运用非关系型的数据存储

普遍选择牺牲掉复杂 SQL 的支持及 ACID 事务换取弹性扩展能力

通常不保证强一致性的(支持最终一致)

主要分类
键值（Key-Value）数据库：如 MemcacheDB，Redis
文档存储：如 MongoDB
列存储：方便存储结构化和半结构化数据，并做数据压缩，对某几列的查询有非常大的IO优势：如 HBase，Cassandra
图数据库：存储图关系(注意：不是图片)。如 Neo4J

NewSQL

针对OLTP的读写，提供与NOSQL相同的可扩展性和性能，同时能支持满足ACID特性的事务，即保持NoSQL的高可扩展和高性能，并且保持关系模型

为什么需要NewSQL NoSQL 不能完全取代 RDBMS 单机RDBMS 无法满足性能需求使用“单机RDBMS + 中间件”方式，在中间件层很难解决分布式事务、高可用问题
NewSQL设计架构可以基于全新的数据库平台，也可以基于现有的SQL引擎优化。无共享存储(MPP架构)是比较常见的架构基于多副本实现高可用和容灾分布式查询数据Sharding机制通过2PC，Paxos/Raft等协议实现数据一致
代表产品

Google Spanner

OceanBase

TiDB

OLTP和OLAP

OLTP

强调支持短时间内大量并发的事务操作（增删改查）能力，每个操作涉及的数据量都很小（比如几十到几百字节）

强调事务的强一致性（想想银行转账交易，容不得差错）

举例：“双十一”期间，可能有几十万用户在同一秒内下订单。后台数据库要能够并发的、以近乎实时的速度处理这些订单请求（如果下了订单，十几分钟还没有反应，用户肯定要骂人了）

OLAP

偏向于复杂的只读查询，读取海量数据进行分析计算，查询时间往往很长

举例：“双十一”结束，淘宝的运营人员对订单进行分析挖掘，找出一些市场规律等等。这种分析可能需要读取所有的历史订单进行计算，耗时几十秒甚至几十分钟都有可能。

代表产品：

Greenplum

TeraData

阿里 AnalyticDB

TiDB怎么诞生的?

著名的开源分布式缓存服务 Codis 的作者，PingCAP联合创始人& CTO ，资深 infrastructure 工程师的黄东旭，擅长分布式存储系统的设计与实现，开源狂热分子的技术大神级别人物。即使在互联网如此繁荣的今天，在数据库这片边界模糊且不确定地带，他还在努力寻找确定性的实践方向。

2012 年底，他看到 Google 发布的两篇论文，如同棱镜般，折射出他自己内心微烁的光彩。这两篇论文描述了 Google 内部使用的一个海量关系型数据F1/Spanner，解决了关系型数据库、弹性扩展以及全球分布的问题，并在生产中大规模使用。“如果这个能实现，对数据存储领域来说将是颠覆性的”，黄东旭为完美方案的出现而兴奋， PingCAP 的 TiDB 在此基础上诞生了。

二、了解TiDB数据库的特点和应用场景

2.1 TiDB 整体架构

TiDB 集群主要包括三个核心组件：TiDB Server，PD Server 和 TiKV Server。此外，还有用于解决用户复杂 OLAP 需求的 TiSpark 组件和简化云上部署管理的 TiDB Operator 组件。

架构图解

TiDB Server

TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。

PD Server

Placement Driver (简称 PD) 是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。

PD 通过 Raft 协议保证数据的安全性。Raft 的 leader server 负责处理所有操作，其余的 PD server 仅用于保证高可用。建议部署奇数个 PD 节点。

TiKV Server

TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。

TiSpark

TiSpark 作为 TiDB 中解决用户复杂 OLAP 需求的主要组件，将 Spark SQL 直接运行在 TiDB 存储层上，同时融合 TiKV 分布式集群的优势，并融入大数据社区生态。至此，TiDB 可以通过一套系统，同时支持 OLTP 与 OLAP，免除用户数据同步的烦恼。

TiDB Operator

TiDB Operator 提供在主流云基础设施（Kubernetes）上部署管理 TiDB 集群的能力。它结合云原生社区的容器编排最佳实践与 TiDB 的专业运维知识，集成一键部署、多集群混部、自动运维、故障自愈等能力，极大地降低了用户使用和管理 TiDB 的门槛与成本。

2.2 TiDB 核心特性

TiDB 具备如下众多特性,其中两大核心特性为：水平扩展与高可用

高度兼容 MySQL 大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。对于用户使用的时候，可以透明地从MySQL切换到TiDB 中，只是“新MySQL”的后端是存储“无限的”，不再受制于Local的磁盘容量。在运维使用时也可以将TiDB当做一个从库挂到MySQL主从架构中。
分布式事务 TiDB 100% 支持标准的 ACID 事务。
一站式 HTAP 解决方案 HTAP: Hybrid Transactional/Analytical Processing TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。
云原生 SQL 数据库 TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，配合 TiDB Operator 项目可实现自动化运维，使部署、配置和维护变得十分简单。
水平弹性扩展通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
真正金融级高可用

相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。

水平扩展

无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力(TiDB)和存储能力(TiKV)。

TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。

TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。

PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。

所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。

高可用

高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。

TiDB TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。
PD PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。
TiKV

TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 节点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。

TiDB 存储和计算能力