mongodb优化

jason0401

　　mongodb优化
　　1.尽量少用in的方式查询，尤其是在shard上，他会让你的查询去被一个shand上跑一次，
　　如果逼不得已要用的话再每个shard上建索引。
　　优化in的方式是把in分解成一个一个的单一查询。速度会提高40-50倍。
　　2.和大部分数据库优化一样，查询量大，并发大的时候通过前端加缓存解决。
　　3.在写入mongodb的时候，可以加入safe用安全模式写。
　　这么的话，在一个会话中就算有一个shand或者一个主切换了，程序会返回错误。从新写入。不然不报错会丢数据。
　　使用safe以后，在mongosniffer抓包会在每次写入和更新之后写一个{getlasterror：1}的返回。
　　4.mongodb在做banlace的时候，会锁住在迁移的数据，不能读。
　　因为mongos不知道要去那个shard上去找数据。64M的chunks迁移快的时候1秒，慢的时候3-5秒
　　5. sharding key通常就是会频繁使用的索引
　　6. increamenting sharding key（增量sharding-key）适合于可划分范围的字段，比如integer、float、date类型的，查询时比较快
　　7. random sharding key（随机sharding-key）适用于写操作频繁的场景，而这种情况下如果在一个shard上进行会使得这个shard负载比其他高，不够均衡，故而希望能hash查询key，将写分布在多个shard上进行
　　8. 枚举类型的字段最适合不过啦 :)
　　9. 考虑复合key作为sharding key
　　9. 总的原则是查询快，尽量减少跨shard查询，balance均衡次数少。
　　10.mongodb默认是单条记录4M，尤其在使用GFS的时候，一定要注意shrading-key的设计。
　　不合理的sharding-key会出现，多个文档，在一个chunks上，同时，因为GFS中存贮的往往是大文件，导致mongodb在做balance的时候无法通过sharding-key来把这多个文档分开到不同的shard上，
　　这时候mongodb会不断报错Tue Jan 10 15:24:59 [conn27669]   Uncaught std::exception: St9bad_alloc, terminating。最后导致mongodb倒掉。
　　解决办法：加大chunks大小（治标），设计合理的sharding-key（治本）。
　　12.在一个shard中要注意PRIMARY，SECONDARY，ARBITER的设计。
　　例如，我们公司环境中的1P，2S，2A的环境，PRIMARY倒掉以后有一定几率出现2A同时支持不同的SECONDARY，导致一直无法选择出新的PRIMARY。
　　表现是mongos查询报错：
　　> db.users.find()
　　error: { "$err" : "error querying server: 10.10.21.163:27018", "code" : 13633 }
　　> db.users.find()
　　error: {
　　"$err" : "DBClientBase::findOne: transport error: 10.10.21.163:27018 query: { setShardVersion: \"test.users\", configdb: \"10.7.3.228:27019\", version: Timestamp 11000|1, serverID: ObjectId('4e2f64af98dd90fed26585a4'), shard: \"shard0000\", shardHost: \"10.10.21.163:27018\" }",
　　"code" : 10276
　　}
　　> db.users.find()
　　error: { "$err" : "socket exception", "code" : 11002 }
　　手动添加的话一个 SECONDARY还是报错
　　> db.runCommand({addshard:"10.10.21.164:27017"});
　　{
　　"ok" : 0,
　　"errmsg" : "host is part of set: set163164 use replica set url format /,,...."
　　}
　　解决办法：重新启动其中一个SECONDARY问题解决。
　　具体操作如下：
　　use admin
　　var cfg={_id:"set162163164", members:[{_id:0,host:"10.10.21.162:27018"}, {_id:1,host:"10.10.21.163:27017"}, {_id:2,host:"10.10.21.164:27017",arbiterOnly:true} ]}
　　rs.initiate(cfg)
　　rs.conf()
　　use admin
　　#db.runCommand({addshard:"set162163164/10.10.21.162:27018,10.10.21.163:27017,10.10.21.164:27017"})       #正常添加3台
　　db.runCommand({addshard:"set162163164/10.10.21.162:27018,10.10.21.163:27017"})       #arbiter
　　db.runCommand({addshard:"10.10.21.165:27018"})
　　db.runCommand({enableSharding:"test"})
　　db.runCommand({shardcollection:"test.users",key:{_id:1}})
　　13.通过ulimit -a来控制mongodb使用内存的大小
　　ulimit 是控制着所有进程的内存大小，怎么针对MongoDB进行控制呢？
　　其实可以变通的，我们在自己linux里使用一个用户来运行MongoDB，其它程序用其它用户进行运行。因为ulimit是可以限制指定用户资源的.
　　通过ulimit -a来查看所有可以修改的资源
　　ulimit -a @root
　　-t: cpu time (seconds) unlimited

　　-f: file>
　　-d: data seg>
　　-s: stack>
　　-c: core file>
　　-m: resident set>　　-u: processes 1024
　　-n: file descriptors 1024

　　-l: locked-in-memory>　　-v: address space (kb) unlimited
　　-x: file locks unlimited
　　-i: pending signals 15661
　　-q: bytes in POSIX msg queues 819200
　　-e: max nice 0
　　-r: max rt priority 0
　　这里我们修改的是 ulimit -v: address space(kb) 选项 也就是用户进程的最大虚拟地址空间。
　　我们新建个用户cb，在启动mongod之前
　　ulimit -v 1000000 修改最大虚拟地址空间为1G
　　然后运行mongod 端口为10000，并执行1000W的数据插入脚本。
　　再使用root用户，不对ulimit进行任何修改，开起另外一个mongod 端口为20000 ,也同时进行1000W的数据插入.