MONGODB数据架构
升级解决.方案
问题发现
应用服务器突然涌入的用户人数,造成服务器响应变慢
检查服务器,发现每次响应速度极慢,为30ops
检查过程
.发现
数据库查询缓慢
.检查索引
.检查内存占.用量
.检查TCP连接
对比测试1
.硬件配置：
.客户端：
.阿.里云，2cpu，2g内存，windows2008
.服务端：
.阿.里云，router：4cpu，4g内存，centos6.5 64位
.阿.里云，mongod：2cpu，8g内存，centos6.5 64位
.1.对router进.行测试，每秒200qps。
.2.对mongod进.行测试，每秒500qps。
.小结：使.用sharding架构，查询会.比直接对单台mongo查询慢。
对比测试2
.硬件配置：
.客户端：
.阿.里云，2cpu，2.5g内存，windows2008
.阿.里云，2cpu，2.0g内存，windows2008
.服务端：
.阿.里云，mongod：2cpu，2.5g内存，windows2008
.1.在本地2cpu，2.5g内存，windows2008进.行测试，查询速度达到3000qps，甚至有时候能突破5000qps。
.2.在2cpu，2.0g内存，windows2008对mongod进.行测试，查询速度500qps。
.小结：tcp对..网络有很.大的影响。
对比测试3
.硬件配置：
.客户端：
.物理机，2cpu，4.0g内存，windows2008
.服务端：
.物理机，mongod：2cpu，4.0g内存，centos6.5 64位
.物理机，router：2cpu，4.0g内存，centos6.5 64位
.1.对mongod进.行测试，查询速度1000qps。
.2.对router进.行测试，查询速度500qps。
.小结：阿.里云存在.一定的限制，使得速度有上限。
对比测试4
.硬件配置：
.客户端：
. ucloud，2cpu，4.0g内存，windows2008
.服务端：
. ucloud，mongod：2cpu，4.0g内存，centos6.5 64位
. ucloud，router：2cpu，4.0g内存，centos6.5 64位
.1.对mongod进.行测试，查询速度2000qps。
.2.对router进.行测试，查询速度1000qps。
.小结：ucloud.比阿.里云的机器性能好。
对比测试5
.硬件配置：
.客户端：
. ucloud，16cpu，64.0g内存，windows2008
.服务端：
. ucloud，mongod：16cpu，64.0g内存，centos6.5 64位
. ucloud，router：16cpu，64.0g内存，centos6.5 64位
.1.对mongod进.行测试，查询速度13000qps。
.2.对router进.行测试，查询速度10000qps。
.小结：至此终于找到问题根结，客户端cpu核数决定mongodb查询速度。
结论
1.阿.里云的云主机有做某些限制，导致.无论如何设定
系统，数据库的配置，都.无法突破.一个数量级的qps。
2.客户端cpu核数决定mongodb查询速度。
3.tcp的限制通过.走内..网可以避免。
4.linux操作系统胜过
windows。因此mongodb架构在linux上.比架构在windows上更好。
最新架构
最新架构
极限性能测试
.以上.面最新架构进.行测试：
.打开4个iis客户端，同时对router进.行查询，
router可以达到每秒20000次查询。换成业务对比，即每秒可以应付2000个人。
性能结论
.为了保证线上业务的正常运.行，数据库所在的服务器需要8cpu,16g内存。
.为了保证备份的完整性，因此对slave数据库进行备份，对router进行备份。备份保留30天。
|