liuwei 创建于 2018-07-07 22:34;更新于 2018-08-13 08:31
mongodb 和 polardb 加载数据数据测试的情况记录报告
1、mongodb 集群的配置情况
1.1、mongos
2 个 mongos 每个的配置为:2 核 4 GB
1.2、shards
总共有 8 个 shard,每个 shard 配置为 4 核 8 GB
2、加载的表的情况
2.1、表的数据量
数据量:20 亿左右
2.2、表结构
字段 | 字段类型 | 字段含义 |
---|---|---|
did | string | 数盟 1 代 ID |
mac__addr | string | MAC 地址 |
imei | string | 国际移动设备身份码的缩写 |
bluetooth | string | 蓝牙 MAC |
serial | string | 序列号 |
sysbootid | string | 系统 ID 每次重启机器会变 |
android__id | string | Android id |
ro_product_manufacturer | string | 厂商小写 |
manufacturer | string | 厂商大写 |
ro_product_brand | string | 品牌 |
brand | string | 品牌 |
ro_product_model | string | 机型 |
model | string | 机型 |
iccid | string | 集成电路卡识别码 |
imsi | string | 国际移动用户识别码 |
gsm_operator_numeric | string | 运营商 |
root | string | 设备是否 root |
cpu_abi | string | 主板信息 |
ro_build_fingerprint | string | rom 信息 |
create_date | string | 设备首次上报时间 |
recent_report_date | string | 最新的上报时间 |
tmp_unique_id | string | 临时唯一 ID |
rule1 | bigint | MAC 厂商合规标记 |
rule2 | bigint | IMEI 厂商合规标记 |
imsi_rule | bigint | imsi iccid 运营商合规,-1 不可用;1 合规,0 不合规 |
manu_rule | bigint | 厂商大小写合规,-1 不可用;1 合规,0 不合规 |
ro_manu_rule | bigint | ro product manufacturer 合规标记 |
mac_rule | bigint | MAC 合规标记 |
sd_rule | bigint | sd_cid 合规标记 |
bd_rule | bigint | bd_deviceid 合规标记 |
imei_rule | bigint | IMEI 合规标记 |
blue_rule | bigint | 蓝牙 MAC 合规标记 |
serial_rule | bigint | serial 合规标记 |
sys_rule | bigint | sys boot id 合规标记 |
id2 | string | 2 代 id |
type | string | 设备状态:same,not_same,un_judge |
status | string | 设备标记,碰撞,无法判清,非多发非碰撞,多发碰撞,多发等 |
id2_online | string | 线上二代 ID |
2.3、表的索引
- 单字段:
did_1
did_2_change
android_id
- 组合索引
mac,imei
mac,bluetooth
imei,bluetooth
imei,sys_boot_id
bluetooth,sys_boot_id
sys_boot_id,mac
分片索引:
did_2
3、入数的设置
条目项 | 值 |
---|---|
批加载 | 每批加载 1000 条记录 |
并发数(线程数) | 10 |
预分片数 | 30000 |
3.1、入数随着时间变化的情况
从上图可以看出,第一个小时入数的速度还是很快的,在前 4 个小时的下降是最快的,前 5-15 个小时比较快的下降,15 个小时以后下保持一个比较平稳的状态,下降的速度很缓慢了。cpu 最高 80% 左右,内存最高 60% 左右,因为有线上正式业务,没把所有的资源都用到极限。
4、polardb 数据库的介绍(只测试 35 分钟左右,因速度慢的缘故)
4.1、4 核 32 GB 情况的测试,分区情况是用 key 的方式。
- 10 线程、每批 1000 条,每 5 分钟的入数情况,
时间 | 记录数 (单位:万) |
---|---|
第 1 个五分钟 | 130 |
第 2 个五分钟 | 110 |
第 3 个五分钟 | 120 |
第 4 个五分钟 | 80 |
第 5 个五分钟 | 95 |
第 6 个五分钟 | 77 |
第 7 个五分钟 | 81 |
- 20 线程、每批 1000 条
时间 | 记录数 (单位:万) |
---|---|
第 1 个五分钟 | 178 |
第 2 个五分钟 | 150 |
第 3 个五分钟 | 119 |
第 4 个五分钟 | 103 |
第 5 个五分钟 | 100 |
第 6 个五分钟 | 91 |
第 7 个五分钟 | 87 |
从以上可以看出,通过增加并发数据是没办法提供加载速度的,阿里云反馈,通过监控指标 cpu 已经到达 400% 了,后通过添加 cpu 来提高集群的能力
4.2、20 核情况的测试,分区情况是用 key 的方式。
-
一种是通过 insert Many 的方式
insert into table_name (field1,field2) vaues (value1_1,value1_2),(value2_1,value2_2) 的方式。
时间 | 每小时插入的数据量(单位:万) |
---|---|
第 1 个小时 | 2302 |
第 2 个小时 | 1833 |
第 3 个小时 | 2025 |
第 4 个小时 | 1804 |
第 5 个小时 | 1668 |
第 6 个小时 | 1609 |
第 7 个小时 | 1526 |
第 8 个小时 | 1496 |
第 9 个小时 | 1467 |
第 10 个小时 | 1445 |
第 11 个小时 | 1417 |
第 12 个小时 | 1384 |
第 13 个小时 | 1352 |
第 14 个小时 | 1316 |
第 15 个小时 | 1285 |
- 另一种是同 mysql api 的 addBatch 方式
时间 | 每小时插入的数据量(单位:万) |
---|---|
第 1 个小时 | 2711 |
第 2 个小时 | 1748 |
第 3 个小时 | 1652 |
第 4 个小时 | 1592 |
第 5 个小时 | 1546 |
第 6 个小时 | 1468 |
第 7 个小时 | 1425 |
第 8 个小时 | 1383 |
第 9 个小时 | 1343 |
第 10 个小时 | 1309 |
第 11 个小时 | 1296 |
第 12 个小时 | 1284 |
第 13 个小时 | 1283 |
第 14 个小时 | 1241 |
第 15 个小时 | 1298 |
第 16 个小时 | 1209 |
第 17 个小时 | 1031 |