官方文档：https://docs.pingcap.com/zh/tidb/stable/overview

新一代数据技术：
1. ORDBMS：面向对象数据库技术（PostGreSQL）
2. NoSQL：非结构化数据库技术
- 键值存储数据库：Redis
- 列式储存数据库：HBase
- 文档型数据库：MongoDB
- 图形数据库：Neo4J
3. NewSQL：这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持传统数据库支持ACID和SQL等特性。如：TiDB、OceanBase、Spanner

—— 背景介绍

场景引入

假设某公司核心业务库 MySQL 数据量近亿行，且不断增长，同时所有数据要求多副本保存至少5年，除了对历史数据进行统计分析的离线报表业务，还需要用户数据实时查询

问题分析

MySQL 单表在 5000w 以内性能较好，超过后数据库性能、可维护性都会急剧下。这个时候可以做 MySQL 分库分表，使用 Mycat 或者 Sharding-JDBC

分库分表优缺点

  • 将大表拆分成小表，单表数据量控制在 5000w 以内，使 MySQL 性能稳定可控
  • 可水平扩展，通过部署到多台服务器，提升整个集群的QPS、TPS 等数据库服务指标
  • 分表跨实例后，产生分布式事务管理难题，一旦数据库服务器宕机，有事务不一致风险
  • 分表对 SQL 语句有一定限制，对业务方功能需求大打折扣
  • 需要维护的对象呈指数增长（MySQL 实例数、需要执行的 SQL 变更数量）

问题解决

可考虑选用 NewSQL 技术解决，NewSQL 具有以下显著特点

  • 无限水平扩展能力
  • 分布式强一致性，确保数据 100% 安全
  • 完整的分布式事务处理能力与 ACID 特性

—— 简介

  • 定位 OLTP（在线事务处理）OLAP（在线分析处理）的融合型数据库产品
  • 实现一键水平伸缩，强一致性的多副本数据安全，分布式事务
  • 兼容 MySQL 协议和生态，迁移便捷，运维成本低
  • 设计目标：100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成

—— 架构特性

整体架构

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

tidb和mysql的关系 tidb和oceanbase差别比较_mysql

核心特性

  • 高度兼容 MySQL：在运维使用时可以将 TiDB 当做一个从库挂到 MySQL 主从架构中
  • 分布式事务
  • 一站式 HTAP（混合式事务/分析处理） 解决方案
  • 云原生 SQL 数据库
  • 真正金融级高可用：基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性，且在不丢失大多数副本的前提下，可以实现故障的自动恢复（auto-failover），无需人工介入
  • 水平弹性扩展
  • 添加 TiDB Server 节点，提高整体处理能力，提供更高的吞吐
  • 部署 TiKV Server 节点解决数据 Scale 问题
  • PD 会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上
  • 所以，业务早期可部署少量服务实例（推荐至少部署 3 个 TiKV，3 个PD，2 个TiDB）
  • 高可用
  • TiDB 是无状态的，当单个实例失效时，会影响正在这个实例上进行的 Session，从应用的角度看，会出现单次请求失败的情况，重新连接后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例
  • PD 是一个集群，通过 Raft 协议保持数据的一致性，单个实例失效时，如果这个实例不是 Raft 的leader，服务完全不受影响；如果是，则会重新选出新的 leader，自动恢复服务。PD 在选举的过程中无法对外提供服务，这个时间大约是 3s
  • TiKV 是一个集群，通过 Raft 协议保持数据一致性，并通过 PD 做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有 Region。对于 Region 中的 leader 节点，会中断服务，等待重新选举；对于 Region 中的 Follower 节点，不会影响服务。当某个 TiKV 节点失效，并且在一段时间内（默认30min）无法恢复，PD 会将其上的数据迁移到其他的 TiKV 节点上

存储（TiKV）

  • TiKV 把数据保存在 RocksDB（Facebook 开源的单机 KV 存储引擎） 中，具体数据落地由 RocksDB 负责
  • 利用 Raft（一致性协议）做数据复制，每个数据变更会落地为一条 Raft 日志，通过 Raft 日志复制功能，将数据安全可靠地同步到复制组的每一个节点中，以防单机失效
  • TiKV 将整个 Key-Value 空间分成很多段，每一段是一系列连续的 Key，每一段叫做一个 Region（分片 / 分区），Region 中保存的数据不超过一定大小（默认 96MB），将数据划分为 Region 后，TiKV 做重要的两件事
  • 以 Region 为单位，将数据分散在集群中所有的节点上，并且尽量保证每个节点上服务的 Region 数量差不多
  • 以 Region 为单位做 Raft 的复制和成员管理
  • TiKV 的 MVCC（多版本并发控制）实现是通过在 Key 后面添加版本号来实现，对应于一个 Key 的多个版本，版本号较大的会被放在前面，方便用户定位 Key 的位置
  • TiKV 的分布式 ACID 事务采用 Google 在 BigTable 中使用的事务模型：Percolator

计算

  • 表数据与 Key-Value 的映射关系：通过表ID（TableID，集群内唯一），行ID（RowID，在表内唯一，可用主键）生成 Key，Value 则为当前行的字段值
  • 分布式 SQL 计算（计算应该需要尽量靠近存储节点，避免大量的 RPC 调用）
  1. SQL 中的谓词条件（如：name=“Tidb”）应被推到存储及诶单进行计算，只需要返回有效行，避免无意义的网络传输
  2. 聚合函数（如：Count(*)）也可以被推到存储节点，进行预聚合，每个节点只需要返回一个结果即可
  3. 最后 SQL 层将各个节点返回的结果累加求和

调度

  • PD 不断地通过 Store 或者 Leader 的心跳包收集整个集群信息，并且根据这些信息以及调度策略生成调度操作序列
  • 每个 TiKV 节点会定期向 PD 汇报节点的状态信息
  • 每个 Raft Group 的 Leader 会定期向 PD 汇报 Region 的状态信息

—— 安装部署

官网有完整的安装部署文档流程，参考官网地址进行安装部署：https://docs.pingcap.com/zh/tidb/stable/quick-start-with-tidb#Linux

注意：

  • 生产安装部署有明确的硬件限制，一般个人PC几乎无法实现生产环境部署搭建
  • 使用 TiDB（默认端口 4000） 前提需安装 MySQL， TiDB 可以理解为一个 MySQL plus

—— 实践操作

SQL 操作

TiDB 兼容 大部分 MySQL 语法与协议，小部分特性不支持（下面列举主要）

  • 存储过程和喊出
  • 触发器
  • 外键约束
  • 自定义函数

读取历史数据（tidb_snapshot）

当数据被更新、删除时，通过SQL接口将更新前的数据读取出来

  • 这个变量的作用域为当前会话（SESSION）
  • 可以通过标准的 SET 语句修改这个变量的值
  • 当这个变量被设置时，TiDB 会按照设置的时间戳建立 Snapshot（没有开销，只是创建数据结构），随后所有的 SELECT 操作都会从这个 Snapshot 上读取数据

TiSpark

  • 可以解决复杂 OLAP 需求，借助 Spark 平台，同时融合 TiKV 分布式集群的优势，和 TiDB 一起为用户一站式解决 HTAP 的需求
  • 依赖于 TiKV 集群和 PD，需要搭建一个 Spark 集群
  • 深度整合了 Spark Catalyst 引擎，可以对计算进行精确的控制，使 Spark 能高效地读取 TiKV 中的数据。还提供索引支持，帮助实现高速点差
  • 通过将计算下推到 TiKV 中提升了数据查询的效率，减少了 Spark SQL 需要处理的数据量，通过 TiDB 内置的统计信息选择最优的查询计划
  • 提供分布式写入 TiKV 的功能。与使用 Spark 结合 JDBC 写入 TiDB 的方式相比，分布式写入 TiKV 能够实现事务

TiDB Lightning

  • 是一个将全量数据高速导入到 TiDB 集群的工具
  • 主要使用场景
  • 迅速导入大量新数据
  • 恢复所有备份数据
  • 支持导入 Dumpling 输出的数据、CSV 文件