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

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 Redis 版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介: 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互信

相关文章
|
4月前
|
SQL JSON 关系型数据库
selenuim实战优化
该文介绍了如何使用Selenium将数据直接存入MySQL数据库,以苏宁易购网站为例。首先,优化了JSON数据写入,通过pymysql连接数据库,创建`books`表并读取JSON文件插入数据。接着,整合代码实现直接从网页抓取价格和标题,使用Selenium自动化滚动加载页面,定位元素,清洗数据并使用参数化查询插入到`books`表。主程序循环遍历多页数据,最后关闭数据库连接。
29 1
|
4月前
|
存储 监控 NoSQL
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群指令分析—上篇)(一)
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群指令分析—上篇)
44 0
|
4月前
|
存储 NoSQL 算法
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群指令分析—上篇)(二)
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群指令分析—上篇)
53 0
|
4月前
|
存储 NoSQL 前端开发
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群指令分析—实战篇)
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群指令分析—实战篇)
37 0
|
4月前
|
NoSQL Shell 网络安全
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群功能分析)(二)
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群功能分析)
48 0
|
4月前
|
存储 缓存 NoSQL
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群功能分析)(一)
【Redis深度专题】「核心技术提升」探究Redis服务启动的过程机制的技术原理和流程分析的指南(集群功能分析)
412 0
|
存储 SQL 分布式计算
大数据存储组件TiDB原理+实战篇2
大数据存储组件TiDB原理+实战篇
|
存储 SQL NoSQL
大数据存储组件TiDB原理+实战篇1
大数据存储组件TiDB原理+实战篇
|
SQL 存储 缓存
开源分布式数据库PolarDB-X源码解读——PolarDB-X源码解读(十二):谈谈in常量查询的设计与优化
开源分布式数据库PolarDB-X源码解读——PolarDB-X源码解读(十二):谈谈in常量查询的设计与优化
229 0
|
存储 缓存 NoSQL
【Redis技术干货】推荐给大家的实战技术开发指南(提炼优化)
【Redis技术干货】推荐给大家的实战技术开发指南(提炼优化)
134 0
【Redis技术干货】推荐给大家的实战技术开发指南(提炼优化)