|
标题
|
测试报告
|
|---|---|
| 背景目标 |
大航海databus任务在合并阶段费资源，且大表执行时间较长，期望缩短同步时间可以10分钟抽10亿条数据。数据同步需要先建表，再建任务，配置不方便。 |
| 结论 | 在满足配置时可以达到期望速度，配置如下 |
| 所需环境信息 |
mysql=========CPU:16核 内存:32G IOPS:32000 数量2台 离线资源包=====CPU:8核 内存:16G 数量:16个 实时资源包=====CPU:16核 内存:32G 数量:16个 |
| 建议方案 |
离线同步： 方案1：直接走离线资源包，达到配置就可以满足10分钟抽10亿条。问题：离线资源包所属pod有瓶颈，128核才刚满足，需再快的话需要单独联系采用大核数服务器 实时同步： 方案1：全量抽取阶段走离线资源包，增量抽取走实时资源包。因为全量抽取可以满足快速抽数诉求，相对纯用实时资源，比较省资源。增量同步走实时资源包 方案2：纯走实时资源包，任务配置管理比较方便，可以分阶段配置资源，如全量抽取配置资源大一些，增量抽取使用小资源。缺点是实时任务每分钟要保留检查点，sink算子写入时也比较费资源，是离线资源的三倍。 |
| 概念 |
离线资源组：由固定cpu内存组成的资源组，是一台Pod虚拟隔离出来的资源。 Pod：隐藏概念，多个离线资源组组成一个Pod，Pod可以理解为一个虚拟物理机有资源上限，也是抽数速度上限，目前最大128核，如扩容需单独申请。 实时资源组：底层为腾讯oceanus，理论上可以无限扩，可以达到很高的同步能力 |
| 相关文档 |
mysql数据库性能介绍：https://cloud.tencent.com/document/product/236/19707 数据集成工具入口：腾讯云控制台，搜索数据集成 使用教程：腾讯数据集成工具使用 详细测试信息：腾讯数据集成工具性能测试 |
一、资源规格
1、mysql数据库
|
分组名称
|
名称
|
内存
|
CPU
|
IOPS
|
磁盘
|
版本
|
|---|---|---|---|---|---|---|
| 低配 | bdg-test | 8G | 4核 | 8000 | 200GB | MySQL5.7 |
| 中配 | test-wangshida | 16G | 8核 | 20000 | 1700GB | MySQL5.7 |
| 高配 | test-wangshida | 32G | 16核 | 32000 | 1700GB | MySQL5.7 |
2、测试数据表
|
数据库
|
测试表名
|
数据行数
|
列数
|
总存储量
|
数据存储量
|
索引存储量
|
存储引擎
|
|---|---|---|---|---|---|---|---|
| 低性能 | order_info | 162 8287 | 40 | 1.25 GB |
416 MB |
844MB | InnoDB |
| 低性能 | order_info1 |
2 6119 6181 |
40 |
77.28 GB |
58.03 GB |
16.12 GB |
InnoDB |
| 高性能 | order_info1 | 2 9359 9266 | 40 | InnoDB | |||
| 高性能 | ss_robot_task_test | 约11亿 | 25 | 1.19TB | 1.19TB | 0 | InnoDB |
3、数据集成资源包
离线资源包
|
分组名称
|
名称
|
内存
|
CPU
|
数量
|
|---|---|---|---|---|
| 低配 | 离线资源包 | 16G | 8核 | 1 |
| 中配 | 离线资源包 | 32G | 8核 | 2 |
| 高配 | 离线资源包 | 16G | 8核 | 8 |
实时资源包
|
分组名称
|
名称
|
内存
|
CPU
|
数量
|
|---|---|---|---|---|
| 低配 | 实时资源包 | 64G | 16核 | 1 |
| 中配 | 实时资源包 | 64G | 16核 | 2 |
二、离线同步
期望10分钟10亿条数据，以下为不同配置的最高速度
|
资源组 |
数据库 |
同步表 |
同步数据量 |
并发 |
同步花费时间 |
平均速度 |
平均速率 |
mysql资源 |
离线包资源 |
|---|---|---|---|---|---|---|---|---|---|
| 低配（1个） | 低配 | order_info | 162 8287 | 1 |
费时：61秒 |
6.26MB/s |
3.36万条/s |
CPU:5% |
CPU:26% 内存:24% |
| 低配（1个） | 低配 | order_info1 | 2 6119 6181 | 最优10 |
费时：43分钟 |
16.97MB/s |
10.36万条/s | CPU:11.46% |
CPU:95%以上 内存:95%以上 |
|
中配（2个） |
低配 | order_info1 | 2 6119 6181 | 最优20 | 费时：23.6分钟 |
30.94MB/s |
18.89万条/s |
CPU:21.91% |
CPU:95%以上 内存:40%以上，32G没用上 |
| 高配（8个） | 低配 | order_info1 | 2 6119 6181 | 最优10 |
费时：10分钟 |
73.95MB/s |
45.15万条/s |
CPU:86% IOPS:120% |
80%以上 |
| 高配（8个） | 高配 | order_info1 | 2 9359 9266 | 最优20 |
费时：6.73分钟 |
120.87MB/s |
73.39万条/s |
CPU:16% IOPS:37% |
80%以上 |
| 高配（8个） | 高配 | ss_robot_task_test | 约11亿 | 最优20 | 费时:19.58分钟 |
157.77MB/s |
96.24万条/s |
CPU:23.69% IOPS:120% |
80%以上 |
| 期望-高配（16个） | IOPS:64000 | 24个列的表 | 约10亿 | 20 | 期望10分钟 | 300MB/s | 200万条/s | - | - |
期望10分钟10亿，则需要以下配置：
|
类型 |
CPU |
内存 |
磁盘 |
数量 |
其它 |
月费用 |
|---|---|---|---|---|---|---|
| mysql | 32核 |
256GB |
最低1.7TB | 1 | 单节点IOPS:80000 | |
| mysql |
16核 |
32GB | 最低1.7TB | 2 | 单节点IOPS:32000 | |
| 数据集成-离线包 | 8核 | 16GB | - | 16 | 8*16=128核 |
|
调优方法：
1、根据资源包规格调整并发，单任务可以跨资源包，但不可以跨pod。单pod目前最大128核，目前最大抽数瓶颈是10分钟10亿条数据
注：
1、单任务只能在一个pod上跑，单pod有资源瓶颈，如单pod最大只能128核，再大需要走特殊申请
2、单pod最大能满足10分钟10亿条期望，如期望再高，则需要单独申请高核数和内存的服务器
3、并发根据资源包设置，低配10并发合适，高配20并发合适
三、实时同步
期望10分钟10亿条数据，以下为不同配置的最高速度
|
资源组 |
数据库 |
同步表 |
同步数据量 |
|
同步花费时间 |
速度 |
速率 |
mysql cpu使用 |
实时包使用率 |
|---|---|---|---|---|---|---|---|---|---|
| 低配（1个） | 低配 | order_info1 | 2 6119 6181 | 0.5CU*26 |
约40分钟 |
高40MB/s 低37MB/s |
高峰12.69万条/s 低峰11.24万条/s |
19% | 93.75% |
| 中配（2个） | 低配 | order_info1 | 2 6119 6181 | 1CU*30 |
约20分钟 |
高100MB/s 低95.96MB/s |
高峰26.71万条/s 低峰25.37万条/s |
45% |
100% |
| 中配（2个） | 低配 | order_info1 | 2 6119 6181 | 0.5CU*60 | 约20分钟 |
高96.63MB/s 低89.55MB/s |
高峰25.5万条/s 低峰23.70万条/s |
42% | 100% |
| 中配（2个） | 高配 | order_info1 | 2 9359 9266 | 1CU*30 | |||||
| 期望高配（16个） | IOPS:64000 | 订单表 | 约10亿 | 20 | 期望10分钟 | 300MB/s | 200万条/s | - | - |
期望10分钟10亿，调大实时资源包大小即可，没有扩容瓶颈，预估资源如下
|
类型 |
CPU |
内存 |
磁盘 |
数量 |
其它 |
月费用 |
|---|---|---|---|---|---|---|
| mysql | 32核 |
256GB |
最低1.7TB | 1 | 单节点IOPS:80000 | |
| mysql |
16核 |
32GB | 最低1.7TB | 2 | 单节点IOPS:32000 | |
| 数据集成-实时 | 16核 | 64GB | - | 16 | 16*16=256核 |