本文完成时MongoDB的最新版本为MongoDB 2.6

1、count统计结果错误

这是由于分布式集群正在迁移数据,它导致count结果值错误,需要使用aggregate pipeline来得到正确统计结果,例如:

db.collection.aggregate([{$group: {_id: null, count: {$sum: 1}}}])

引用:“On a sharded cluster, count can result in an inaccurate count if orphaned documents exist or if a chunk migration is in progress.”

参考:http://docs.mongodb.org/manual/reference/command/count/ 

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

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

参考:《MongoDB权威指南》第一版

3、restore数据到新DB时,不要去先建索引

把bson数据文件restore到另一个DB时,需要注意:不能先创建索引再restore数据,否则性能极差,mongorestore工具默认会在restore完数据时,根据dump出来的index信息创建索引,无须自己创建,如果是要更换索引,也应该在数据入库完之后再创建。

4、DB中的namespace数量太多导致无法创建新的collection

错误提示:error: hashtable namespace index max chain reached:1335,如何解决呢?
这是DB中的collection个数太多导致,在实践中以每个collection 8KB计算(跟官方文档里说的不同,可能跟index有关系),256MB可以支持36000个collection。db.system.namespaces.count() 命令可以统计当前DB内的collection数目,DB可支持collection数量是由于nssize参数指定的,它指定了dbname.ns磁盘文件的大小,也就指定了DB可支持的最大collection数目,ns为namespace缩写。默认nssize为16MB。
如果重启MongoD并修改了nssize参数,这新nssize只会对新加入的DB生效,对以前已经存在的DB不生效,如果你想对已经存在的DB采用新的nssize,必须在加大nssize重启之后新建DB,然后把旧DB的collection 复制到新DB中。
namespace限制相关文档:http://docs.mongodb.org/manual/reference/limits/#Number-of-Namespaces

5、moveChunk因旧数据未删除而失败

错误日志:”moveChunk failed to engage TO-shard in the data transfer: can't accept new chunks because there are still 1 deletes from previous migration“。
意思是说,当前正要去接受新chunk 的shard正在删除上一次数据迁移出的数据,不能接受新Chunk,于是本次迁移失败。这种log里显示的是warning,但有时候会发现shard的删除持续了十几天都没完成,查看日志,可以发现同一个chunk的删除在不断重复执行,重启所有无法接受新chunk的shard可以解决这个问题。
参考:
http://stackoverflow.com/questions/26640861/movechunk-failed-to-engage-to-shard-in-the-data-transfer-cant-accept-new-chunk
如果采用了balancer自动均衡,那么可以加上_waitForDelete参数,如:
{ "_id" : "balancer", "activeWindow" : { "start" : "12:00", "stop" : "19:30" }, "stopped" : false, "_waitForDelete" : true }
,这样就不会因delete堆积而导致后续migrate失败,当然,需要考虑到这里的阻塞是否会影响到程序正常运转,在实践中慎重采用使用waitForDelete,因为发现加上它之后迁移性能非常差,可能出现卡住十几个小时的情况,外界拿住了被迁移chunk的游标句柄,这时候删除不能执行,阻塞了后续其它迁移操作。
游标被打开而导致被迁移数据无法及时删除时的日志:
2015-03-07T10:21:20.118+0800 [RangeDeleter] rangeDeleter waiting for open cursors in: cswuyg_test.cswuyg_test, min: { _id: -6665031702664277348 }, max: { _id: -6651575076051867067 }, elapsedSecs: 6131244, cursors: [ 220477635588 ]
这可能会卡住几十小时,甚至一直卡住,影响后续的moveChunk操作,导致数据不均衡。
解决方法还是:重启。

6、bson size不能超过16MB的限制

单个文档的BSON size不能超过16MB。find查询有时会遇到16MB的限制,譬如使用$in 查询的时候,in中的数组元素不能太多。对一些特殊的数据源做MapReduce,MapReduce中间会将数据组合为“KEY:[VALUE1、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.

7、批量插入

批量插入可以减少数据往服务器的提交次数,提高性能,一般批量提交的BSON size不超过48MB,如果超过了,驱动程序自动修改为往mongos的多次提交。

8、安全写入介绍及其沿革

关键字: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表示安全写入到多少个副本集才返回。
参考:
http://docs.mongodb.org/manual/release-notes/drivers-write-concern/
http://docs.mongodb.org/manual/core/write-concern/
http://blog.mongodirector.com/understanding-durability-write-safety-in-mongodb/
http://whyjava.wordpress.com/2011/12/08/how-mongodb-different-write-concern-values-affect-performance-on-a-single-node/

9、善用索引——可能跟你以为的不一样

使用组合索引的时候,如果有两组索引,在限量查询的情况下,可能跟常规的认识不同:
利用组合索引做的查询,在不同数量级下会有不同性能:
组合索引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索引,在大多数应用上执行得很好。
参考:《MongoDB——The Definitive Guide 2nd Edition》page89

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

做find的时候,并不要求索引一定要在前面,
譬如:
db.test集合中对R有索引
db.test.find({R:"AA", "H": "BB"}).limit(100).explain()
db.test.find({"H":"BB", "R" : "AA"}).limit(100).explain()
这两个查找性能一样,它都会使用R索引。

11、使用组合索引做shard key可以大幅度提高集群性能

“固定值+增量值” 两字段做组合索引可以有效的实现分布式集群中的分散多热点写入、读取。以下为读书笔记:
在单个MongoDB实例上,最高效的写入是顺序写入,而MongoDB集群则要求写入能随机,以便平均分散到多个MongoDB实例。所以最高效的写入是有多个局部热点:在多个MongoDB实例之间是分散写入,在实例内部是顺序写入。 要实现这一点,我们采用组合索引。
例如:shardkey的第一部分是很粗糙的,可选集很少的字段,索引的第二部分是递增字段,当数据增加到一定程度时,会出现很多第一部分相同第二部分不同的chunk,数据只会在最后一个chunk里写入数据,当第一部分不同的chunk分散在多个shard上,就实现了多热点的写入。如果在一个shard上,不止一个chunk可以写入数据,那也就是说不止一个热点,当热点非常多的时候,也就等同于无热点的随机写入。当一个chunk分裂之后,只能有一个成为热点,另一个不能再被写入,否则就会产生两个热点,不再写入的chunk也就是死掉了,后续只会对它有读操作。

最典型的应用是具有日期属性的日志处理,shard key选择“日期+用户ID”组合,保证了数据写入时的局部热点(一个shard上只有少数几个chunk被写入,避免随机IO)和全局分散(所有的shard上都有写入数据,充分利用磁盘IO)。
我在实践中除了书中讲到的组合键方式外,还加上了预分片策略,避免了早期数据增长过程中的分片和数据迁移。另外还尽可能的制造能利用局部性原理的数据写入,例如在数据写入之前先对数据排序,有大约30%左右的update性能提升。

预分片是这样子做的:根据组合shardkey信息先分裂好chunk,把这些空chunk移动到各个shard上,避免了后续自动分裂引起的数据迁移。

good case:

环境:一台机器、7分片、MongoDB2.6版本、shard key选择“日期+用户ID组合”,

数据:写入使用批量插入,对10亿条日志级分片集群的写入,写入1000W条日志只需要35分钟,每条日志约0.11K。

bad case:

环境:3台机器、18分片、MongoDB2.6版本、shard key选择 _id的hashid

数据:写入采用批量插入,对3亿条日志级分片集群的写入,写入300W条日志耗时35分钟,每条日志约0.11K。

从对比可以看到,在数据量比较大的情况下选择组合索引做shard key性能明显优于选择hashid。

我在实际应用中还遇到选择hashid的更极端情况:对3条机器&18分片&3亿条日志集群每天写入300W条日志,耗时170分钟,每条日志约4K。每次写入数据时,所有分片磁盘IO使用率都达到100%。

附创建组合索引和使用组合索引做shard key 的 mongo shell代码:

xx> db.cswuyg.ensureIndex({'code':1, 'insert_time':1})

xx> use admin

admin> db.runCommand({"enablesharding":"xx"})

admin> db.runCommand({"shardcollection":"xx.cswuyg","key":{'code':1, 'insert_time':1}})

 

参考:《MongoDB——The Definitive Guide 2nd Edition》 page268

12、怎么建索引更能提高查询性能?

在查询时,索引是否高效,要注意它的cardinality(cardinality越高表示该键可选择的值越多),在组合索引中,让cardinality高的放在前面。注意这里跟分布式环境选择shard key的不同。以下为读书笔记:
index cardinality(索引散列程度),表示的是一个索引所对应到的值的多少,散列程度越低,则一个索引对应的值越多,索引效果越差:在使用索引时,高散列程度的索引可以更多的排除不符合条件的文档,让后续的比较在一个更小的集合中执行,这更高效。所以一般选择高散列程度的键做索引,或者在组合索引中,把高散列程度的键放在前面。
参考:《MongoDB——The Definitive Guide 2nd Edition》 page98

13、非原地update,性能会很差

update文档时,如果新文档的空间占用大于旧文档加上它周围padding的空间,那么就会放弃原来的位置,把数据拷贝到新空间。
参考:《MongoDB——The Definitive Guide 2nd Edition》 page43

14、无法在索引建立之后再去增加索引的过期时间

如果索引建立指定了过期时间,后续要update过期时间可以这样子:db.runCommand({"collMod":"a", index:{keyPattern:{"_":-1}, expireAfterSeconds: 60}})。

注意,通过collMod能修改过期时间的前提是:这个索引有过期时间,如果这个索引之前没有设置过期时间,那么无法update,只能删了索引,重建索引并指定过期时间。
参考:http://docs.mongodb.org/manual/tutorial/expire-data/

15、_id索引无法删除

参考:《MongoDB——The Definitive Guide 2nd Edition》 page114

16、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掉它。

参考:
http://docs.mongodb.org/v2.4/core/record-padding/
http://docs.mongodb.org/v2.4/faq/developers/#faq-developers-manual-padding

17、usePowerOf2Size是什么

这是为更有效的复用磁盘空间而设置的参数:分配的磁盘空间是2的倍数,如果超过了4MB,则是距离计算值最近的且大于它的完整MB数。
可以通过db.collections.stats()看到该值“userFlags”。
MongoDB2.6之后默认开启usePowerOf2Size参数
使用后的效果可以看这里的PPT:http://www.slideshare.net/mongodb/use-powerof2sizes-27300759

18、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的。
附错误码信息:
https://github.com/mongodb/mongo/blob/master/src/mongo/s/commands_public.cpp#L778
uassert(13140, "Don't recognize source or target DB", confFrom && confTo);
uassert(13138, "You can't rename a sharded collection", !confFrom->isSharded(fullnsFrom));
uassert(13139, "You can't rename to a sharded collection", !confTo->isSharded(fullnsTo));
uassert(13137, "Source and destination collections must be on same shard", shardFrom == shardTo);
参考:http://docs.mongodb.org/manual/reference/method/db.collection.mapReduce/#mapreduce-out-mtd

19、杀掉MongoD进程的几种方式

1)进入到MongoD的命令行模式执行shutdown,
eg: 
$ mongo --port 10001
> use admin
> db.shutdownServer()
2)1方式的简化:
eg:mongo admin --port 10001 --eval "db.shutdownServer()"
3)使用MongoD命令行关闭,需要指定db路径:
mongod --dbpath ./data/db --shutdown

20、集群的shard key慎重采用hash

如果你的日志是有日期属性的,那么shard key不要使用hash,否则删除过期日志时无法成块删除;在更新日志的时候,也不能利用局部性原理,查找、更新、插入数据都会因此而变慢。一般来说,hash id应付小数据量时压力不大,但在数据量较大(热数据大于可用内存容量)时,CRUD性能极差,且会放大碎片对性能的影响:数据非常分散,当有过期日志被删除后,这些删除后的空间成为碎片,可能会因为磁盘预读策略被加载到内存中。另外,采用hash shard key还会浪费掉一个索引,浪费不少空间。

21、副本数也不用太多

如果你的副本数量超过了12个(MongoDB3.0.0超过了50个),那么就要选择使用 master-slave ,但这样会失去故障自恢复功能,主节点故障时,需要手动去切换到无故障节点。

22、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。
参考:http://stackoverflow.com/questions/21226255/where-is-the-mongos-config-database-string-being-stored

23、shard key的选择跟update性能紧密关联

分布式MongoDB,shard key的选择跟update性能,甚至是update可用性有很大关系,需要注意。
1、在对文档个别字段update时,如果query部分没有带上shard key,性能会很差,因为mongos需要把这条update语句派发给所有的shard 实例。
2、当update 的upsert参数为true时,query部分必须带上 shard key,否则语句执行出错,例子:
mongos> 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下执行才能看到错误信息。

附:
以下英文部分来自:https://jira.mongodb.org/browse/SERVER-13010
It's actually not clear to me that this is something we can support - problem is this:
> db.coll.update({ _id : 1 }, { }, true);
> db.coll.find()
{ "_id" : ObjectId("53176700a2bc4d46c176f14a") }
Upserts generate new _ids in response to this operation, and therefore we can't actually target this correctly in a sharded environment. The shard on which we need to perform the query may not be the shard on which the new _id is placed.
意思是说,upsert产生了新的_id,_id就是shard key,但是如果query里没有shard key,它们不知道要到哪个shard上执行这个命令,upsert产生的shard key可能并不是执行这条命令的shard的。
另外,如果_id不是shard key我们的例子也是不能成功的,因为没有shard key,这条upsert要在哪个shard上执行呢?不能像普通update那样给所有的shard去做,否则可能导致插入多条。
参考:
https://jira.mongodb.org/browse/SERVER-13010
http://docs.mongodb.org/manual/core/sharding-shard-key/
http://stackoverflow.com/questions/17190246/which-of-the-following-statements-are-true-about-choosing-and-using-a-shard-key

24、通过repairDatabase提高性能

从db.stats()中可以看到几个跟碎片相关的关键字段,dataSize,表示数据的大小,它包含了padding的空间;storageSize,表示这些数据存储占用的空间,包含了dataSize和被删除数据所占空间,可以认为storageSize/dataSize就是磁盘碎片比例,当删除、update文档比较多后,它会变大,考虑做repairDatabase,以减少碎片让数据更紧凑,在实践中,这对提高CURD性能极其有用。repairDatabase时需要注意:它是把数据拷贝到新的地方,然后再做处理,所以repair之前在DB目录所在磁盘需要预留一倍的空闲磁盘空间,如果你发现磁盘空间不足,可以停止服务,然后增加一块新磁盘,再执行实例级别的repair,并指定--repairpath为新磁盘路径,eg:mongod --dbpath /path/to/corrupt/data --repair --repairpath /media/external-hd/data/db,实例的数据会拷贝到/media/external-hd/data/db上做处理。

参考:《MongoDB——The Definitive Guide 2nd Edition》page325

25、索引字段的长度不能大于1024字节

索引字段的长度不能大于1024字节,否则shell下会有插入错误提示:"errmsg" : "insertDocument :: caused by :: 17280 Btree::insert: key too large to index”。 使用pymongo的“continue_on_error”参数,不会发出错误提示,要注意。 参考:http://docs.mongodb.org/manual/reference/limits/#Index-Key-Limit

26、修改索引的expireAfterSeconds之后,负载均衡失败

修改索引的expireAfterSeconds之后,负载均衡失败,出现错误提示“2015-06-05T09:59:49.056+0800 [migrateThread] warning: failed to create index before migrating data.  idx: { v: 1, key: { _: -1 }, name: "__-1", ns: "cswuyg_test.cswuyg_test", expireAfterSeconds: 5227200 } error: IndexOptionsConflict Index with name: __-1 already exists with different options 检查发生moveChunk的两个shard,并没有发现不一致,怀疑存在缓存,重启所有shard解决。

27、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。

28、sort()方法的size限制

当我对一个没有建索引的字段做find,然后做sort的时候,可能触发sort的size的32MB限制,例如:

cswuyg> 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时可以用的内存设置大点:cswuyg> db.adminCommand({setParameter:1, internalQueryExecMaxBlockingSortBytes:335544320})
参考:http://askubuntu.com/questions/501937/how-to-increase-buffered-data-limit
这两种解决方法各有利弊:(1)增加了索引会导致数据写入变慢,存储占用变多;(2)不建索引修改默认配置,会导致sort的时候占用更多的内存。

标签:
MongoDB,使用小结

免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com

P70系列延期,华为新旗舰将在下月发布

3月20日消息,近期博主@数码闲聊站 透露,原定三月份发布的华为新旗舰P70系列延期发布,预计4月份上市。

而博主@定焦数码 爆料,华为的P70系列在定位上已经超过了Mate60,成为了重要的旗舰系列之一。它肩负着重返影像领域顶尖的使命。那么这次P70会带来哪些令人惊艳的创新呢?

根据目前爆料的消息来看,华为P70系列将推出三个版本,其中P70和P70 Pro采用了三角形的摄像头模组设计,而P70 Art则采用了与上一代P60 Art相似的不规则形状设计。这样的外观是否好看见仁见智,但辨识度绝对拉满。