乐趣区

关于数据库:理想汽车-HTAP-读流量优化指南

jiezi

“没有任何一种数据库是银弹，业务场景的适配和降本增效永远是最重要的。”数据库的性能优化可能帮忙企业最大限度地利用系统资源，进步业务撑持能力和用户体验。本文为 TiDB 性能调优专题的第一篇，在这个专题中，咱们将邀请更多 TiDBer 从理论的业务场景登程，分享 TiDB 优化的最佳实际。

作者介绍

郑赫扬（艺名：潜龙），现实汽车 DBA。负责公司分布式数据库的技术摸索和业务场景落地，酷爱开源。就任于金融、互联网教育、电商、新能源汽车等畛域。

现实汽车作为奢华智能电动车品牌，以“发明挪动的家，发明幸福的家”为使命。随着电动汽车业务的一直倒退，公司业务既有 OLTP 也有 OLAP 的需要，因而须要一款 HTAP 数据库帮忙公司实现实时业务决策。在 TUG 企业行 —— 走进 58 同城流动中，来自现实汽车的郑赫扬老师为大家介绍了现实汽车 HTAP 读流量在物理环境、业务环境、SQL 优化、热点问题、流量环境、版本及架构等方面的优化计划。

以下为演讲实录。

现实汽车抉择 TiDB 的理由

1）一栈式 HTAP：简化企业技术栈

TiDB 能够在一份数据源上同时撑持现实汽车 OLTP 和 OLAP 需要，岂但能很好地反对实时数据落地存储，也能提供一体化的剖析能力。另外，TiDB 也能够集成常见的大数据计算技术框架，比方 Spark、Flink 等等，能够应用其构建离线或者实时的数据仓库体系。

2）解决 MySQL 传统拆库拆表问题

随着数据量的激增，单机数据库存不下怎么办？传统关系型数据库再扩展性问题，如果业务上曾经用了 MySQL，那只能去做分库分表，或者利用中间件去转化，业务层要把代码改个遍。而 TiDB 与 MySQL 齐全兼容，MySQL 利用无需批改便可间接运行。反对包含传统 RDBMS 和 NoSQL 的个性，能够随着数据增长而无缝程度扩大，只须要通过减少更多的机器来满足业务增长需要。

3）简洁但不简略的扩缩容

在经验产品更新的演进中，TiDB 4.0 和 5.0 版本基本上能够通过一些操作控制来灵便便捷地扩缩容，例如通过减少节点来线性扩大计算能力，存储节点同样能够依据存储需要一直进行扩容减少存储。在进行节点缩容时，对线上服务的影响也简直无感知。

4）欠缺的生态工具

目前现实汽车正在应用 DM（TiDB Data Migration）、TiCDC、TiSpark 等工具，在实际操作中也很强烈的感触到 TiDB 生态工具十分全面，这些生态工具还在不停地演进倒退中，咱们也在和官网小伙伴一起摸索。

5）丰盛的场景反对

TiDB 在现实汽车的业务场景包含 OLAP 和 OLTP 两个维度。OLAP 包含离线数仓，实时数仓、DMP 平台（包含日常的决策调度、财务调度、报表等）；OLTP 类的商业前端、算法训练（包含线上派单、交付、信息上报）等等。

6）良好的社区环境

社区始终是造就 TiDB 一直倒退的优渥土壤，在日常保护中一旦呈现故障和难点，官网的技术人员就会马上解决，这也给现实汽车很大的信念把 TiDB 引入更多业务场景中应用。
接下来跟大家介绍现实汽车针对读流量在以下 7 个方面的优化实际。

HTAP 读流量如何优化？

1）物理环境优化

现实汽车目前把 TiDB 和 PD 集群的配置从原来的 16 核 32G 升级成了 32 核 128G。对于 TiDB 来说，反对 AP 类的大 SQL 可能要跑 7 – 8G 左右的内存，对内存的需要更高。为了解决 PD 的算力问题，咱们会预估一下数仓的数据级，预估之后咱们会再调大，例如一个单点的话，一个 PD 在 50 万以上可能有调度问题。所以咱们能够调大 Region，来横向防止 Region 数量过多的状况。

TiKV 刚开始应用的是 32C32G 2T 的百度云 SSD，当初和 TiFlash 一样全副采纳 32 核 64G 的 4T NVMe 物理盘，这两个降级都是为了更好地兼顾计算资源。

2）业务环境优化

目前在现实汽车次要的 TiDB 集群都由 DM 同步上游的 MySQL，针对 DM 集群治理做了大量优化。做完之后，就是当初所有的上游 MySQL 次要库在 TiDB 外面都会有正本，因而 TiDB 就具备了 MySQL 从库 + 业务主库 + DMP 平台后果库的性能。

要害业务库表 DDL 变更和业务变更

  • 上游 MySQL DDL 变更是否容许都会做一个标准，避免同步工作中断。
  • 新业务残缺的测试环境反对。

  • 上游 MySQL 刷业务数据会有大量写流量，DM-sync 线程扩容。刷数据之前大家须要提前自动化，调整到顶峰以应答流量冲击，因为上游有很多重要的业务，数据提早的话会很有影响。

    分类开发标准:

  • OLTP 开发标准：
    目前现实汽车的单个事务 SQL 后果集大小不能超过 20MB 后果集 50W 以下，或者 TiDB 计算节点内存小于 120MB，因为 TiDB 要对后果集做一个解决，可能最大扩充至 6 倍。
  • OLAP 开发标准：
  1. 简单 SQL 大表走 TiFlash（个别 2KW），小表走 TiKV。
  2. 后果集最大值小于 7KW 或者 TiDB 计算结果内存小于 8G。
  3. 一直摸索 TiDB 的 OLAP 性能边界。

DM 优化：

DDL 的问题是不反对变更，如果上游读流量业务受到影响，例如公司上游挂了很多个 MySQL，你心愿做 MySQL 同步关联，你只有同步在一个 TiDB 集群外面，你也能够做一个小的数仓，调整办法，首先调整 TiDB 反对 DDL 变更。
解决办法:
(1)调整 TiDB 反对 DDL 变更
(2) 上游新建表 –> 插入业务数据 –> rename 表名 –> 跳过报错（针对上游流量和数据量小，要做数据修补）
(3)上游新建表 –> 插入业务数据 –> rename 表名 –> 跳过报错（上游不会失落数据）

业务环境优化中，典型的 TP 类型的 SQL 对后果集和算子要求就是 20MB，比方须要思考环境规划，咱们要求后果集在多少，总共不能少过多少万行或者多少的内存，下图所示最大内存是 25.3MB。

再来看下 AP 类型的 SQL 实时数仓，最大内存是 8G，总共少了 7700 万的数据，执行工夫是 381 秒，是用 TiFlash 跑的。因为有的报表类或者是定时工作实时性不高，所以分类的话，还是 OK 的。咱们当初好多相似的 SQL 在这么跑，TiFlash 5.0.2 集群版本，对于咱们来说还能够，业务上比较稳定。

3）SQL 优化

首先得定一下规定

SQL 索引：

  • OLTP 类：决定查问速度，所有 SQL 必须走索引

     a. 留神不走索引的状况（where 条件中左侧等式函数，隐式转化，不等式)
  b. 优化形式 MySQL 索引基本一致

  • OLAP 类：依据表的数量级和 SQL 复杂度

      a. 行存 where 条件查一条数据，行存 + 索引更快。b. 列存没有细粒度索引，扫描数据性能更好。

DDL 大表（数量过 10 亿）索引上线可能会影响线上业务:

  1. 参数调整：业务顶峰调小调低优先级
    tidb_ddl_reorg_batch_size = 128

tidb_ddl_reorg_worker_cnt = 2

tidb_ddl_reorg_priority = PRIORITY_LOW

  1. 业务低峰调大调高优先级（看监控察看业务）
    tidb_ddl_reorg_batch_size = 1024

tidb_ddl_reorg_worker_cnt = 16

tidb_ddl_reorg_priority = PRIORITY_HIGH

SQL 执行打算：

读表算子 TiDB 和 MySQL 不一样。MySQL 的话是 Type、Reader 之类的，然而 TiDB 是有分成算子再往上来读像 TableReader，点查大于索引笼罩，相当于 MySQL 的索引笼罩，相当于 TiDB 一般索引。

读表算子优劣：PointGet/BatchPointGet>IndexReader（MySQL 笼罩索引）> IndexLookupReader（一般索引）> TableReader。对于 TP 类型 SQL 来说尽可能打消 TableReader 读表算子或者缩小后果集。

SQL 谬误索引与统计信息：

TiDB 统计信息和表格衰弱度会间接影响你的索引，通常就不走了，所以你的业务忽然就变慢了，只能说越来越小了。对于现实汽车来说，看表的衰弱度只有是大于 80% 的话，正确索引的概率基本上是能够保障的。

解决办法：
手动或者自动更新表和索引统计信息
(1) 自动更新条件

  • 表中至多 1000 行数据
  • 默认 1 分钟无 DML
  • modify_count > tidb_auto_analyze_ratio 参数（默认 0.5，设置成 0.8）
  • tidb_build_stats_concurrency（默认 4，资源短缺能够调大）
  • tidb_distsql_scan_concurrency（默认 15，AP 30，TP 10）
  • tidb_index_serial_scan_concurrency（默认 1，TP 不调，AP 调成 4）

解决办法：
(1) 设置主动 analyze 工夫 -tidb_auto_analyze_start_time（这里是 UTC 工夫，如果是默认值 00:00 + 0000，则早上 8 点开始执行）。所以倡议设置工夫为业务低峰 -8 小时，比方凌晨执行（16:00 + 0000），完结 tidb_auto_analyze_end_time 设置（23:59 + 0000）。

(2) 如果依然不精确, 能够适当入侵绑定 SQL 打算或者强制走索引。
CREATE [GLOBAL | SESSION] BINDING FOR BindableStmt USING BindableStmt;

(3) 如果避开了主动 analyze 工夫，则应该手动从新统计表信息。
show stats_meta where table_name=’xxx’

show stats_healthy where table_name=’xxx’

show STATS_HISTOGRAMS where table_name=’xxx’ analyze table xxx;

SQL 逻辑优化

TiFlash 函数下推，大家肯定要看一下，因为 TiFlash 不是所有的函数都下推。如果你走 TiFlash 数据量很大，又没有函数下推，代表你会在 TiDB 外面计算，这个过程可能就会比拟耗时。倡议对准官网的反对列表，（下图为局部截取）依照下推列表去标准 SQL。

4）热点问题优化

业务报慢 SQL，监控看单个节点 Coprocessor CPU（Coprocessor 是 TiKV 中读取 数据并计算的模块）异样飙升。（v3.0.14 未开启 Unified read pool，面板指标 TiKV – Details -> Thread CPU）

  • 看读热点，能够基于命令行去做一个脚本，比方 pt-ctl，看 hot read 和 hot write。
    (1) 去看 region 对应的表是哪张，获取热点的单个 region。
    (2) 4.0 以上 dashboard 热力求。
    (3) TiDB_HOT_REGIONS 表中记录了是那张表，有多少个字节。

    而后手动 split Region，而后 hot read schedule 进行调度，CPU 应用资源降落，单个读热点 region 就隐没了。

V4 版本有一个参数 Load base Split，默认 10 秒内 3000 次查问，或者是流量超过了 30MB/ 秒主动分类。每一家的业务都不一样，每一家的集群也不一样，默认只是说是一个挺好的配置，然而大多数的部署 TiDB 可能用的不是 NVMe，可能用的是云盘的 SSD 或者是一般的 SSD，每一家的读流量规范应该依据各自的硬盘配置规范，设置一个失常流量平衡的 Region。
这个能够通过热力求，也能够通过抓取的形式去看，能够做成自动化监控。所以 TiDB 还有个益处就是 Information Schema 外面简直涵盖了你所有的信息，比 MySQL 更全。

像监控、命令能够看最高的读取热点，每天都能够看，用命令行做一个筛选，找到对应的库表切割，切割完之后或者主动切割都能够，而后再察看。然而这个 Load base split 有的时候也有可能，也能够每天跑一遍测验它的后果。

5）流量环境优化

第一，强制 SQL 外面走一些执行打算，执行内容能够限定一个参数，比如说 10 秒，或者内存 20M。咱们针对线上 TP 类型是有的，比方下图这个业务的 SQL，就是点击类的报表零碎，因为点击类的报表零碎因为业务人员选的维度不同，最初的数据量级也不同，你能够设置一个限度，否则可能他点很屡次的话，一个大的流量就会把你的集群冲击掉。

Optimizer Hints 熔断：

  • 执行工夫: MAX_EXECUTION_TIME(N)
  • 执行内存: MEMORY_QUOTA(N)
  • 线上 TP SQL

第二，Global 参数配置确保资源不溢出和连贯品质。

  • 长连贯管制: pt-kill 管制杀掉 Sleep 线程或者重启 TiDB-Server（慎用）
  • 执行内存: tidb_mem_quota_query

第三，现实汽车 AP 和 TP 读流量是分流的，TP 走的是 TiKV，AP 走的是 TiFlash，线上默认所有库表都加了 TiFlash 正本，有 3000 多个同步工作，大略是 3000 多张表，做一个流量分流。有的时候可能走 TiKV 更快，然而有的时候是一个整体切割，如下图所示，当初是两个流量分流了。

  • AP 和 TP 的流量均摊，能够更改执行打算，然而咱们用 Hint 更改执行打算，发现对 AP 类型十分不敌对，测试的时候可能还会走到 TiKV 下面。
    SELECT + READ_FROM_STORAGE(TIFLASH[test1.t1,test2.t2]) / t1.a FROM test1.t t1, test2.t t2 WHERE t1.a = t2.a;
  • Session 会话管制，须要配合 rollback 回滚参数应用，强行走 TiFlash。
    set @@session.tidb_isolation_read_engines = “tiflash”;

  • TiFlash 上面有一个参数肯定要设置，就是如果 TiFlash 产生查问谬误，业务语句返回 TiKV 查问数据。确保万一 TiFlash 正本不能用了，还有读取数据的机会。
    set global tidb_allow_fallback_to_tikv=’tiflash’;

    6）版本优化：

5.0 版本因为有 MPP 性能，咱们去尝试从轻 AP 类型转到 AP 类型，看是否能够罢黜业务迁徙的麻烦。咱们的测试后果拿 2 台 TiFlash 做 MPP 测试作为参考，后果如下：

  • 2 台 TiFlash MPP 业务整体晋升 35%。
  • 业务 SQL 比较复杂，5.0.2 之后官网做了更多的下推优化。

下图能够看出优化前后的运行工夫比照。这些都是线上业务，线上的数仓 SQL 特地简单，都是一两千行的大 SQL，关上文本看大略有 1400 行，所以这个优化成果还是很棒的。

生产环境中，咱们用 5 个 TiFlash node 跑，这是前后的流量比照图，整体有 32 秒，起初根本都降到了 1 秒以下。

然而这个图很骗人的，大家千万不能置信这个 999，你真正须要优化的，可能就不在这个 999 外面，全在那个 0.01 外面。然而整体优化的成果还是很显著的，包含事务提早执行 lantency，都升高了很多。整体的响应更具说服力，以下是一天工夫内的比照图，大于 30 秒的 SQL 少了 87%，大于 60 秒的 SQL 也升高了 87%，大于 2 分钟的 SQL 同比升高了 99%，同样的流量，5.0.2 对咱们整体的优化晋升还是十分大的。

7）架构优化

架构优化的核心思想是用技术架构来转化 SQL 压力，下图是实时数仓的技术架构。下面是 DM 同步 MySQL 的数据源写入到 TiDB，TiDB 做一个 ODS 层之后，再导入到 TiCDC，之后通过分区打入到 Kafka，再分批生产进入 Flink，而后数据回写回 TiDB，提供实时数据和物化视图性能。因为 TiDB 自身不反对物化视图，能够在 Flink 外面解决这个技术难题，打造一个流批一体的实时数仓。

思考到 OLAP 业务 SQL，咱们抉择了 TiKV 存储引擎，这个时候在 Flink 做完计算的表再写回 TiDB 的话，有一些 AP 的 SQL 就能够变成 TP 了，像 Table Reader 的算子有的时候能够变成 PointGet 或者是 BatchPointGet（点查或者表查），范畴查问就会少很多，这样就在侧面缓解了压力。抉择 TiFlash 就能够实现各种维度的聚合操作，实现离线报表和在线统计这些性能。这些都是咱们曾经施行上线的，然而还有几个应用问题，例如：

  • 在现实汽车的 DM 场景下，对表做了 rename 后 TiCDC 就无奈辨认了。因为 TiCDC 默认是以 Table ID 算的，表名一样，然而外面的 Table ID 曾经变了，TiCDC 辨认不了，就只能重启；
  • 新增的 Kafka 分区，流量增大时减少 Kafka 分机，TiCDC 无奈辨认，也须要重启；

  • V4.0.14 版本以前的 TiCDC 稳定性存在问题。

    总结

业务倒退推动技术革新，目前现实汽车的倒退十分快。TiDB 的读流量优化是个全局视角，除了 SQL 自身外，官网提供了十分全面的优化伎俩，包含引擎、架构、执行打算、参数管制等。大家能够去依照本人的业务倒退去做各种不同的尝试。

当然，优化都不能只看外表，TiDB Duration SQL 999 线是最常看的指标，然而也有欺骗性，但有时候最须要优化的是那 0.01%。

最初，没有任何一种数据库是银弹，业务场景的适配和降本增效永远是最重要的。TiDB 更像是集百家之长，而不是专精于一技，在解决分库分表的根底上，根本笼罩所有场景和生态反对。现实汽车也心愿能和 TiDB 一起走得更远。

退出移动版