tidb 基础

tidb 简介

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

tidb 架构

tidb 组件说明

TiDB Server

SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 TiProxy、LVS、HAProxy、ProxySQL 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

PD

PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

TiKV Server

存储节点，负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。

TiFlash

TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

TiProxy

TiProxy 是 TiDB 的 L7 代理，可以平衡连接并迁移会话。

TiCDC

TiCDC 是一款 TiDB 增量数据同步工具，通过拉取上游 TiKV 的数据变更日志，TiCDC 可以将数据解析为有序的行级变更数据输出到下游。

TiUP

TiUP 是在 TiDB v4.0 中引入的集群运维工具，提供了使用 Golang 编写的集群管理组件 TiUP cluster。通过使用 TiUP cluster 组件，你可以轻松执行日常的数据库运维操作，包括部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群，以及管理 TiDB 集群参数。

TiUP 还支持部署 TiDB、TiFlash、TiCDC 以及监控系统。

tidb 特性

一键水平扩缩容
    得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

金融级高可用
    数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略，满足不同容灾级别的要求。

实时 HTAP
    提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

云原生的分布式数据库
    专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。

兼容 MySQL 协议和 MySQL 生态
    兼容 MySQL 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

tidb 优势

纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容

支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL

默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明

支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账

具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景

tidb 应用场景

金融行业场景
    金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案的资源利用率低，维护成本高。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，确保系统的 RTO <= 30s 及 RPO = 0。

海量数据及高并发的 OLTP 场景
    传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求。TiDB 是一种性价比高的解决方案，采用计算、存储分离的架构，可对计算、存储分别进行扩缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

实时 HTAP 场景
    TiDB 适用于需要实时处理的大规模数据和高并发场景。TiDB 在 4.0 版本中引入列存储引擎 TiFlash，结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

数据汇聚、二次加工处理的场景
    TiDB 适用于将企业分散在各个系统的数据汇聚在同一个系统，并进行二次加工处理生成 T+0 或 T+1 的报表。与 Hadoop 相比，TiDB 要简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。

tidb 服务器配置要求

组件 CPU 内存 硬盘类型 网络 实例数量(最低要求)
TiDB 16 核+ 48 GB+ SSD 万兆网卡（2 块最佳） 2
PD 8 核+ 16 GB+ SSD 万兆网卡（2 块最佳） 3
TiKV 16 核+ 64 GB+ SSD 万兆网卡（2 块最佳） 3
TiFlash 48 核+ 128 GB+ 1 or more SSDs 万兆网卡（2 块最佳） 2
TiCDC 16 核+ 64 GB+ SSD 万兆网卡（2 块最佳） 2
监控 8 核+ 16 GB+ SAS 千兆网卡 1

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 3930 TiFlash RAFT 服务和 Coprocessor 服务端口
TiFlash 20170 TiFlash Proxy 服务端口
TiFlash 20292 Prometheus 拉取 TiFlash Proxy metrics 端口
TiFlash 8234 Prometheus 拉取 TiFlash metrics 端口
CDC 8300 CDC 通信接口
Monitoring 9090 Prometheus 服务通信端口
Monitoring 12020 NgMonitoring 服务通信端口
Node_exporter 9100 TiDB 集群每个节点的系统信息上报通信端口
Blackbox_exporter 9115 Blackbox_exporter 通信端口，用于 TiDB 集群端口监控
Grafana 3000 Web 监控服务对外服务和客户端(浏览器)访问端口
Alertmanager 9093 告警 web 服务端口
Alertmanager 9094 告警通信端口

tidb 磁盘空间要求

组件 磁盘空间要求 健康水位使用率
TiDB
  • 日志盘建议最少预留 30 GB。
  • v6.5.0 及以上版本默认启用了 Fast Online DDL 对添加索引等 DDL 操作进行加速（通过变量 tidb_ddl_enable_fast_reorg 控制）。如果业务中可能存在针对大对象的 DDL 操作，或需要使用 IMPORT INTO SQL 语句导入数据，推荐为 TiDB 准备额外的 SSD 磁盘空间（建议 100 GB+）。配置方式详见设置 TiDB 节点的临时空间。
 低于 90%
PD 数据盘和日志盘建议最少各预留 20 GB 低于 90%
TiKV 数据盘和日志盘建议最少各预留 100 GB 低于 80%
TiFlash 数据盘建议最少预留 100 GB，日志盘建议最少预留 30 GB 低于 80%
TiUP
  • 中控机：部署一个版本的 TiDB 集群占用不超过 1 GB 空间，部署多个版本集群所占用的空间会相应增加
  • 部署服务器（实际运行 TiDB 各组件的机器）：TiFlash 占用约 700 MB 空间，其他组件（PD、TiDB、TiKV 等）各占用约 200 MB 空间。同时，部署过程会占用小于 1 MB 临时空间（/tmp）存放临时文件
 不涉及
Ngmonitoring
  • Conprof：3 x 1 GB x 组件数量（表示每个组件每天占用约 1 GB，总共 3 天） + 20 GB 预留空间
  • Top SQL：30 x 50 MB x 组件数量（每个组件每天占用约 50 MB，总共 30 天）
  • Top SQL 和 Conprof 共享预留空间
 不涉及

参考文档

https://docs.pingcap.com/zh/tidb/stable/overview/

posted @ 2025-05-14 17:44  小吉猫  阅读(58)  评论(0)    收藏  举报