MongoDB 和 PolarDB 加载数据数据测试的情况记录报告

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、表的索引

• 单字段：

1. did_1
2. did_2_change
3. android_id

• 组合索引

1. mac,imei
2. mac,bluetooth
3. imei,bluetooth
4. imei,sys_boot_id
5. bluetooth,sys_boot_id
6. sys_boot_id,mac

分片索引：

1. 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