mongodb分库
测试机配置[*]SAS 硬盘
[*]16GB内存
[*]千兆网
[*]8 cores cpu
mongodb
[*]版本： 2.2.3
[*]replicaset: 3台物理机
[*]driver：pymongo2.5.2(w=2,safe=True,use_greenlets)
分库前测试结果
之前有测试过mongodb的读写性能 对于单条数据比较小的应用场景 非常适合 读写的吞吐量很不错 但是我们的应用场景是单条数会超过1MB 实际测试下来的结果是写锁非常严重 吞吐量保持在20qps左右 但是mongodb的CPU占用率不到70% 内存占用量在40% - 50% 磁盘IO也未到瓶颈 mongostate 查看状态的时候 写锁的比例非常高
给常用查询的字段加索引
开始测试时 没有给查询的字段加索引 使用explain的结果如下：
view sourceprint? 01 db.users.find({'uid':'123456789'}).explain() 02 { 03 "cursor" : "BasicCursor", 04 "isMultiKey" : false, 05 "n" : 0, 06 "nscannedObjects" : 2, 07 "nscanned" : 2, 08 "nscannedObjectsAllPlans" : 2, 09 "nscannedAllPlans" : 2, 10 "scanAndOrder" : false, 11 "indexOnly" : false, 12 "nYields" : 0, 13 "nChunkSkips" : 0, 14 "millis" : 9, 15 "indexBounds" : {}, 16 } 在查询的时候 使用的是BasicCursor 没有对查询uid添加索引 导致查询时需要遍历所有的ns
添加索引db.users.ensureIndex({'uid':1})后 再看查询的解释
view sourceprint? 01 db.users.find({'uid':'123456789'}).explain() 02 { 03 "cursor" : "BtreeCursor uid_1", 04 "isMultiKey" : false, 05 "n" : 0, 06 "nscannedObjects" : 0, 07 "nscanned" : 0, 08 "nscannedObjectsAllPlans" : 0, 09 "nscannedAllPlans" : 0, 10 "scanAndOrder" : false, 11 "indexOnly" : false, 12 "nYields" : 0, 13 "nChunkSkips" : 0, 14 "millis" : 0, 15 "indexBounds" : { 16 "uid" : [ 17 [ 18 "123456789", 19 "123456789" 20 ] 21 ]}, 22 } 添加索引后 吞吐有一定的提升 但是非常有限 我们测试的主要场景是大量的更新操作 查看mongostat的结果 还是写锁严重
分库
mongodb在2.2后的写锁是数据库级别的 所以我们尝试着进行分库 在单个replicaset集群上部署多个数据库 然后进行测试 实际的测试结果为 写锁被分散到多个数据库上 但是local这个数据库的写锁比例突然上升了很多 能到120%+
查看local这个数据库 里面存的数据
view sourceprint? 1 switched to db local 2 dds:PRIMARY> show collections; 3 me 4 oplog.rs 5 replset.minvalid 6 slaves 7 system.indexes 8 system.replset 上述collections中 me是mongodb的host信息 slaves里面存了secondary和oplog同步的信息 opslog.rs里面记录的是oplog 怀疑是oplog同步导致local写锁比例上升
添加replicaset集群
为了验证上述猜测 我们在测试的三台物理机上又搭建了一个replicaset 然后再进行测试 结果非常好 local写锁有明显下降 吞吐量提高到150qps
页:
[1]