【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

TiDB 在 360 商业化的应用和实践

  • 2019-10-10
  • 本文字数:3804 字

    阅读完需:约 12 分钟

TiDB 在 360 商业化的应用和实践

业务简介以及数据库选型

360 商业化广告主实时报表业务简介

广告主关键词实时统计报表业务,流程是:业务数据入 Kafka,每 30 秒会有程序读 Kafka 数据进行聚合存储到 TiDB 中,每批次会有几十万的写入,单表数据量 1.2~1.5 亿。


写入场景


业务写入 SQL 主要是:insert on duplicate key update,Batch 为 100,并发为 300。并且每天创建一张新表进行写入,写入初期由于没有重复的 uniq_key,所以主要是 insert,随着数据量到达 2000 多万,update 的操作越多。


表结构如下:


数据库选型:MySQL or TiDB?


说到 TiDB 不得不提 TiDB 的架构,结合架构说说 TiDB 的特性:


  1. 可在线扩展:TiDB Server/PD/TiKV 这 3 大核心模块各司其职,并且支持在线扩容,region 自动 balance,迁移过程对业务无感知。

  2. 高可用:基于 Raft 的多数派选举协议实现了金融级别的数据强一致性保证,且在不丢失大多数副本的前提下,可以实现故障的自动恢复 (auto-failover),无需人工介入。

  3. 无缝迁移:支持 MySQL 协议,业务迁移无需修改代码。

  4. 丰富的监控+运维工具:


  • 监控:基于 Prometheus + Grafana 的丰富监控模板;

  • 运维工具:tidb-ansible 部署+运维;

  • TiDB Data Migration(DM):将数据从 MySQL 迁移+同步的工具;

  • TiDB Lightning:可以从 CSV 文件或者第三方数据源将数据直接导入到 TiKV;

  • TiDB Binlog:备份工具,也可以重放到 Kafka/MySQL/TiDB 等数据库。


TiDB 最核心的应用场景是:大数据量下的分库分表,比如经常需要 1 拆 4,4 拆 8 等数据库无限制拆分情况,并且业务端还需要自己维护路由规则,TiDB 良好的扩展性解决了这些问题


为了能满足这么大的写入量,曾经尝试过单实例 MySQL 去抗请求,测试完后发现单实例 MySQL 压力较大,为了分散写压力,又想走 MySQL 分库分表这种老路,TiDB 3.0.0GA 后,我们拿离线数据进行了压测,2 小时 1.5 亿的数据存储(tps:2W/s),整个系统负载良好,所以决定使用 TiDB。

系统配置

服务器硬件配置


CPU: E5-2630v2*2;


MEM: 16G DDR3*8;


Disk: Intel S3500 300G 1; flash:宝存 1.6T 1;


Net: 1000M*2


服务器系统版本:CentOS Linux release 7.4.1708 (Core)


TiDB 的版本:tidb-ansible-3.0.0


规模:2.8 亿/天


存储:3.8T


TiDB 部署架构图:



注:PD 跟 TiDB 共用服务器

写热点问题

1. 热点现象描述

接到业务反馈:从 7 月份开始, Kafka 队列里面有大量的数据累积,等待写入 TiDB,Kafka 高峰期的待写入 lag 有 3000 多万,接口的调用时间由之前的 1s 变成现在的 3s~5s。我登录 TiDB 发现,单表的数据量由之前的 7000 飙升到 1.2~1.5 亿,虽然数据量几乎翻了一倍,但单条 insert 的性能不至于这么差。


下图是 Kafka 当时的待写入的 lag 情况:


2. 查看 Grafana Overview 监控

TiKV 监控项:scheduler pending commands,发现 TiKV 227 节点大量等待的命令。



TiKV 监控项:CPU 使用也可能看出热点都集中在 227 这个 TiKV 节点上。


解决方案

DBA 可以根据线上写热点表的表结构不同而采用不同的优化方案。对于 PK 非整数或没有 PK 的表,数据在 insert 时,TiDB 会使用一个隐式的自增 rowid,大量的 Insert 会把数据集中写入单个 region,造成写热点。


此时可以使用 SHARD_ROW_ID_BITS 来打散热点,如果业务表可以新建的话(比如我们的报表业务是按天分表),可以结合 pre-split-regions 属性一起在建表阶段就将 region 打散。如果不满足上面的表结构(比如就是以自增 ID 为主键的表),可以使用手动 split region 功能。上面的两种方法都需要 PD 的参数调整来加快热点 region 的调度。

手动 split 热点

因为我的表结构是 ID 自增主键,所以我先使用手动 split 热点。


(1)找出热点 TiKV 的 store number


在 tidb-ansible 的 scripts 目录下 table-regions.py 脚本可以查看热点表和索引 region 分布情况:


python table-regions.py --host=tidb_host –port=10080 db_name tb_name[RECORD – db_name.tb_name] - Leaders Distribution:total leader count: 282store: 1, num_leaders: 1, percentage: 0.35%store: 4, num_leaders: 13, percentage: 4.61%store: 5, num_leaders: 16, percentage: 5.67%store: 7, num_leaders: 252, percentage: 89.36%
复制代码


通过执行上面的命令,能查看热点表都在 store 7(227 服务器) 这个 TiKV 节点。


(2)查看热点的表 regions 分布:


curl http:// ${tidb_host}:10080/tables/db_name/tb_name/regions > regions.log
复制代码


(3)手动切分 region:


切分命令如下


pd-ctl -u http:// ${pd_host}:2379 operator add split-region region_id
复制代码


使用命令找出 store7 的 region id:


grep -B 3 ": 7" regions.log |grep "region_id"|awk -F': ' '{print $2}'|awk -F',' '{print "pd-ctl -u http://pd_host:2379 operator add split-region",$1}' > split_region.sh
复制代码


(4)执行切分脚本就实现了 region 切分:


sh split_region.sh
复制代码

参数优化

(1)调整 PD 调度参数


pd-ctl -u http://pd_host:2379 config set 参数值


“hot-region-schedule-limit”: 8


“leader-schedule-limit”: 8,


“region-schedule-limit”: 16


上面 3 个参数分别是控制进行 hot-region\leader\region 调度的任务个数。 这个值主要影响相应 Region balance 的速度,值越大调度得越快,但是也不宜过大,可以先增加一倍看效果。


(2) TiKV 参数之:sync-log


跟 MySQL 的 innodb_flush_log_at_trx_commit(0,1,2) 类似,TiDB 也有一个 sync-log 参数,该参数控制数据、log 落盘是否 sync。注意:如果是非金融安全级别的业务场景,建议设置成 false,以便获得更高的性能,但可能会丢数据


该参数是 TiKV 参数,需要调整 tidb-ansible 下 conf 目录中 tikv.yml,然后使用下面的命令,只滚动升级 TiKV 节点。


ansible-playbook rolling_update.yml –tags=tikv
复制代码


注:本次优化保持默认 true

优化后查看效果方式

(1)命令查看 leader 调度情况:


pd-ctl -u http:// ${pd_host}:2379 operator show leader
复制代码


(2)查看 Grafana 监控图


PD 监控模块中:scheduler 模块->Scheduler is running->balance-hot-region-scheduler 看这个是否有值,这个有值代表有热点 region 调度。



PD 监控模板中:Operator->Schedule operator create->balance-leader



其他就是从 Overview 中,TiKV 模块的 Leader、Region,CPU、Scheduler pending commands 等变化情况。

终极大招之表结构优化

通过手 split 的方式并没有较好地解决业务的写热点问题,我们采用了 SHARD_ROW_ID_BITS 结合 PRE_SPLIT_REGION 的方式来打散热点。


对于 PK 非整数或没有 PK 的表,在 insert 的时候 TiDB 会使用一个隐式的自增 rowid,大量 INSERT 会把数据集中写入单个 Region,造成写入热点。通过设置 SHARD_ROW_ID_BITS 来适度分解 Region 分片,以达到打散 Region 热点的效果。使用方式:


ALTER TABLE t SHARD_ROW_ID_BITS = 4; #值为 4 表示 16 个分片


由于我们的表每天都会新建,所以为了更好的效果,我们也使用了 PRE_SPLIT_REGIONS 建表预切分功能,通过配置可以预切分 2^(pre_split_regions-1) 个 Region。


下面的最新的表结构,重要的优化是:删除了自增主键 ID,建表时添加了 SHARD_ROW_ID_BITS 结合 PRE_SPLIT_REGION 配置。



该建表语句会对这个表 t 预切分出 4 + 1 个 Region。4 (2^(3-1)) 个 Region 来存 table 的行数据,1 个 Region 是用来存索引的数据。


关于 2 个参数使用详情参见下面的链接:



TiDB FAQ | TiDB 官方用户文档


TiDB 是由 PingCAP 研发的一款定位于在线事务处理/在线分析处理(HTAP)的开源融合型数据库产品,实现了一键水平伸缩,强一致性的多副本数据安全,分布式事务,实时 OLAP 等重要特性,目前已广泛应用于金融服务、互联网、制造等行业。



Split Region 使用文档 | TiDB 官方用户文档


TiDB 是由 PingCAP 研发的一款定位于在线事务处理/在线分析处理(HTAP)的开源融合型数据库产品,实现了一键水平伸缩,强一致性的多副本数据安全,分布式事务,实时 OLAP 等重要特性,目前已广泛应用于金融服务、互联网、制造等行业。

优化最终效果

TiKV 的 CPU 使用非常均衡:



用命令调度来看也比较均衡:


总结

TiKV 作为一个分布式引擎在大部分业务写入中都能较好的分散热点 Region,本文只是拿 360 商业化业务的一个业务场景分享了热点 Region 的分散方法,目的是提供写热点优化的思路,希望能对大家有一定的帮助。本文调优过程中得到了 PingCAP 公司技术人员的大力支持,在此表示衷心的感谢。


作者介绍


代晓磊,现 360 商业化-数据库运维专家。负责整个商业化业务线数据库运维,解决各种数据库疑难问题,推广 TiDB 等新开源数据库应用。


  1. 大街网经验累积阶段(2013-06~2019-02):


数据库方面:负责整个数据库 Team。


具体做过的骄傲的事儿:


  • DB 规范制定

  • 基于开源搭建大街自动化运维平台

  • 大街 DB 高可用

  • MySQL 版本在线升级 (5.1->5.5->5.6->5.7)

  • 数据库优化

  • 经历各种 DB 分库分表迁移

  • DB 备份频度和恢复

  • 拥抱开源技术,如 TiDB 数据库/Cobar 高可用中间件/inception 审核系统/Prometheus + Grafana 监控等

  • 下线 memcache&ttserver,将大街缓存全部统一到 Redis

  • Redis 高可用方案 (Redis cluster/codis/temproxy)

  • Redis 自动化监控和运维


  1. 人人网打怪升级阶段(2012-01~2013-06):


2012 年校招进入人人,主要负责人人无线数据库以及线下 OLAP 数据库的维护。


数据分析方面:让数据驱动业务


具体做过的骄傲的事儿:


  • 实现了做的了技术也玩的了业务

  • 数据分析高效的支持


原文链接


https://asktug.com/t/tidb-360/1135


2019-10-10 08:002537

评论

发布
暂无评论
发现更多内容

Android开发必须掌握!动脑学院android视频

android 程序员 移动开发

Android开发经典实战!享学课堂架构师vip百度云

android 程序员 移动开发

Android开发谈,html5移动开发即学即用网盘

android 程序员 移动开发

Android开发面试题!动脑学院安卓教程vip2019

android 程序员 移动开发

Android开发必学:扔物线rxJava

android 程序员 移动开发

从错误中学习

FunTester

学习 测试 bug 自学 FunTester

Android开发进大厂面试必备技能,大厂面试必备技能

android 程序员 移动开发

Android开发必学,动脑学院课程值得买吗

android 程序员 移动开发

Android开发必学:rxjava扔物线

android 程序员 移动开发

Android开发必须要会!享学课堂Android架构师vip

android 程序员 移动开发

Android开发教程入门!动脑学院vip2019百度网盘

android 程序员 移动开发

Android开发知识点!动脑学院android全套

android 程序员 移动开发

Android开发必会技术!动脑学院vip课程百度云

android 程序员 移动开发

Android开发者跳槽面试,深夜思考

android 程序员 移动开发

终于有人把前端鉴权讲明白了

青云技术社区

云计算 云原生 大前端

Android开发教程入门!android开发艺术探索pdf百度网盘

android 程序员 移动开发

Android开发者该学习哪些东西提高竞争力,程序员面试防坑宝典

android 程序员 移动开发

Android开发面试题目,动脑学院vip

android 程序员 移动开发

Android开发实战,动脑学院android全套

android 程序员 移动开发

Android开发面试技能介绍,动脑学院架构师vip视频

android 程序员 移动开发

这9个单例被破坏的事故现场,你遇到过几个?

Tom弹架构

Java 架构 设计模式

Android开发环境!android开发艺术探索pdf百度网盘

android 程序员 移动开发

Android开发者出路在哪,看完直接跪服

android 程序员 移动开发

Android开发者出路在哪,附大厂真题面经

android 程序员 移动开发

Android开发者该学习哪些东西提高竞争力,做了5年Android

android 程序员 移动开发

Android开发者面试如何系统复习,Android小技巧

android 程序员 移动开发

Android开发核心知识笔记共2100页,统统给你解决

android 程序员 移动开发

Android开发社招面试解答之性能优化,阿里官方推荐

android 程序员 移动开发

新思科技:在智能网联汽车中构建软件安全性及可靠性

InfoQ_434670063458

新思科技 汽车软件安全

Android开发者必须收藏的8个开源库,阿里蚂蚁金服五面

android 程序员 移动开发

Android开发揭秘,扔物线课程怎么样

android 程序员 移动开发

TiDB 在 360 商业化的应用和实践_文化 & 方法_代晓磊_InfoQ精选文章