PingCAP
  • PingCAP University
  • 文档
  • 案例
  • 社区
  • 博客
  • 关于
  • 问答
  • 联系我们
PingCAP
  • 文档
  • 案例
  • 社区
  • 博客
  • 关于
  • 问答
  • 联系我们
  • PingCAP University

Contact

  • Wechat qrCode

    微信扫一扫
    微信ID:pingcap2015

English
文档
v3.0 (stable) dev v2.1This doc does not exist in v2.1
  • 关于 TiDB
    • TiDB 简介
    • Benchmark 测试
      • 如何用 Sysbench 测试 TiDB
      • 如何对 TiDB 进行 TPC-C 测试
      • Sysbench 性能对比 - v3.0 对比 v2.1
      • TPC-C 性能对比 - v3.0 对比 v2.1
      • 线上负载与 `Add Index` 相互影响测试
      • TiDB in Kubernetes Sysbench 性能测试
      • DM 1.0-GA 性能测试
  • 主要概念
    • 整体架构
    • 核心特性
      • 水平扩展
      • 高可用
  • 操作指南
    • 快速上手
      • 使用 Docker Compose 部署 TiDB
      • SQL 基本操作
      • 读取历史数据
      • TiDB Binlog 教程
      • TiDB Data Migration 教程
      • TiDB Lightning 教程
      • TiSpark 教程
    • 部署
      • 软硬件环境需求
      • 集群部署方式
        • 使用 Ansible 部署(推荐)
        • 使用 Ansible 离线部署
        • 使用 Docker 部署
      • 跨地域冗余
        • 跨数据中心部署方案
        • 配置集群拓扑
      • 使用 Ansible 部署 DM 集群
    • 配置
      • 时区
      • 内存控制
    • 安全
      • 安全传输层协议 (TLS)
        • 为 MySQL 客户端开启 TLS
        • 为 TiDB 组件间开启 TLS
      • 生成自签名证书
    • 监控
      • 概述
      • 监控 TiDB 集群
    • 迁移
      • 概述
      • 从 MySQL 迁移
        • 全量迁移
        • 增量复制
      • 从 Amazon Aurora MySQL 迁移数据
      • 从 CSV 迁移
    • 运维
      • Ansible 常见运维操作
      • 备份与恢复
        • 使用 Mydumper/Loader 进行备份与恢复
        • 使用 BR 进行备份与恢复
      • 定位慢查询
    • 扩容缩容
      • 使用 Ansible 扩容缩容
    • 升级
      • 升级至最新开发版
    • 故障诊断
      • 集群配置诊断
      • TiDB Lightning 故障诊断
  • 参考手册
    • SQL
      • 与 MySQL 兼容性对比
      • SQL 语言结构
        • 字面值
        • Schema 对象名
        • 关键字和保留字
        • 用户自定义变量
        • 表达式语法
        • 注释语法
      • 数据类型
        • 概述
        • 默认值
        • 数值类型
          • `BIT`
          • `BOOL|BOOLEAN`
          • `TINYINT`
          • `SMALLINT`
          • `MEDIUMINT`
          • `INT|INTEGER`
          • `BIGINT`
          • `DECIMAL`
          • `FLOAT`
          • `DOUBLE`
        • 日期和时间类型
          • `DATE`
          • `DATETIME`
          • `TIMESTAMP`
          • `TIME`
          • `YEAR`
        • 字符串类型
          • `CHAR`
          • `VARCHAR`
          • `TEXT`
          • `LONGTEXT`
          • `BINARY`
          • `VARBINARY`
          • `TINYBLOB`
          • `BLOB`
          • `MEDIUMBLOB`
          • `LONGBLOB`
          • `ENUM`
          • `SET`
        • JSON Type
      • 函数与操作符
        • 函数与操作符概述
        • 表达式求值的类型转换
        • 操作符
        • 控制流程函数
        • 字符串函数
        • 数值函数与操作符
        • 日期和时间函数
        • 位函数和操作符
        • Cast 函数和操作符
        • 加密和压缩函数
        • 信息函数
        • JSON 函数
        • GROUP BY 聚合函数
        • 窗口函数
        • 其它函数
        • 精度数学
        • 下推到 TiKV 的表达式列表
      • SQL 语句
        • `ADD COLUMN`
        • `ADD INDEX`
        • `ADMIN`
        • `ALTER DATABASE`
        • `ALTER TABLE`
        • `ALTER USER`
        • `ANALYZE TABLE`
        • `BEGIN`
        • `COMMIT`
        • `CREATE DATABASE`
        • `CREATE INDEX`
        • `CREATE TABLE LIKE`
        • `CREATE TABLE`
        • `CREATE USER`
        • `CREATE VIEW`
        • `DEALLOCATE`
        • `DELETE`
        • `DESC`
        • `DESCRIBE`
        • `DO`
        • `DROP COLUMN`
        • `DROP DATABASE`
        • `DROP INDEX`
        • `DROP TABLE`
        • `DROP USER`
        • `DROP VIEW`
        • `EXECUTE`
        • `EXPLAIN ANALYZE`
        • `EXPLAIN`
        • `FLUSH PRIVILEGES`
        • `FLUSH STATUS`
        • `FLUSH TABLES`
        • `GRANT <privileges>`
        • `INSERT`
        • `KILL [TIDB]`
        • `LOAD DATA`
        • `MODIFY COLUMN`
        • `PREPARE`
        • `RECOVER TABLE`
        • `RENAME INDEX`
        • `RENAME TABLE`
        • `REPLACE`
        • `REVOKE <privileges>`
        • `ROLLBACK`
        • `SELECT`
        • `SET [NAMES|CHARACTER SET]`
        • `SET PASSWORD`
        • `SET TRANSACTION`
        • `SET [GLOBAL|SESSION] <variable>`
        • `SHOW CHARACTER SET`
        • `SHOW COLLATION`
        • `SHOW [FULL] COLUMNS FROM`
        • `SHOW CREATE TABLE`
        • `SHOW CREATE USER`
        • `SHOW DATABASES`
        • `SHOW ENGINES`
        • `SHOW ERRORS`
        • `SHOW [FULL] FIELDS FROM`
        • `SHOW GRANTS`
        • `SHOW INDEXES [FROM|IN]`
        • `SHOW INDEX [FROM|IN]`
        • `SHOW KEYS [FROM|IN]`
        • `SHOW PRIVILEGES`
        • `SHOW [FULL] PROCESSSLIST`
        • `SHOW SCHEMAS`
        • `SHOW [FULL] TABLES`
        • `SHOW TABLE REGIONS`
        • `SHOW TABLE STATUS`
        • `SHOW [GLOBAL|SESSION] VARIABLES`
        • `SHOW WARNINGS`
        • `SPLIT REGION`
        • `START TRANSACTION`
        • `TRACE`
        • `TRUNCATE`
        • `UPDATE`
        • `USE`
      • 约束
      • 生成列
      • 分区表
      • 字符集
      • SQL 模式
      • 视图
    • 配置
      • tidb-server
        • MySQL 系统变量
        • TiDB 特定系统变量
        • 配置参数
        • 配置文件描述
      • pd-server
        • 配置参数
        • 配置文件描述
      • tikv-server
        • 配置参数
        • 配置文件描述
    • 安全
      • 与 MySQL 的安全特性差异
      • TiDB 数据库权限管理
      • TiDB 用户账户管理
      • 基于角色的访问控制
    • 事务
      • 事务语句
      • 事务模型
      • 隔离级别
      • 悲观事务
    • 系统数据库
      • `mysql`
      • `information_schema`
    • 错误码
    • 支持的连接器和 API
    • 垃圾回收 (GC)
      • GC 机制简介
      • GC 配置
    • 性能调优
      • SQL 优化流程
      • 理解 TiDB 执行计划
      • 执行计划绑定
      • 统计信息概述
      • Optimizer Hints
      • Follower Read
      • 使用 SQL 语句检查 TiDB 集群状态
      • Statement Summary Table
      • TiKV 调优
      • TiDB 最佳实践
    • 监控指标
      • Overview 面板
      • TiDB 面板
      • PD 面板
      • TiKV 面板
    • 报警规则
    • 最佳实践
      • HAProxy 最佳实践
      • Java 应用开发最佳实践
      • 高并发写入场景最佳实践
      • Grafana 监控最佳实践
      • PD 调度策略最佳实践
      • 海量 Region 集群调优最佳实践
      • 乐观锁事务最佳实践
    • TiSpark 使用指南
    • TiDB Binlog
      • 概述
      • 部署使用
      • 运维管理
      • 版本升级
      • 监控告警
      • 增量恢复
      • Kafka 自定义开发
      • 故障诊断
        • 故障诊断
        • 常见错误修复
      • FAQ
    • 周边工具
      • Mydumper
      • Loader
      • Syncer
      • Data Migration
        • 概述
          • DM 架构
          • 同步功能介绍
          • 使用限制
          • DM-worker 简介
          • DM Relay Log
        • 核心特性
          • Table Routing
          • Black & White Lists
          • Binlog Event Filter
          • 同步延迟监控
          • Shard Support
            • 简介
            • 使用限制
            • 手动处理 Sharding DDL Lock
        • 使用场景
          • 简单的从库同步场景
          • 分库分表合并场景
          • 分表合并数据迁移最佳实践
          • DM-worker 在上游 MySQL 主从间切换
        • 部署使用
        • 配置
          • 概述
          • DM-master 配置
          • DM-worker 配置
          • 任务配置
        • DM 集群管理
          • 集群操作
          • 集群升级
        • DM 同步任务管理
          • 管理数据同步任务
          • 任务前置检查
          • 任务状态查询
          • 跳过或替代执行异常的 SQL 语句
        • 监控 DM 集群
        • 从与 MySQL 兼容的数据库迁移数据
          • 从 Amazon Aurora MySQL 迁移数据
        • DM Portal
        • DM 故障诊断
          • 故障诊断
          • 错误含义
          • 常见错误修复
        • DM FAQ
        • 版本发布历史
          • v1.0
            • 1.0.2
        • TiDB DM 术语表
      • TiDB Lightning
        • 概述
        • 部署执行
        • 断点续传
        • 表库过滤
        • CSV 支持
        • 监控告警
        • 故障诊断
        • FAQ
      • sync-diff-inspector
      • PD Control
      • PD Recover
      • TiKV Control
      • TiDB Controller
      • 工具下载
  • TiDB in Kubernetes
    • TiDB Operator 简介
    • 快速上手
      • kind
      • GKE
      • Minikube
    • 部署
      • 集群环境要求
      • 部署 TiDB Operator
      • 标准 Kubernetes 上的 TiDB 集群
      • AWS EKS 上的 TiDB 集群
      • GCP 上的 TiDB 集群
      • 阿里云上的 TiDB 集群
      • 访问 Kubernetes 上的 TiDB 集群
    • 配置
      • 初始化集群
    • 监控
    • 运维
      • 销毁 TiDB 集群
      • 维护 TiDB 集群所在节点
      • 备份与恢复
      • 恢复 Kubernetes 上的 TiDB 集群数据
      • 收集日志
      • 集群故障自动转移
      • TiDB Binlog
    • 扩缩容
    • 升级
      • TiDB 集群
      • TiDB Operator
    • 参考信息
      • 配置
        • 集群配置
        • 备份配置
        • PV 配置
        • TiDB Drainer
      • 工具
        • tkctl
        • 相关工具使用
    • 故障诊断
    • 常见问题
  • 常见问题 (FAQ)
    • TiDB FAQ
    • TiDB Lightning FAQ
    • 升级 FAQ
  • 技术支持
    • 支持渠道
    • 反馈问题
  • 贡献
    • 贡献代码
    • 改进文档
  • TiDB 路线图
  • 版本发布历史
    • v3.0
      • 3.0.7
      • 3.0.6
      • 3.0.5
      • 3.0.4
      • 3.0.3
      • 3.0.2
      • 3.0.1
      • 3.0 GA
      • 3.0.0-rc.3
      • 3.0.0-rc.2
      • 3.0.0-rc.1
      • 3.0.0-beta.1
      • 3.0.0-beta
    • v2.1
      • 2.1.18
      • 2.1.17
      • 2.1.16
      • 2.1.15
      • 2.1.14
      • 2.1.13
      • 2.1.12
      • 2.1.11
      • 2.1.10
      • 2.1.9
      • 2.1.8
      • 2.1.7
      • 2.1.6
      • 2.1.5
      • 2.1.4
      • 2.1.3
      • 2.1.2
      • 2.1.1
      • 2.1 GA
      • 2.1 RC5
      • 2.1 RC4
      • 2.1 RC3
      • 2.1 RC2
      • 2.1 RC1
      • 2.1 Beta
    • v2.0
      • 2.0.11
      • 2.0.10
      • 2.0.9
      • 2.0.8
      • 2.0.7
      • 2.0.6
      • 2.0.5
      • 2.0.4
      • 2.0.3
      • 2.0.2
      • 2.0.1
      • 2.0
      • 2.0 RC5
      • 2.0 RC4
      • 2.0 RC3
      • 2.0 RC1
      • 1.1 Beta
      • 1.1 Alpha
    • v1.0
      • 1.0
      • Pre-GA
      • RC4
      • RC3
      • RC2
      • RC1
  • 术语表

TiDB 高并发写入场景最佳实践

在 TiDB 的使用过程中,一个典型场景是高并发批量写入数据到 TiDB。本文阐述了该场景中的常见问题,旨在给出一个业务的最佳实践,帮助读者避免因使用 TiDB 不当而影响业务开发。

目标读者

本文假设你已对 TiDB 有一定的了解,推荐先阅读 TiDB 原理相关的三篇文章(讲存储,说计算,谈调度),以及 TiDB Best Practice。

高并发批量插入场景

高并发批量插入的场景通常出现在业务系统的批量任务中,例如清算以及结算等业务。此类场景存在以下特点:

  • 数据量大
  • 需要短时间内将历史数据入库
  • 需要短时间内读取大量数据

这就对 TiDB 提出了以下挑战:

  • 写入/读取能力是否可以线性水平扩展
  • 随着数据持续大并发写入,数据库性能是否稳定不衰减

对于分布式数据库来说,除了本身的基础性能外,最重要的就是充分利用所有节点能力,避免让单个节点成为瓶颈。

TiDB 数据分布原理

如果要解决以上挑战,需要从 TiDB 数据切分以及调度的原理开始讲起。这里只作简单说明,详情可参阅谈调度。

TiDB 以 Region 为单位对数据进行切分,每个 Region 有大小限制(默认 96M)。Region 的切分方式是范围切分。每个 Region 会有多副本,每一组副本,称为一个 Raft Group。每个 Raft Group 中由 Leader 负责执行这块数据的读 & 写(TiDB 即将支持 Follower-Read)。Leader 会自动地被 PD 组件均匀调度在不同的物理节点上,用以均分读写压力。

TiDB 数据概览

只要业务的写入没有 AUTO_INCREMENT 的主键,或没有单调递增的索引(即没有业务上的写入热点,更多细节可参阅 TiDB 正确使用方式),从原理上来说,TiDB 依靠这个架构可具备线性扩展的读写能力,并且可以充分利用分布式资源。从这一点看,TiDB 尤其适合高并发批量写入场景的业务。

但理论场景和实际情况往往存在不同。以下实例说明了热点是如何产生的。

热点产生的实例

以下为一张示例表:

CREATE TABLE IF NOT EXISTS TEST_HOTSPOT(
      id         BIGINT PRIMARY KEY,
      age        INT,
      user_name  VARCHAR(32),
      email      VARCHAR(128)
)

这个表的结构非常简单,除了 id 为主键以外,没有额外的二级索引。将数据写入该表的语句如下,id 通过随机数离散生成:

INSERT INTO TEST_HOTSPOT(id, age, user_name, email) values(%v, %v, '%v', '%v');

负载是短时间内密集地执行以上写入语句。

以上操作看似符合理论场景中的 TiDB 最佳实践,业务上没有热点产生。只要有足够的机器,就可以充分利用 TiDB 的分布式能力。要验证是否真的符合最佳实践,可以在实验环境中进行测试。

部署拓扑 2 个 TiDB 节点,3 个 PD 节点,6 个 TiKV 节点。请忽略 QPS,因为测试只是为了阐述原理,并非 benchmark。

QPS1

客户端在短时间内发起了“密集”的写入,TiDB 收到的请求是 3K QPS。理论上,压力应该均摊给 6 个 TiKV 节点。但是从 TiKV 节点的 CPU 使用情况上看,存在明显的写入倾斜(tikv - 3 节点是写入热点):

QPS2

QPS3

Raft store CPU 为 raftstore 线程的 CPU 使用率,通常代表写入的负载。在这个场景下 tikv-3 为 Raft Leader,tikv-0 和 tikv-1 是 Raft 的 Follower,其他的 TiKV 节点的负载几乎为空。

从 PD 的监控中也可以证明热点的产生:

QPS4

热点问题产生的原因

以上测试并未达到理论场景中最佳实践,因为刚创建表的时候,这个表在 TiKV 中只会对应为一个 Region,范围是:

[CommonPrefix + TableID, CommonPrefix + TableID + 1)

短时间内大量数据会持续写入到同一个 Region 上。

TiKV Region 分裂流程

上图简单描述了这个过程,随着数据持续写入,TiKV 会将一个 Region 切分为多个。但因为首先发起选举的是原 Leader 所在的 Store,所以新切分好的两个 Region 的 Leader 很可能还会在原 Store 上。新切分好的 Region 2,3 上,也会重复之前发生在 Region 1 上的过程。也就是压力会密集地集中在 TiKV-Node 1 上。

在持续写入的过程中,PD 发现 Node 1 中产生了热点,会将 Leader 均分到其他的 Node 上。如果 TiKV 的节点数多于副本数的话,TiKV 会尽可能将 Region 迁移到空闲的节点上。这两个操作在数据插入的过程中,也能在 PD 监控中得到印证:

QPS5

在持续写入一段时间后,整个集群会被 PD 自动地调度成一个压力均匀的状态,到那个时候整个集群的能力才会真正被利用起来。在大多数情况下,以上热点产生的过程是没有问题的,这个阶段属于表 Region 的预热阶段。

但是对于高并发批量密集写入场景来说,应该避免这个阶段。

热点问题的规避方法

为了达到场景理论中的最佳性能,可跳过这个预热阶段,直接将 Region 切分为预期的数量,提前调度到集群的各个节点中。

TiDB 在 v3.0.x 以及 v2.1.13 后支持一个叫 Split Region 的新特性。这个特性提供了新的语法:

SPLIT TABLE table_name [INDEX index_name] BETWEEN (lower_value) AND (upper_value) REGIONS region_num
SPLIT TABLE table_name [INDEX index_name] BY (value_list) [, (value_list)]

但是 TiDB 并不会自动提前完成这个切分操作。原因如下:

Table Region Range

从上图可知,根据行数据 key 的编码规则,行 ID (rowID) 是行数据中唯一可变的部分。在 TiDB 中,rowID 是一个 Int64 整形。但是用户不一定能将 Int64 整形范围均匀切分成需要的份数,然后均匀分布在不同的节点上,还需要结合实际情况。

如果行 ID 的写入是完全离散的,那么上述方式是可行的。如果行 ID 或者索引有固定的范围或者前缀(例如,只在 [2000w, 5000w) 的范围内离散插入数据),这种写入依然在业务上不产生热点,但是如果按上面的方式进行切分,那么有可能一开始数据仍只写入到某个 Region 上。

作为一款通用数据库,TiDB 并不对数据的分布作假设,所以开始只用一个 Region 来对应一个表。等到真实数据插入进来以后,TiDB 自动根据数据的分布来作切分。这种方式是较通用的。

所以 TiDB 提供了 Split Region 语法,专门针对短时批量写入场景作优化。基于以上案例,下面尝试用 Split Region 语法提前切散 Region,再观察负载情况。

由于测试的写入数据在正数范围内完全离散,所以用以下语句,在 Int64 空间内提前将表切分为 128 个 Region:

SPLIT TABLE TEST_HOTSPOT BETWEEN (0) AND (9223372036854775807) REGIONS 128;

切分完成以后,可以通过 SHOW TABLE test_hotspot REGIONS; 语句查看打散的情况。如果 SCATTERING 列值全部为 0,代表调度成功。

也可以通过 table-regions.py 脚本,查看 Region 的分布。目前分布已经比较均匀了:

[root@172.16.4.4 scripts]# python table-regions.py --host 172.16.4.3 --port 31453 test test_hotspot
[RECORD - test.test_hotspot] - Leaders Distribution:
  total leader count: 127
  store: 1, num_leaders: 21, percentage: 16.54%
  store: 4, num_leaders: 20, percentage: 15.75%
  store: 6, num_leaders: 21, percentage: 16.54%
  store: 46, num_leaders: 21, percentage: 16.54%
  store: 82, num_leaders: 23, percentage: 18.11%
  store: 62, num_leaders: 21, percentage: 16.54%

再重新运行写入负载:

QPS6

QPS7

QPS8

可以看到已经消除了明显的热点问题了。

本示例仅为一个简单的表,还有索引热点的问题需要考虑。读者可参阅 Split Region 文档来了解如何预先切散索引相关的 Region。

更复杂的热点问题

如果表没有主键或者主键不是 Int 类型,而且用户也不想自己生成一个随机分布的主键 ID 的话,TiDB 内部有一个隐式的 _tidb_rowid 列作为行 ID。在不使用 SHARD_ROW_ID_BITS 的情况下,_tidb_rowid 列的值基本也为单调递增,此时也会有写热点存在(参阅 SHARD_ROW_ID_BITS 的详细说明)。

要避免由 _tidb_rowid 带来的写入热点问题,可以在建表时,使用 SHARD_ROW_ID_BITS 和 PRE_SPLIT_REGIONS 这两个建表选项(参阅 PRE_SPLIT_REGIONS 的详细说明)。

SHARD_ROW_ID_BITS 用于将 _tidb_rowid 列生成的行 ID 随机打散。pre_split_regions 用于在建完表后预先进行 Split region。

注意:

pre_split_regions 必须小于或等于 shard_row_id_bits。

示例:

create table t (a int, b int) shard_row_id_bits = 4 pre_split_regions=·3;
  • SHARD_ROW_ID_BITS = 4 表示 tidb_rowid 的值会随机分布成 16 (16=2^4) 个范围区间。
  • pre_split_regions=3 表示建完表后提前切分出 8 (2^3) 个 Region。

开始写数据进表 t 后,数据会被写入提前切分好的 8 个 Region 中,这样也避免了刚开始建表完后因为只有一个 Region 而存在的写热点问题。

参数配置

TiDB 2.1 版本中在 SQL 层引入了 latch 机制,用于在写入冲突比较频繁的场景中提前发现事务冲突,减少 TiDB 和 TiKV 事务提交时写写冲突导致的重试。通常,跑批场景使用的是存量数据,所以并不存在事务的写入冲突。可以把 TiDB 的 latch 功能关闭,以减少为细小对象分配内存:

[txn-local-latches]
enabled = false
"TiDB 高并发写入场景最佳实践" 更新于 Nov 20 2019: best-practices: fix typos (#2043) (f2b0485)
修改本文 反馈文档问题

本页导航

产品

  • TiDB
  • TiSpark
  • TiDB 路线图

文档

  • 快速入门
  • 最佳实践
  • 常见问题解答
  • TiDB 周边工具
  • 版本发布说明

资源

  • 博客
  • GitHub
  • 知乎专栏
  • PingCAP University
  • 联合解决方案
  • Ask TUG

公司

  • 关于我们
  • 招贤纳士
  • 新闻报道

联系我们

  • Twitter
  • LinkedIn
  • Reddit
  • Google Group
  • Stack Overflow
  • 微信公众号
    Wechat qrCode

    微信扫一扫
    微信ID:pingcap2015

© 2019 北京平凯星辰科技发展有限公司

English