【TiDB原理与实战详解】1、原理与基础优化~学不会? 不存在的!

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: TiDB 是一款开源的分布式关系型数据库,具备水平扩展、高可用性和强一致性等特点,适用于高并发、低延迟的大规模数据处理场景。其架构设计灵感源自 Google 的 Spanner 和 F1,并兼容 MySQL。TiDB 集群由 TiDB Server(无状态 SQL 层)、PD(元数据管理模块)和 TiKV Server(分布式存储层)组成,还包含 TiFlash(列存储引擎)以加速分析型查询。TiDB 支持分布式事务和多种事务模式,适用于 OLTP 和 HTAP 场景,如电商平台和金融系统。此外,TiDB 的部署要求包括高性能硬件配置和特定网络设置,以确保系统的稳定性和高效运行。

简介

TiDB 是一款开源的分布式关系型数据库,具有水平扩展、高可用性和强一致性等特点,特别适用于需要高并发、低延迟和高可用性的大规模数据处理场景。TiDB 的架构设计灵感来自 Google 的 Spanner 和 F1,并且与 MySQL 兼容。以下是对 TiDB 集群原理的详细介绍。

1. TiDB 集群的整体架构

TiDB 集群主要由三个核心组件构成:

  • TiDB Server: 无状态的 SQL 层,负责接收来自客户端的 SQL 请求,执行 SQL 解析、优化和计划生成,最终将数据读写请求分发给存储层。
  • PD(Placement Driver): 集群的元数据管理模块,负责管理 TiKV 集群的元数据,调度数据的存储和副本分布,保证数据的负载均衡和高可用性。
  • TiKV Server: 分布式的存储层,负责数据的存储和读取,提供分布式事务的支持,确保数据的一致性。

另外,还有 TiFlash 作为列存储引擎,用于加速分析型查询。

2. TiDB Server 详细解析

  • 无状态设计: TiDB Server 是无状态的,所有请求都是通过负载均衡器分发到任意一台 TiDB Server 进行处理。这意味着 TiDB Server 可以轻松扩展,满足高并发的需求。
  • SQL 处理流程:
    1. SQL 解析: 将 SQL 语句解析为抽象语法树(AST)。
    2. 查询优化: 基于元数据和统计信息,TiDB 优化器会选择最优的执行计划。
    3. 执行计划生成: 生成物理执行计划,确定如何访问数据以及如何执行操作。
    4. 请求分发: 将数据访问请求分发到存储层(TiKV 或 TiFlash)。

3. PD(Placement Driver)详细解析

  • 元数据管理: PD 负责存储集群的元数据,包括每个 Region 的位置、副本分布和节点状态等信息。
  • 负载均衡和调度:
    • Region 的分裂与合并: 当某个 Region 的数据量或请求量过大时,PD 会自动将其分裂成多个小的 Region;相反,如果某些 Region 过小,PD 可能会将它们合并。
    • 副本管理: PD 确保每个 Region 在集群中有足够数量的副本,通常是 3 个副本,以确保高可用性和容灾能力。
    • Leader 选举: PD 负责为每个 Region 选择一个 Leader,Leader 负责处理所有的写入请求和大部分的读取请求。
  • 时间同步: PD 使用内建的 TSO(Timestamp Oracle)服务为集群提供全局递增的时间戳,确保分布式事务的一致性。

4. TiKV Server 详细解析

  • 分布式存储设计:
    • Key-Value 存储模型: TiKV 以键值对的形式存储数据,支持范围查询,并且基于 Raft 协议实现分布式一致性。
    • Region: TiKV 中的数据按范围切分成多个 Region,每个 Region 是连续的 Key-Value 对集合,默认大小为 96MB。每个 Region 在物理上被存储在不同的 TiKV 节点上。
  • Raft 协议:
    • 数据一致性: 每个 Region 的副本组通过 Raft 协议进行日志复制,确保数据一致性。Raft 中的 Leader 负责处理客户端请求,将操作日志复制到 Follower,并在多数副本确认后提交日志。
    • 高可用性: 当某个副本故障时,PD 可以自动将其替换,并通过 Raft 协议确保新的副本能够恢复数据。
  • 事务支持:
    • 两阶段提交(2PC): TiKV 采用两阶段提交协议保证分布式事务的原子性和一致性。第一阶段预提交(Prewrite),第二阶段提交(Commit)。
    • 乐观事务和悲观事务: TiKV 提供乐观事务(默认)和悲观事务两种模式,前者适用于冲突较少的场景,后者适用于冲突较多的场景。

5. TiFlash 解析

  • 列存储引擎: TiFlash 是 TiDB 集群的列存储引擎,专为 OLAP(在线分析处理)场景设计。它与 TiKV 保持数据一致性,支持实时分析查询。
  • 异步复制: TiDB 会将 TiKV 中的数据异步复制到 TiFlash 中,使得 TiFlash 能够加速复杂的分析查询,而不影响 TiKV 的事务性能。

6. 数据写入和读取流程

  • 数据写入:
    1. 客户端通过 TiDB Server 发送写入请求。
    2. TiDB Server 解析 SQL 并将数据写入请求分发到对应的 TiKV Leader。
    3. TiKV Leader 通过 Raft 协议将数据复制到 Follower 节点。
    4. 在多数 Follower 节点确认写入后,Leader 将数据提交,并返回给 TiDB Server。
  • 数据读取:
    1. 客户端通过 TiDB Server 发送读取请求。
    2. TiDB Server 解析 SQL,并根据 PD 提供的元数据确定数据所在的 TiKV 或 TiFlash 节点。
    3. TiDB Server 向对应的节点发送读取请求并获取数据。
    4. TiDB Server 将查询结果返回给客户端。

7. 高可用性和故障恢复

  • 多副本存储: 每个 Region 在 TiKV 集群中有多个副本,通常为 3 个副本。即使某个节点故障,数据也可以通过其他副本进行恢复。
  • 自动故障转移: 当 PD 监测到某个 TiKV 节点失效时,会将其上的 Leader 转移到其他正常节点上,保证集群的可用性。
  • Raft Group 选举: Raft 协议确保在 Leader 节点失效后,剩余的 Follower 节点能够自动选举出新的 Leader,继续提供服务。

8. TiDB 的扩展性

  • 水平扩展: TiDB 支持通过增加更多的 TiDB Server 和 TiKV Server 实现水平扩展,能够应对不断增长的业务需求。
  • 负载均衡: PD 通过动态调整 Region 的分布和 Leader 的位置,确保集群负载均衡,避免单点热点问题。

9. TiDB 的强一致性

  • 全局一致性: TiDB 使用 MVCC(多版本并发控制)和 Raft 协议来确保在分布式环境下的强一致性,所有读写操作都遵循线性一致性。
  • 分布式事务: TiDB 的事务模型确保了 ACID(原子性、一致性、隔离性、持久性)属性,即使在跨节点的分布式事务中也能保持数据一致。

10. TiDB 的适用场景

  • OLTP 场景: 由于 TiDB 的高并发支持和分布式事务能力,非常适合在线交易处理系统,如电商平台、金融系统等。
  • HTAP 场景: 结合 TiKV 和 TiFlash,TiDB 能够同时支持 OLTP 和 OLAP 的混合负载,这使其在需要实时数据分析的场景中具有优势。

一、部署要求

1、硬件要求

CentOS 7.3及以上版本

组件 CPU 内存 硬盘类型 网络 实例数
TiDB 16核 32GB SAS 万兆网卡两块 2
PD 4核 8GB SSD 万兆网卡两块 3
TiKV 16核 32GB SSD 万兆网卡两块 3
TiFlash 48核 128GB SSD 万兆网卡两块 2
TiCDC 16核 16GB SSD 万兆网卡两块 2
监控 8核 16GB SAS 千兆网卡两块 1

注释:

  • 生产环境TiDB和PD可以部署和运行在同一服务器上,如对性能要求较高,可分开部署。
  • TiKV硬盘大小建议 SSD 不超过 2TB使用NVME接口以保证读写更快,普通SSD不超过1.5TB。

  • TiFlash 支持多盘部署

  • TiFlash 数据目录的第一块磁盘推荐用高性能 SSD来缓冲 TiKV 同步数据的实时写入,该盘性能应不低于 TiKV 所使用的磁盘,比如 PCI-E SSD。并且该磁盘容量建议不小于总容量的 10%,否则它可能成为这个节点的能承载的数据量的瓶颈。而其他磁盘可以根据需求部署多块普通 SSD,当然更好的 PCI-E SSD 硬盘会带来更好的性能。

  • TiFlash 推荐与 TiKV 部署在不同节点,如果条件所限必须将 TiFlash 与 TiKV 部署在相同节点,则需要适当增加 CPU 核数和内存,且尽量将 TiFlash 与 TiKV 部署在不同的磁盘,以免互相干扰。
  • TiFlash 硬盘总容量大致为:整个 TiKV 集群的需同步数据容量 / TiKV 副本数 * TiFlash 副本数。例如整体 TiKV 的规划容量为 1 TB、TiKV 副本数为 3、TiFlash 副本数为 2,则 TiFlash 的推荐总容量为 1024 GB / 3 * 2。用户可以选择同步部分表数据而非全部,具体容量可以根据需要同步的表的数据量具体分析。

  • TiCDC 硬盘配置建议 1 TB+ PCIE-SSD。

如果公司真的要用 TiDB 最低的要求也应该使用 NVME 的硬盘,否则不建议使用,而且必须部署在相同的交换机上,如果想要性能更好还是要使用万兆网卡,毕竟对于分布式来讲,现在最大的瓶颈就是网络。

2、网络要求

TiDB 各组件和端口说明:

组件 默认端口 说明
TiDB 4000 应用及 DBA 工具访问通信端口
TiDB 10080 TiDB 状态信息上报通信端口
TiKV 20160 TiKV 通信端口
TiKV 20180 TiKV 状态信息上报通信端口
PD 2379 提供 TiDB 和 PD 通信端口
PD 2380 PD 集群节点间通信端口
TiFlash 9000 TiFlash TCP 服务端口
TiFlash 8123 TiFlash HTTP 服务端口
TiFlash 3930 TiFlash RAFT 服务和 Coprocessor 服务端口
TiFlash 20170 TiFlash Proxy 服务端口
TiFlash 20292 Prometheus 拉取 TiFlash Proxy metrics 端口
TiFlash 8234 Prometheus 拉取 TiFlash metrics 端口
Pump 8250 Pump 通信端口
Drainer 8249 Drainer 通信端口
CDC 8300 CDC 通信接口
Prometheus 9090 Prometheus 服务通信端口
Node_exporter 9100 TiDB 集群每个节点的系统信息上报通信端口
Blackbox_exporter 9115 Blackbox_exporter 通信端口,用于 TiDB 集群端口监控
Grafana 3000 Web 监控服务对外服务和客户端(浏览器)访问端口
Alertmanager 9093 告警 web 服务端口
Alertmanager 9094 告警通信端口

二、基础环境优化

1、使用ext4文件系统

2、开启高性能模式

# 查询 //虚拟机无信息
cpupower frequency-info --policy
# 修改为CPU高性能模式
cpupower frequency-set --governor performance

3、挂载优化

  • noatime:读取文件时,将禁用对元数据的更新。
  • nodiratime: 该行为会在读取目录时禁用对元数据的更新。
示例:
# 开机自动挂载
vi /etc/fstab
/dev/mapper/data  /data ext4 defaults,nodelalloc,noatime 0 2

# 挂载数据盘
mount -a
# 挂载生效
mount -t ext4

4、关闭swap分区

echo "vm.swappiness = 0">> /etc/sysctl.conf
swapoff -a && swapon -a
sysctl -p

5、关闭防火墙

systemctl stop firewalld.service
systemctl disable firewalld.service

6、使用时间同步

# 安装ntpdate命令
yum install -y ntpdate
# 设置时间同步
crontal  -e
* */12 * * *  ntpdate ntp.aliyum.com

7、关闭大叶内存

echo never > /sys/kernel/mm/transparent_hugepage/enabled 
echo never > /sys/kernel/mm/transparent_hugepage/defrag

8、调整I/O调度器

echo noop > /sys/block/sd[bc]/queue/scheduler

9、网络及内核参数

echo "fs.file-max = 1000000">> /etc/sysctl.conf
echo "net.core.somaxconn = 32768">> /etc/sysctl.conf
echo "net.ipv4.tcp_tw_recycle = 0">> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 0">> /etc/sysctl.conf
echo "vm.overcommit_memory = 1">> /etc/sysctl.conf
sysctl -p

cat >>/etc/security/limits.conf<<'EOF' 
tidb soft nofile 1000000
tidb hard nofile 1000000
tidb soft stack  32768
tidb hard stack  32768
EOF

10、SSH互信

相关文章
|
存储 SQL Java
数据库TiDB-01.数据库架构概述
TiDB兼容MySQL 5.7协议,支持水平扩容或者缩容的金融级高可用的云原生分布式数据库。
749 2
数据库TiDB-01.数据库架构概述
|
数据库 数据安全/隐私保护
TiDB分布式事务处理机制
【2月更文挑战第28天】TiDB作为开源的分布式HTAP数据库产品,其分布式事务处理机制是其核心功能之一。本章节将深入解析TiDB分布式事务处理机制的工作原理,包括其采用的分布式事务协议、事务的提交与回滚过程、以及如何处理并发事务等关键内容。通过了解TiDB的分布式事务处理机制,我们可以更好地理解其在分布式环境下如何确保数据一致性和事务正确性。
|
SQL 关系型数据库 MySQL
TiDB安装简介
TiDB安装简介
2746 0
|
存储 SQL 运维
TIDB和MySQL的区别
TIDB和MySQL的区别
1900 0
|
存储 SQL 弹性计算
TiDB概述:定义与基本概念
【2月更文挑战第25天】TiDB是一款高性能、分布式的关系型数据库,它采用Go语言开发,兼容MySQL协议和生态,能够为用户提供强大的数据存储和查询能力。本文将详细介绍TiDB的定义、基本概念以及其核心特性,更好地理解这一开源数据库产品。
1383 5
|
SQL 弹性计算 分布式计算
TiDB计算层详解:分布式计算框架与查询优化机制
【2月更文挑战第26天】本文将深入剖析TiDB的计算层,详细解析其分布式计算框架和查询优化机制。通过了解计算层的核心组件和工作原理,我们可以更好地理解TiDB如何高效处理SQL查询和计算任务。本文将从计算层的架构、任务分发、查询优化等方面展开介绍,帮助读者全面掌握TiDB计算层的关键技术和优势。
|
存储 安全 Linux
TiDB安装准备工作与基础环境搭建
【2月更文挑战第28天】TiDB安装前需满足硬件(足够CPU、内存、存储)和软件(Linux,推荐CentOS 7+)要求,确保网络稳定性。配置包括设置唯一主机名,关闭防火墙和SELinux,同步NTP,创建TiDB用户和目录。下载官方安装包并验证后,解压,配置环境变量,初始化集群,启动服务并验证运行状态。稳定的环境对发挥TiDB性能至关重要。
1022 1
|
存储 关系型数据库 MySQL
TiDB中的数据类型详解
【2月更文挑战第29天】TiDB支持多种数据类型:整数(TINYINT到BIGINT)、浮点(FLOAT, DOUBLE)、定点(DECIMAL)、字符串(CHAR, VARCHAR, TEXT)、日期时间(DATE, TIME, DATETIME, TIMESTAMP)、二进制(BINARY, VARBINARY, BLOB)以及枚举和集合(ENUM, SET)。正确选择数据类型对存储、查询和性能至关重要。
1756 1
|
SQL 关系型数据库 MySQL
TiDB亿级数据亚秒响应查询将MySql数据全量迁移到TiDB
TiDB亿级数据亚秒响应查询将MySql数据全量迁移到TiDB
599 0
|
6月前
|
存储 关系型数据库 MySQL
【赵渝强老师】TiDB的体系架构
TiDB是由PingCAP公司自主研发的开源分布式关系型数据库,支持HTAP(混合事务分析处理),具备弹性扩缩容、金融级高可用、实时分析等特性,兼容MySQL协议。其架构分为存储集群(行存TiKV与列存TiFlash)、调度集群(PD实例)和计算集群(TiDB实例)。相比传统单机数据库,TiDB优势显著:纯分布式设计、高扩展性、自动故障恢复、ACID事务支持及丰富的工具生态,适用于高可用与强一致要求的场景。
204 10