MongoDB使用中的一些问题

从shell中更新/写入到文档的数字，会变为float类型

引用：“shell中的数字都被MongoDB看成是双精度数。这意味着若是你从数据库中得到的是一个32位整数，修改文档后，将文档存回数据库的时候，这个整数也就被换成了浮点数，即使保持这个整数原封不动也会这样的。”

restore数据到新DB时，不要去先建索引

把bson数据文件restore到另外一个DB时，须要注意：不能先建立索引再restore数据，不然性能极差，mongorestore工具默认会在restore完数据时，根据dump出来的index信息建立索引，无须本身建立，若是是要更换索引，也应该在数据入库完以后再建立。

bson size不能超过16MB的限制

单个文档的BSON size不能超过16MB。find查询有时会遇到16MB的限制，譬如使用$in 查询的时候，in中的数组元素不能太多。对一些特殊的数据源作MapReduce，MapReduce中间会将数据组合为“KEY：[VALUE一、VALUE2]”这样的格式，当value特别多的时候，也可能会赶上16MB的限制。 限制无处不在，须要注意，”The issue is that the 16MB document limit applies to everything - documents you store, documents MapReduce tries to generate, documents aggregation tries to return, etc.

批量插入

批量插入能够减小数据往服务器的提交次数，提升性能，通常批量提交的BSON size不超过48MB，若是超过了，驱动程序自动修改成往mongos的屡次提交。

安全写入介绍及其沿革

关键字：acknowledge、write concern。 在2012年11月以前，MongoDB驱动、shell客户端默认是不安全写入，也就是fire-and-forget，动做发出以后，不关心是否真的写入成功，若是这时候出现了_id重复、非UTF8字符等异常，客户端不会知道。在2012年11月以后，默认为安全写入，安全级别至关于参数w=1，客户端能够知道写入操做是否成功。若是代码使用Mongo或者Collection来链接数据库，则说明它是默认不安全写入的legacy代码，安全写入已经把链接数据库修改成MongoClient接口。 安全写入能够分为三个级别，

• 第一级是默认的安全写入，确认数据写入到内存中就返回（w=N属于这一级）；
• 第二级是Journal save，数据在写入到DB磁盘文件以前，MongoDB会先把操做写入到Journal文件，这一级指的是确认写入了Journal文件就返回；
• 第三级是fysnc，全部数据刷写到到DB磁盘文件才返回。

通常第一级就足够了，第二级是为了保证在机器异常断电的状况下也不会丢失数据。安全写入要付出性能的代码：不安全写入的性能大概是默认安全写入的3倍。使用fync参数则性能更差，通常不使用。若是是副本集（replica set），其w=N参数，N表示安全写入到多少个副本集才返回。

善用索引——可能跟你觉得的不同

使用组合索引的时候，若是有两组索引，在限量查询的状况下，可能跟常规的认识不一样： 利用组合索引作的查询，在不一样数量级下会有不一样性能： 组合索引A： {"age": 1, "username": 1} 组合索引B： {"username": 1, "age": 1} 全量查询:db.user.find({"age": {"$gte": 21, "$lte":30}}).sort({"username":1}) ,使用索引A的性能优于索引B。 限量查询： db.user.find({"age": {"$gte": 21, "$lte": 30}}).sort({"username": 1}).limit(1000) ，使用索引B的性能优于索引A。 这两个查询在使用索引A的时候，是先根据age索引找到符合age的数据，而后再对这些结果作排序。使用索引B的时候，是遍历name，对应的数据判断age，而后获得的结果是name有序的。 优先使用sort key索引，在大多数应用上执行得很好。

查询时索引位置的无顺序性

作find的时候，并不要求索引必定要在前面， 譬如：db.test集合中对R有索引 db.test.find({R:"AA", "H": "BB"}).limit(100) db.test.find({"H":"BB", "R" : "AA"}).limit(100) 这两个查找性能同样，它都会使用R索引。只有当R属性不参与排序且R的位置不影响查询结果的条件下，才会知足索引的无顺序行。

使用组合索引作shard key能够大幅度提升集群性能

集群分片应遵循“总体分散，局部递增”的原则。“固定值+增量值” 两字段作组合索引能够有效的实现分布式集群中的分散多热点写入、读取。

在单个MongoDB实例上，最高效的写入是顺序写入，而MongoDB集群则要求写入能随机，以便平均分散到多个MongoDB实例。因此最高效的写入是有多个局部热点：在多个MongoDB实例之间是分散写入，在实例内部是顺序写入。 要实现这一点，咱们采用组合索引。

怎么建索引更能提升查询性能？

在查询时，索引是否高效，要注意它的cardinality（cardinality越高表示该键可选择的值越多），在组合索引中，让cardinality高的放在前面。也就是说在建立组合索引的时候，应该把枚举类型、布尔类型等低cardinality的属性排在后面，避免给低cardinality属性建立独立索引。

index cardinality（索引散列程度），表示的是一个索引所对应到的值的多少，散列程度越低，则一个索引键对应的值越多，索引效果越差。在使用索引时，高散列程度的索引能够更多的排除不符合条件的文档，让后续的比较在一个更小的集合中执行，这更高效。因此通常选择高散列程度的键作索引，或者在组合索引中，把高散列程度的键放在前面。

非原地update，性能会不好

update文档时，若是新文档的空间占用大于旧文档加上它周围padding的空间，那么就会放弃原来的位置，把数据拷贝到新空间。

TTL索引

TTL表明"time to live"，TTL是一种特殊的索引，能够将集合中过时的数据删除。使用expireAfterSeconds 选项建立索引便可。 推荐和限制：

• 使用usePowerOf2Sizes标识能够更有效的防止磁盘碎片的产生。 db.runCommand( {collMod: "products", usePowerOf2Sizes : true }) db.runCommand( {collMod: "products", usePowerOf2Sizes : false })
• TTL索引必须创建在date类型的字段上，若是不是date类型将不会被删除。
• TTL索引不能创建在_id字段上
• TTL索引不能是联合索引，不然会报错，不让建
• 若是date类型中包含一个数组，好比time:['date1','date2']，那么TTL会按照一个最先的进行过滤。
• TTL不能创建在固定集合上（capped collection）,由于固定集合不能删除数据。 使用方法： db.log.ensureIndex( { "createDate": 1 }, { expireAfterSeconds: 3600 } )

没法在索引创建以后再去增长索引的过时时间

若是索引创建指定了过时时间，后续要update过时时间能够这样子：

db.runCommand({"collMod":"a", index:{keyPattern:{"_":-1}, expireAfterSeconds: 60}})。 注意，经过collMod能修改过时时间的前提是：这个索引有过时时间，若是这个索引以前没有设置过时时间，那么没法update，只能删了索引，重建索引并指定过时时间。

###  **paddingFactor是什么？**
它是存储空间冗余系数，1.0表示没有冗余，1.5表示50%的冗余空间，有了冗余空间，可让后续引起size增长的操做更快（不会致使从新分配磁盘空间和文档迁移），通常是在1到4之间。能够经过db.collection.stats()看到collection的该值“paddingFactor”。
该值是MongoDB本身处理的，使用者没法设置paddingFactor。咱们能够在compact的时候对已经有的文档指定该值，但这个paddingFactor值不影响后续新插入的文档。
repairDatabase跟compact相似，也能移除冗余减小存储空间，但冗余空间少了会致使后续增长文档size的update操做变慢。
虽然咱们没法设置paddingFactor，可是可使用usePowerOf2Sizes保证分配的空间是2的倍数，这样也能够起到做用（MongoDB2.6版本起默认启用usePowerOf2Size）。
或者手动实现padding：在插入文档的时候先用默认字符占用一块空间，等到真实数据写入时，再unset掉它。
###  **usePowerOf2Size是什么**
这是为更有效的复用磁盘空间而设置的参数：分配的磁盘空间是2的倍数，若是超过了4MB，则是距离计算值最近的且大于它的完整MB数。
能够经过db.collections.stats()看到该值“userFlags”。
MongoDB2.6以后默认开启usePowerOf2Size参数
使用后的效果能够看这里的PPT：http://www.slideshare.net/mongodb/use-powerof2sizes-27300759

###  **aggregate pipeline 指定运算完成输出文档跟MapReduce相比有不足**
（基于MongoDB2.6版本）MapReduce能够指定输出到特定的db.collection中，例如：out_put = bson.SON([("replace", "collection_name" ), ("db", "xx_db")])
aggregate pipeline只能指定collection名字，也就意味着数据只能写入到本db，同时结果不能写入到capped collection、shard collection中。
相比之下，aggregate pipeline限制是比较多的，若是咱们须要把结果放到某个DB下，则须要再作一次迁移：
db.runCommand({renameCollection:"sourcedb.mycol",to:"targetdb.mycol"})
可是！！上面的这条命令要求在admin下执行，且只能迁移往同shard下的DB，且被迁移的collection不能是shard的。

###  **中止MongoD进程的几种方式**
> ###  进入到MongoD的命令行模式执行shutdown，
>$ mongo --port 10001
> use admin
> db.shutdownServer()
>###  1方式的简化：**
mongo admin --port 10001 --eval "db.shutdownServer()"
>###  使用MongoD命令行关闭，须要指定db路径：
mongod --dbpath ./data/db --shutdown

###  **集群的shard key慎重采用hash**
若是你的日志是有日期属性的，那么shard key不要使用hash，不然删除过时日志时没法成块删除；在更新日志的时候，也不能利用局部性原理，查找、更新、插入数据都会所以而变慢。通常来讲，hash id应付小数据量时压力不大，但在数据量较大（热数据大于可用内存容量）时，CRUD性能极差，且会放大碎片对性能的影响：数据很是分散，当有过时日志被删除后，这些删除后的空间成为碎片，可能会由于磁盘预读策略被加载到内存中。另外，采用hash shard key还会浪费掉一个索引，浪费很多空间。

###  **副本数也不用太多**
若是你的副本数量超过了12个（MongoDB3.0.0超过了50个），那么就要选择使用 master-slave ，但这样会失去故障自恢复功能，主节点故障时，须要手动去切换到无端障节点。

###  **mongos的config server配置信息中不要使用localhost、127.0.0.1**
启动mongos时，config server的配置信息不得使用localhost、127.0.0.1，不然添加其它机器的shard时，会出现错误提示：
>
"can’t use localhost as a shard since all shards need to communicate. either use all shards and configdbs in localhost or all in actual IPs host: xxxxx isLocalHost"
以新的config server启动mongos，也须要重启config server，不然会有错误提示：
“could not verify config servers were active and reachable before write”
若是改完后面又出现 “mongos specified a different config database string”  错误，那么还须要重启mongod，
>修改了config server 几乎是要所有实例重启。另外，在配置replica set时也不得使用localhost、127.0.0.1。


###  **shard key的选择跟update性能紧密关联**
分布式MongoDB，shard key的选择跟update性能，甚至是update可用性有很大关系，须要注意。
1.在对文档个别字段update时，若是query部分没有带上shard key，性能会不好，由于mongos须要把这条update语句派发给全部的shard 实例。
2.update 的upsert参数为true时，query部分必须带上 shard key，不然语句执行出错，例子：
>db.test.update({"_id":".7269993106A92327A89ABCD70D46AD5"}, {"$set":{"P": "aaa"}, "$setOnInsert":{"TEST":"a"}}, true)
WriteResult({
"nMatched" : 0,
"nUpserted" : 0,
"nModified" : 0,
"writeError" : {
"code" : 61,
"errmsg" : "upsert { q: { _id: \".7269993106A92327A89ABCD70D46AD5\" }, u: { $set: { P: "aaa" }, $setOnInsert: { TEST: \"a\" } }, multi: false, upsert: true } does not contain shard key for pattern { _: 1.0, B: 1.0 }"
}
})
    
    这是由于若是没有shard key，mongos既不能在全部shard实例上执行这条语句（可能会致使每一个shard都插入数据），也没法选择在某个shard上执行这条语句，因而出错了。
    另外，须要特别注意，若是使用pymongo引擎，它不会告诉你出错了，只是函数调用陷入不返回，在shell下执行才能看到错误信息。

###  **经过repairDatabase提升性能**
从db.stats()中能够看到几个跟碎片相关的关键字段，
>- dataSize，表示数据的大小，它包含了padding的空间；
>- storageSize，表示这些数据存储占用的空间，包含了dataSize和被删除数据所占空间，

    能够认为storageSize/dataSize就是磁盘碎片比例，当删除、update文档比较多后，它会变大，考虑作repairDatabase，以减小碎片让数据更紧凑。在实践中，这对提升CURD性能极其有用。
    repairDatabase时须要注意：它是把数据拷贝到新的地方，而后再作处理，因此repair以前在DB目录所在磁盘须要预留一倍的空闲磁盘空间，若是你发现磁盘空间不足，能够中止服务，而后增长一块新磁盘，再执行实例级别的repair，并指定--repairpath为新磁盘路径，
    >mongod --dbpath /path/to/corrupt/data --repair --repairpath    /media/external-hd/data/db，实例的数据会拷贝到/media/external-hd/data/db上作处理。


###  **索引字段的长度不能大于1024字节**
索引字段的长度不能大于1024字节，不然shell下会有插入错误提示：
>"errmsg" : "insertDocument :: caused by :: 17280 Btree::insert: key too large to index”。

###  **config DB没法写入**
因config DB没法修改，只可读，致使drop、enablesharding失败：
config server 相关日志：2015-06-11T16:51:19.078+0800 [replmaster] local.oplog.$main Assertion failure isOk() src/mongo/db/storage/extent.h 80
mongos 相关日志： [LockPinger] warning: pinging failed for distributed lock pinger 'xxx:1234/xxx:1235:1433993544:1804289383'. : : caused by :: isOk()
这是同事遇到的问题，不肯定是什么操做引发的。重启、configdb作repair均没法解决。
最后经过dump、restore解决：（1）把旧configdb dump出来；（2）restore到新的configure server；（3）mongos采用新的configure server；（4）重启所有mongod。

###  **sort()方法的size限制**
当我对一个没有建索引的字段作find，而后作sort的时候，可能触发sort的size不超过32MB限制，例如：
>db.stotal.find({}).sort({'type':-1})
Error: error: {
        "$err" : "Executor error: Overflow sort stage buffered data usage of 33554493 bytes exceeds internal limit of 33554432 bytes",
        "code" : 17144
}
    
    有两种解决方法：
解决方法一：对须要排序的字段建索引 db.stotal.ensureIndex({'type': -1})
解决方法二：修改默认配置，把sort时能够用的内存设置大点：
>db.adminCommand({setParameter:1, internalQueryExecMaxBlockingSortBytes:335544320})

    这两种解决方法各有利弊：（1）增长了索引会致使数据写入变慢，存储占用变多；（2）不建索引修改默认配置，会致使sort的时候占用更多的内存。