写点什么

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:002646

评论

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

java开发培训好还是自学好?

小谷哥

软件测试 | 测试开发 | vue双向绑定原理实现

测吧(北京)科技有限公司

Vue 测试框架

软件测试 | 测试开发 | 基于php-code-coverage的增量代码覆盖率实现

测吧(北京)科技有限公司

php 测试 PHP框架

上海参加java开发培训怎么样

小谷哥

OpenHarmony——内核IPC机制数据结构解析

OpenHarmony开发者

OpenHarmony

软件测试 | 测试开发 | 测试人生 | 年薪50w+ 并入职名企大厂,这是双非学历小哥哥给自己30岁的礼物

测吧(北京)科技有限公司

人生 软件测试 测试

软件测试 | 测试开发 | 测试人生 | 双非院校跨城重新开始,薪资翻了2倍还多,这个90后小姐姐好飒

测吧(北京)科技有限公司

软件测试 | 测试开发 | 测试人生 | 双非学历,从外包到某大厂只用了1年时间,在2线城市年薪近30万,我柠檬了......

测吧(北京)科技有限公司

面试 测试 软件测试和开发

软件测试 | 测试开发 | 测试人生 | 从外行到外包,从手工测试到知名互联大厂测开 这个90后小姐姐是怎么腾飞的?

测吧(北京)科技有限公司

软件测试 | 测试开发 | MySQL锁机制总结

测吧(北京)科技有限公司

最佳实践|用腾讯云AI图像搜索打造属于自己的拍立淘

牵着蜗牛去散步

腾讯 图像搜索 腾讯云AI 小程序商城 AI技术实践

软件测试 | 测试开发 | 测试人生 | 从传统行业到名企大厂,薪资翻倍,我做到了

测吧(北京)科技有限公司

面试 测试工程师 软件测试和开发

专访|3DCAT如何赋能Matterverse打造3A游戏画面的Sandbox

3DCAT实时渲染

云计算 元宇宙 实时渲染 实时云渲染 云VR

软件测试 | 测试开发 | 项目倒排,跟工期不足say byebye~

测吧(北京)科技有限公司

测试

2022 DEMO CHINA创新中国峰会拉开帷幕

创业邦

软件测试 | 测试开发 | Kafka入门

测吧(北京)科技有限公司

kafka 软件测试

知识图谱在智能运维中的应用

穿过生命散发芬芳

知识图谱 9月月更

清远市等保测评公司有几家?分别在哪里?

行云管家

网络安全 等保 等保测评 等级测评 清远

软件测试 | 测试开发 | 测试人生 | 双非院校、入职某知名电商公司薪资翻倍还有股票奖励,这个90后小姐姐也太飒了吧?

测吧(北京)科技有限公司

面试 软件测试

软件测试 | 测试开发 | 测试人生 | 从跨专业手工测试转岗外包,再到 Python 测试开发,跳槽涨薪 85%

测吧(北京)科技有限公司

Python 测试开发

Java注解详细

石臻臻的杂货铺

Java 阅读 9月月更

同样是断言,为何 Hamcrest 如此优秀?

霍格沃兹测试开发学社

在北京如何能找到大数据培训机构

小谷哥

web前端培训班口碑哪个比较好

小谷哥

深圳参加java培训哪个机构靠谱

小谷哥

切流的基本逻辑

agnostic

切流

软件测试 | 测试开发 | 使用charles 修改服务器返回数据

测吧(北京)科技有限公司

软件测试 测试

软件测试 | 测试开发 | 测试人生 | 毕业2年,拒绝独角兽入职名企大厂涨薪10万+,这个95后小姐姐好飒

测吧(北京)科技有限公司

软件测试 测试

软件测试 | 测试开发 | 测试人生 | 拿到多个 offer 从了一线互联网公司并涨薪70%,90后小哥哥免费分享面试经验~

测吧(北京)科技有限公司

测试 软件测试和开发

OpenIM集群(非k8s)部署文档

Geek_1ef48b

干货分享!JAVA诊断工具Arthas在Rainbond上实践~

北京好雨科技有限公司

Kubernetes Arthas 企业号九月金秋榜

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