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 size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-m: resident set size (kbytes) unlimited
-u: processes 1024
-n: file descriptors 1024
-l: locked-in-memory size (kb) 64
-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的数据插入.