压测说明
- MySQL数据量为1000万条记录,共1张表,11个字段,一个字段为主键,其余十个字段类型为text,每个字段100个字符。
- MongoDB数据量为1000万个文档,共一个集合,11个字段,一个字段唯一,其余十个字段存储文本,每个字段100个字符。
- MySQL和MongoDB都是阿里云数据库,规格都为4核8G。MySQL buffer cache为6GB,MongoDB cache为4GB。
- 每次测试,threadcount都是100.
- 测试场景为YCSB工具自带的workloada,workloadb,workloadc,workloadd,workloade
read | update | insert | scan | |
---|---|---|---|---|
workloada | 0.5 | 0.5 | 0 | 0 |
workloadb | 0.95 | 0.05 | 0 | 0 |
workloadc | 1 | 0 | 0 | 0 |
workloadd | 0.95 | 0 | 0.05 | 0 |
workloade | 0 | 0 | 0.05 | 0.95 |
准备压测数据
MySQL准备1000万条记录
CREATE TABLE usertable (
YCSB_KEY VARCHAR(255) PRIMARY KEY,
FIELD0 TEXT, FIELD1 TEXT,
FIELD2 TEXT, FIELD3 TEXT,
FIELD4 TEXT, FIELD5 TEXT,
FIELD6 TEXT, FIELD7 TEXT,
FIELD8 TEXT, FIELD9 TEXT
);
./bin/ycsb load jdbc -s -P workloads/workloada -P ./jdbc-binding/conf/db.properties -cp ./mysql-connector-java-8.0.20.jar -p recordcount=10000000 -p threads=10 -p operationcount=10000000
MongoDB准备1000万个文档
./bin/ycsb load mongodb -s -P workloads/workloada -p mongodb.url=mongodb://ycsb:123456@dds-2zeb56f815eb94842.mongodb.rds.aliyuncs.com:3717/ycsb
性能测试
workloada
read=0.5,update=0.5,insert=0,scan=0
监控项 | MySQL | MongoDB |
---|---|---|
QPS | 2412 | 11220 |
CPU | 11% | 100% |
IOPS | 1261 | 8200 |
workloadb
read=0.95,update=0.05,insert=0,scan=0
监控项 | MySQL | MongoDB |
---|---|---|
QPS | 2885 | 15099 |
CPU | 9.3% | 100% |
IOPS | 1376 | 4924 |
workloadc
read=1,update=0,insert=0,scan=0
监控项 | MySQL | MongoDB |
---|---|---|
QPS | 3265 | 19136 |
CPU | 7.4% | 100% |
IOPS | 1630 | 4199 |
workloadd
read=0.95,update=0,insert=0.05,scan=0
监控项 | MySQL | MongoDB |
---|---|---|
QPS | 3313 | 18670 |
CPU | 7.7% | 100% |
IOPS | 1030 | 1685 |
workloade
read=0,update=0,insert=0.05,scan=0.95
监控项 | MySQL | MongoDB |
---|---|---|
QPS | 0 | 550 |
CPU | 100% | 67% |
IOPS | 5000 | 8024 |
压测总结
由于测试资源有限,并没有将MySQL和MongoDB资源扩到足够大,以测试MySQL和MongoDB的极限。
但是从目前测试的结果可以看出:
- 在走索引情况下,虽然MongoDB资源使用率高,但是QPS要比MySQL高的多,达到了“物尽其用”的效果,充分利用硬件资源而换取更快的查询速度。
- 在未走索引情况下,千万这个级别的表,MySQL几乎是跑不动的状态,甚至出现了宕机的情况(主备切换了),而MongoDB却给了惊喜,QPS在500+,还能勉强跑得动。