TIDB 详解

TIDB是什么？

TIDB 受谷歌Spanner和F1的论文启发的new sql数据库，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性，同类数据库还包括巨杉数据库。

TiDB的原理与实现

TiDB 架构是 SQL 层和 KV 存储层分离，相当于 innodb 插件存储引擎与 MySQL 的关系。

有了 TiKV，TiDB 层只需要实现 SQL 层，再加上 MySQL 协议的支持，应用程序就能像访问 MySQL 那样去访问 TiDB 了

TiDB的成功案例

目前今日头条，摩拜单车、凤凰网、游族网络等公司采用了TIDB数据库。

这些企业采用TIDB的主要原因包括：

?

1 2 3 4 5 6

1. 兼容mysql 2. 分布式存储，扩展能力强。 3. 支持OLTP 4. 可以直接利用TiSpark做实时分析。 5. 稳定的高可用性 6. 无阻塞在线DDL

采用TIDB的公司需求具有的共同点：

?

1 2	1. 拥有数亿以上记录的数据，希望在保持海量数据存储能力的前提下保留良好的OLTP性能和QPS性能 2. 希望数据库拥有实时计算的能力

TIDB的架构

TiKV Server：负责数据存储，是一个提供事务的分布式 Key-Value 存储引擎；

PD Server：负责管理调度，如数据和 TiKV 位置的路由信息维护、TiKV 数据均衡等；

TiDB Server：负责 SQL 逻辑，通过 PD 寻址到实际数据的 TiKV 位置，进行 SQL 操作。

TiDB的特性

?

1 2	1. 水平扩展：包括计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。 2. 高可用：TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性

TIDB的部署

?

1 2 3

1. 因 TiDB 和 PD 对磁盘 IO 要求不高，所以只需要普通磁盘即可。 2. TiKV 对磁盘 IO 要求较高。TiKV 硬盘大小建议不超过 500G，以防止硬盘损害时，数据恢复耗时过长。整个 TiDB 架构是面向未来、面向海量数据高并发场景，底层存储技术（如数据定位 seek）都是针对当前主流的 SSD 进行设计和优化的，不会对传统的 SATA/SAS 机械硬盘再进行优化。(参考凤凰网的部署方案) 3. 部署工具使用了 TiDB-Ansible。TiDB-Ansible 是 PingCap 基于 Ansible playbook 功能编写了一个集群部署工具叫 TiDB-Ansible。使用该工具可以快速部署一个完整的 TiDB 集群（包括 PD、TiDB、TiKV 和集群监控模块)

TIDB的监控方案

Pincap 团队给 TiDB 提供了一整套监控的方案，他们使用开源时序数据库 Prometheus 作为监控和性能指标信息存储方案，使用 Grafana 作为可视化组件进行展示。（参考今日头条的方案）

监控的原理：

?

1 2 3

1. 在 client 端程序中定制需要的 Metric 2. Push GateWay 来接收 Client Push 上来的数据，统一供 Prometheus 主服务器抓取。 3. AlertManager 用来实现报警机制，使用 Grafana 来进行展示

 

 

关于索引

除了使用主键查询外，TiDB 允许用户创建二级索引以加速访问，就像上面提到过的，在 TiKV 的层面，TiDB 这边的表里面的行数据和索引的数据看起来都是 TiKV 中的 KV Pair，所以很多适用于表数据的原则也适用于索引。和 Spanner 有点不一样的是，TiDB 只支持全局索引，也就是 Spanner 中默认的 Non-interleaved indexes。全局索引的好处是对使用者没有限制，可以 scale 到任意大小，不过这意味着，索引信息不一定和实际的数据在一个 Region 内。

• 建议：
  对于大海捞针式的查询来说 (海量数据中精准定位某条或者某几条)，务必通过索引。

当然也不要盲目的创建索引，创建太多索引会影响写入的性能。

 

 

TiDB 具备如下核心特点：
1 高度兼容 MySQL
　大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。
2水平弹性扩展
　通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
3分布式事务
　TiDB 100% 支持标准的 ACID 事务。
4 真正金融级高可用
　相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
5 一站式 HTAP 解决方案
　TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP解决方案，一份存储同时处理OLTP & OLAP(OLAP、OLTP的介绍和比较 )无需传统繁琐的 ETL 过程。
6云原生 SQL 数据库
　TiDB 是为云而设计的数据库，同 Kubernetes （十分钟带你理解Kubernetes核心概念 ）深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。
　TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。 TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力.

二 TiDb 整体架构

TiDB 集群主要分为三个组件：
１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 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。
３TiKV Server
　TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range （从 StartKey 到EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 RaftGroup，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也是以 Region 为单位进行调度。
三 核心特性
1 水平扩展
　无限水平扩展是 TiDB 的一大特点，这里说的水平扩展包括两方面：计算能力和存储能力。TiDB Server 负责处理 SQL 请求，随着业务的增长，可以简单的添加 TiDB Server 节点，提高整体的处理能力，提供更高的吞吐。TiKV 负责存储数据，随着数据量的增长，可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。所以在业务的早期，可以只部署少量的服务实例（推荐至少部署 3 个 TiKV， 3 个 PD，2 个 TiDB），随着业务量的增长，按照需求添加 TiKV 或者 TiDB 实例。
2 高可用
　高可用是 TiDB 的另一大特点，TiDB/TiKV/PD 这三个组件都能容忍部分实例失效，不影响整个集群的可用性。下面分别说明这三个组件的可用性、单个实例失效后的后果以及如何恢复。
TiDB
　TiDB 是无状态的，推荐至少部署两个实例，前端通过负载均衡组件对外提供服务。当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。
PD
　PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的 leader，那么服务完全不受影响；如果这个实例是 Raft 的 leader，会重新选出新的 Raft leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个 PD 实例，单个实例失效后，重启这个实例或者添加新的实例。
TiKV
　TiKV 是一个集群，通过 Raft 协议（raft一致性哈算法以及Raft 为什么是更易理解的分布式一致性算法 ）保持数据的一致性（副本数量可配置，默认保存三副本），并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 结点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认 30 分钟）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上。
四 TiDb技术内幕
　1 保存数据 TiDB 技术内幕 - 说存储
　2 计算（很关键如何做sql运算） TiDB 技术内幕 - 说计算
　3 调度(Tidb集群管理) TiDB 技术内幕 - 谈调度