PingCAP TiDB全新一栈式实时HTAP数据库_TiDB在线分析处理融合型数据库-云巴巴

PingCAP TiDB全新一栈式实时HTAP数据库

PingCAP TiDB全新一栈式实时HTAP数据库，打破数据壁垒，合而为一。事务性与分析型处理完全基于一体化的数据基座。在线数据分析与决策，分秒必争。强一致性保障基于数据的决策，分毫不差。一站式数据服务基座；高弹性、按需扩缩容；在线 DDL；无需分片、无业务侵入；金融级高可用。

立即咨询

首页 > 产品中心 > 分布式数据库 > PingCAP TiDB全新一栈式实时HTAP数据库

TiDB 简介

83% 代码自主率

TiDB 参加了行业主管部门组织的代码自主率扫描，结果为：代码克隆率 17.07%

81% 研发人员占比

PingCAP是一家分布式数据库产品研发公司，注重产品的研发，研发人员在公司中的人员占比达到 80%+

开源自主

我司产品在行业主管部门组织的产品能力测评中，功能、性能效率、可靠性、信息安全性、易用性、维护性、可移植性、兼容性、可扩展性等 9 个方面的 60 个指标项全部通过

高度兼容 MySQL 5.7 icon

TiDB 高度兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。MySQL 5.7 生态中的系统工具 (PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader)、客户端等均适用于 TiDB。

TiDB 价值

融合的数据平台
打破数据壁垒，合而为一。事务性与分析型处理完全基于一体化的数据基座。

实时的商业分析
在线数据分析与决策，分秒必争。强一致性保障基于数据的决策，分毫不差。

敏捷的业务创新
一站式数据服务基座；高弹性、按需扩缩容；在线 DDL；无需分片、无业务侵入；金融级高可用；

开放的生态系统
基于 CNCF 项目的中国领先开源社区。无缝支持多云架构、对接丰富的MySQL 生态。

一种经典体验，多种部署形态 icon

TiDB 核心组件

Raft 分布式一致性算法 icon

基本概念：Raft 是一个多数派协议，不会出现脑裂的问题。正常运行的情况下，会有一个 leader，其他全为 follower。Follower 只会响应 Leader 的请求。客户端的请求则全部由 leader 处理。即使有客户端请求了一个 follower 也会将请求重定向到 leader。

全局动态有序的 KV Map icon

Region

类 Range 分区：按照 Key 分 Range，某一段连续的 Key 都保存在一个存储节点上。段内连续：将整个 Key-Value 空间分成很多段，每一段是一系列连续的 Key，将每一段叫做一个 Region。96M 大小：会尽量保持每个 Region 中保存的数据不超过一定的大小，目前在 TiKV 中默认是 96MB。StartKey & EndKey：每一个 Region 都可以用 [StartKey，EndKey) 这样一个左闭右开区间来描述。最小单位：以 Region 为单位将数据分散在集群中所有的节点上，以 Region 为单位做 Raft 的复制和成员管理。

TiKV

• TiKV 是一个支持高并发的 TP 存储引擎

• 数据会转换为 Key-Value 对，顺序存放在 TiKV 中，然后以Region 为单位切分进行管理

• TiKV 是一个集群，通过 Raft 协议保持数据的一致性（副本数量可配置，默认保存三副本）

• 每个 region（数据分片）构成独立的 Raft 组

• 推荐至少部署三个 TiKV 实例

• 单个实例失效时

○ 会影响这个节点上存储的所有 Region

○ Region 组中的 Leader 节点，会中断服务，等待重新选举

○ Region Leader 切换非常快（秒级），且应用基本无感知

○ Region 组中的 Follower 节点，不会影响服务

• 单个实例失效后，会尝试在其它 TiKV 实例恢复三副本；不足三个 TiKV 实例时重启这个实例或添加新的实例

TiFlash

• TiFlash 是一个拥有 MPP 能力的 AP 存储引擎

• 数据实时同步自 TiKV，同时拥有隔离性和一致性

• TiFlash 是一个集群，通过Raft 协议保持数据的一致性

• Learner 副本数手动指定（默认为 0，建议设置为 2），并通过 PD 做负载均衡调度

• 推荐至少部署两个 TiFlash 实例

• 单个实例失效时

○ 会影响这个节点上存储的所有 Region ○ 导致当前正在执行的查询失败

○ 重新发起查询会去查询另一个可用的 Learner 副本

• 单个实例失效后，会尝试在其它 TiFlash 实例恢复两副本；不足两个 TiFlash 实例时重启这个实例或添加新的实例

TiKV & TiFlash icon

隔离性：列存副本以特殊角色 (Raft Learner) 进行异步的数据复制。这表示当节点宕机或者网络高延迟等状况发生时，交易的业务仍然能确保正常进行。一致性：每次收到读取请求，列存副本会向交易副本发起进度校对，只有当进度确保至少所包含读取请求时间戳所覆盖的数据之后才响应读取。

TiDB

• TiDB 负责处理 SQL 请求，自动转换成对 Key-Value 的操作

• 兼容 MySQL 协议，支付各种复杂查询

• 基于 CBO 生成执行计划 • TiDB 为无状态节点，易于扩展和收缩

• 推荐至少部署两个实例

• 前端通过负载均衡组件对外提供服务

• 单个实例失效时

○ 会影响正在这个实例上进行的 Session

○ 从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务

• 单个实例失效后，可以重启这个实例或者部署一个新的实例。

• PD 是整个集群的大脑，主要负责元数据的记录和事务号的生成

• 集群各组件会定期向其汇报，之后 PD 会根据会报的信息对集群进行调度

• PD 是一个集群，通过 Raft 协议保持数据的一致

• 推荐至少部署三个 PD 实例

• 单个实例失效时

○ 如果这个实例不是 Raft 的 leader，那么服务完全不受影响

○ 如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。

○ PD leader 切换，预期 3s 内。

• 单个实例失效后，重启这个实例或者添加新的实例。

元数据管理

每个 Raft Group 的 Leader 会定期向 PD 汇报 Region 的状态信息 Leader 的位置

Followers 的位置

掉线副本的个数

数据写入/读取的速度

每个 TiKV 节点会定期向 PD 汇报节点的状态信息

总磁盘容量

可用磁盘容量

承载的 Region 数量

数据写入/读取速度

发送/接受的 Snapshot 数量（副本之间可能会通过 Snapshot 同步数据）

是否过载 labels 标签信息

集群自动调度

实现第一类需求后，整个系统将具备强大的容灾功能。实现第二类需求后，可以使得系统整体的资源利用率更高且合理，具备良好的扩展性。

第一类：作为一个分布式高可用

存储系统，必须满足的需求

副本数量不能多也不能少，副本需要根据拓扑结构分布在不同属性的机器上，节点宕机或异常能够自动合理快速地进行容灾。

第二类：作为一个良好的分布式系统，

需要考虑的地方包括

维持整个集群的 Leader 分布均匀，维持每个节点的储存容量均匀，维持访问热点分布均匀，控制负载均衡的速度，避免影响在线服务，管理节点状态，包括手动上线/下线节点。

标准集群拓扑

TiDB 特性

一键水平扩容或者缩容

可按需进行在线扩容或者缩容，过程透明。降低投产成本。

统一数据平台，实时 HTAP

一套技术栈解决所有。行列引擎，同时获得时效性、一致性、隔离性。

MySQL 兼容

高度兼容 MySQL 生态。少量修改即可迁移到 TiDB。

金融级高可用，故障自动处理

采用计算与存储分离的多副本存储，保证系统持续高可用。

云原生，云托管

为用户提供云上托管的分布式数据库服务。

应用透明性

应用无需考虑和设置分区表及数据分片规则，支持数据自动调度分布

数据强一致

数据副本之间实现实时强一致性。同时支持严格的跨节点分布式事务

在线表结构变更能力

支持不影响生产业务的在线添加索引、增加字段

自动负载均衡

根据业务访问负载自动进行数据在不同存储节点之间均衡

滚动升级和变更能力

版本发生变更时，支持滚动更新

TP 场景

大数据高并发

TiDB 中单笔 SQL 延迟远高于单机数据库，但吞吐很大，可以在保持这个比较高的延迟的前提下，扩展到能承载很高的并发。而单机数据库在并发增加到一定程度之延迟会剧增，引起崩盘。

敏态高可用

传统的 MySQL、Oracle 等单机数据库在容量和性能层面遇到瓶颈，有些企业开始尝试 MySQL 分库分表方案，但是在业务扩展性、敏捷性、可维护性等方面遭遇了诸多挑战，常常导致运维和应用开发人员加班熬夜依然无法跟上业务的迭代速度。

用户中心

场景描述：用户中心是一个非常通用的业务，几乎是所有互联网公司必备的系统。主要提供用户注册、登录、信息查询与修改、用户关系、权限等的服务，随着数据量不断增加，吞吐量不断增大。

技术特点：延迟低，高并发，SLA 要求高，用户中心基本上是 2C 平台最前端模块，是很多业务频繁调用的模块，一般是核心业务，但这个业务理论数据有上限，TiDB 一般适合中大平台。

商品、内容与物料

涵盖元信息存储

场景描述：很多互联网本质是实现物、服务与人的互联，这里的物与服务，在不同的平台可以具体为商品、内容、物料、资讯、服务等，他们都属于基础信息，这类信息在平台属于业务前端模块，在业务流的角度看非常核心，下游很多业务模块都会对这个模块进行调用。技术特点：典型的读多写少，读并发吞吐量很大，延迟要求低，SQL 一般比较简单，点查居多，因为会被多个模块频繁调用，所以商这个服务的模块 SLA、稳定性要求非常高，属于比较核心的业务。

订单与支付类

场景描述：订单是用户乘于商品的关系，所以数据量比用户中心要大，对延迟要求低，事务是强需。订单场景本质是高写入高读的场景，订单数据一般是很多业务模块的基础，很多中下游模块都需要对订单进行访问，比如支付、促销、配送、物流、运营、画像、结算、风控等等，但在主流的架构模型下，这些读流量会通过各种订单副本进行承担，这些副本包括本身的 replica（Slave）、更多包括异步同步等其他存储引擎的模式，所以这个主流架构会造成大量的“副本成本”，“副本成本”会扩展为技术栈成本、时间成本、业务复杂度成本。所以从宏观讲，TiDB 对企业在订单场景下普遍的副本成本是有帮助的。

技术特点：这个场景对数据库的稳定性、一致性、高可用要求都很高，也是 MySQL sharding 最常见的场景。

明细、历史数据等综合查询类 icon

场景描述：在互联网+的平台或者 APP 上，都会有一个“我的”入口，在里面可以看到我的订单、我的支付流水、我的关注、我的消息、我看过的视频、读过文章、我的对战记录、我发过的朋友圈、我的足迹等等，这个场景非常普遍，业务等级一般是 P2。

技术特点：因为涉及到历史数据，这个场景数据量比较大，读的并发量也比较大，从查询交互看，一般都是二级索引的小范围查询、SQL 相对简单。涵盖内容、直播、视频、社交互动类，比如一键三连（点赞、投币、收藏），直播打赏、互动等。

IM 与通信互动类

场景描述：IM 已经成为当下 App 的必备模块（70% ），一般分为用户消息（单聊、私信、群聊、弹幕等）、系统消息（广播、推送、提醒等）、用户关系等。这个场景特点追求高实时性。

技术特点：高写入、低延迟，短信息存储量比较大，数据有一定实效性，对事务不是强需。在电商、社交行业是比较重要的业务。

涵盖场景：IM 技术上讲、是一门高实时性与复用长链接的技术架构与方案。这个技术架构可以辐射扩展其他高实时性的场景，比如：视频会议、弹幕、抽奖、互动游戏、协同办公、股票基金实时报价、体育实况更新、在线课堂等。

适用场景

高可用，高并发，大数据量，强一致事务要求的 OLTP 业务，

如：toC 场景、银行 OLTP（联机+跑批），包括用户、商品、订单、支付、物流、贷款，渠道，互金，计息等。

对灵活扩缩容有较强需求的场景，

如：游戏行业新游戏的上线到下线；微服务，促销等场景。

vs 分库分表

AP 场景

数据综合查询

各种数据同步到 TiDB 集群获得全图的视野。一站式提供明细和汇总查询能力。传统 MPP 或从库无法提供近实时的数据混合查询能力。

数据加工处理

在线准实时数据的加工、存储和分析。流批一体的数据处理平台。传统数仓 T+1 的时效性无法支撑面向消费者业务的实时数据消费。

数据汇总层（明细/汇总报表） icon

优点

数据链路清晰，上游数据变化原封不动直接汇总至 TiDB。整体架构简化，为轻量级可扩展的支持高并发写入的查询层。复杂多维查询支持，同时提供明细报表和汇总报表能力。生态友好，与数据同步工具、大数据技术栈、报表工具等可无缝对接。实时报表，相较于传统技术栈，有着跨代的优势。结合重构业务逻辑 100 倍提升很正常。

数据汇总层（跑批/待加工 icon

优点

数据链路清晰，各上游数据汇总到大数据中台。简化技术栈，轻量级可扩展的支持高并发写入的的数据中台。复杂查询支持，支持多维计算能力。生态友好，与数据同步工具、大数据技术栈、报表工具等可无缝对接。相较于传统技术栈，有着跨代的优势。可大幅提升处理效率。

数据集市层

优点

报表出具效率次高的做法，相较于 Spark，会有 3~5 倍提升。相对于纯流式计算，可以对历史数据进行更新和分析。数据实时更新能力极强、同时提供高频明细查询能力、较为强大的分析查询能力。

优势场景

近实时分析，将数据同步到 TiDB 从集群进行近实时分析。

中台数据汇聚加工，有并发数据多源同步或写入，并发更新和计算的场景。如近实时风控，近实时营销。

传统数据中台架构的短板 icon

单机数据库

Oracle、MySQL等，不具备横向扩展能力

MPP 数据库

GreenPlum、ClickHouse，实时写入能力较弱

Hadoop 平台

不支持事务、标准 SQL 以及复杂的 Ad-hoc 查询

HTAP 场景

HTAP

优势

简化技术栈，一套数据库同时提供 TP 和 AP 能力。最保守情况下手也能给交易系统提供了一个“大数据”接口。一站式解决方案，对中小客户最具吸引力的特性。

中通快递

TiDB Solution

一套 TiDB 同时服务包裹追踪管理与实时报表系统，使已有系统数据存储周期增加至 3 倍以上：在线弹性扩展：支持分布式架构的 TiDB 满足高峰期的高并发读写、更新，同时支持在线扩缩容，单点故障对业务无影响；分钟级实时分析：与中通现有大数据技术生态紧密结合，通过 TiFlash+TiCDC 实现分钟级的实时统计分析、轻度汇总与多维汇总；多维度实时查询：打通各业务产生的数据，汇总到TiDB 建设 100+ 列大宽表，实现多维度实时查询分析。

小红书

TiDB Solution

电商业务需要面临大量促销、优惠券发放情况，对反欺诈数据分析要求较高，通过 TiDB HTAP 构建实时数据中台，满足以下特性：实时写入：T+1 改为实时写入，实时汇聚业务线数据，打破数据孤岛，速率峰值 QPS 达 3-4万，单表一天写入 5亿数据；实时汇总数据中台：通过 TiDB HTAP 提供实时查询，分钟级查看促销优惠券使用与分发情况，提供高效、稳健的实时数据服务；冷数据预处理： Amazon S3 和 EMR 离线数仓冷数据，通过TiDB 实现数据预处理和预聚合；

浦发银行

TiDB Solution

各个商业银行通过第三方合作，利用线上技术，按照约定的资金比例，基于双方共同认可的规则审批，为符合特定准入标准的客户群，提供个人信用贷款，用于其生产经营周转。浦发银行使用 TiDB 承载了跑批业务：跑批时间变短：快速完成了利息核算和报表生成，满足了监管要求，批处理时间压缩至两至三个小时；支持在线弹性扩缩容：为新网贷业务的快速开展提供了可靠的技术保障，日均处理借据数亿笔；开发简化，应用透明：与原应用层框架和应用做无缝透明对接，提升开发效率，两个月完成项目建设投产。

TiDB 产品定位