ホームページ >データベース >mysql チュートリアル >研究了这么久的MongoDB,我也来吐下槽。
MongoDB做为一款NOSQL数据库,在刚接触它的时候,被它的性能深深的吸引了。在一四核,4G内存的centos虚拟机上,插入了500W每条大小200byte的数据。发现它的写性能太令我震惊了。在不做索引的情况下,前一百万条,只用了二分钟就插完了,这只是我WIN7上的一台
MongoDB做为一款NOSQL数据库,在刚接触它的时候,被它的性能深深的吸引了。在一四核,4G内存的centos虚拟机上,插入了500W每条大小200byte的数据。发现它的写性能太令我震惊了。在不做索引的情况下,前一百万条,只用了二分钟就插完了,这只是我WIN7上的一台虚拟机,WIN7执行插入操作。在先建索引的情况下,再插入了一百万条,只是比没有索引的情况下,慢了20秒。但发现它对磁盘的占用,有点超出了我的估计!它占用的磁盘空间太大,而实际上数据大小没有这么大。磁盘占用大小差不多是数据的三倍。
插完数据后,进行了一些读取操作。性能还是非常可观的,查询都是MS秒级的。欣喜之余,接着再插数据。坑爹的事情就发生了。32位的mongodb最大一块文件块是512M,当512M有存储空间用完时,再插数据会先划出512M的数据块。当内存被大量占用后,发现它的插入数据,变龟速了。特别是在开辟一块新的存储空间时,完全阻塞了。Mongo在内存足够的情况下,开始插入的数据能达到6000条/秒,到内存不足后,速度瞬间降到了200条/秒,如果内存进一步退化,索引比数据量大的话,香港空间,有可能完全阻塞。
换到64位的MongoDB测试,发现他的内存充足的情况下,比32位的插入100W条速度要快到十几秒。而且64位的MongoDB,他最大的一块存储是2G的数据块。当内存不足的情况下,哥哭了~~~,绝大部分时间在阻塞。速度降到你不能忍受。关闭MongoDB,重启centos后,再接着插入,在将部分MongoDB的数据加载进内存后,又非常快了,插入速度几M/秒。好景不长,当2G的数据块用完后,再开辟一块2G的数据块时,发现MongoDB占用的内存瞬间升高,写入速度直线下降,直至阻塞。我怀疑MongoDB在开辟了那2G的空间后,同时在内存中开辟了一块2G的内存,由于当时内存不足(发现SWAP中的虚拟内存也占用过高),所以产生了阻塞情况。MongoDB可能是内存映射写入方式,所以它在内存足够的情况下,写入速度非常快。建议实际生产环境中,如果数据量大的话,给它多留点内存吧,MongoDB绝对是吃内存的老虎。
之后重启centos,内存又降下来了,MongoDB中已经存储了500万条数据了,再进行有索引查询,发现MongoDB在数据在冷的情况下,响应很慢,多执行几次查询预热后,性能才能回升,直至像刚插入时再查询那样。500万条数据查询,返回1000行数据内的,有索引情况下,查询时间是几十MS,然后继续测试了各种复杂查询。执行下面一条语句后,哥泪牛满面了
db.jqueue.find({"$or":[{"Name":"janson7"},{"Age":{"$in":[1,2,3]}}]}).sort({"_id":-1}).explain() { "cursor" : "BtreeCursor _Name_ reverse", "isMultiKey" : false, "n" : 301, "nscannedObjects" : 5000000, "nscanned" : 5000000, "nscannedObjectsAllPlans" : 5000000, "nscannedAllPlans" : 5000000, "scanAndOrder" : false, "indexOnly" : false, "nYields" : 0, "nChunkSkips" : 0, "millis" : 50989, "indexBounds" : { "_id" : [ [ { "$maxElement" : 1 }, { "$minElement" : 1 } ] ] }, "server" : "localhost:27017" }
发现他全表遍历了一次,反复测试后,都是这样的情况,一去掉sort,后,就是直接读索引,或者把OR操作去掉,也是读索引。我认为,排序应该是在查询到的数据中进行排序的,也就是先去索引中找到了相应的项,再把项根据我的要求排序啊,不可能出现遍历表的情况。
然后经过了坚辛的百度和Google,终于找到了答案,原来这是MongoDB的一个Bug,从他一设计出来后,这个Bug就一直没解决过。
园子里这位兄台的文章里写了
它自已的官方上的反馈:https://jira.mongodb.org/browse/SERVER-1205 发现这个问题,从10年就有人提出了,直到现在,2.2.2版本了,都还没有解决。如果有要进行$or查询,再sort排序业务的兄弟,请三思,我们开始想用MongoDB,就是因为我们业务里面这个查询是一个非常频繁且关键的查询。
在倍受打击后,改变设计方法,改变业务模式,虚拟主机,我不再进行$or查询了,我直接用Capped Collection来做一个临时映射,通过Capped表中数据进行排序,分页偏移,再用ID去主表查询。
在使用Capped Collection时,又发现了坑爹的事。2.2之前的版本,Capped Collection是默认没有索引的,2.2后就默认加了_id,并做索引了.我用的是C#驱动,然后按照驱动说明方法,
var collectionOptions = CollectionOptions.SetCapped(true).SetMaxDocuments(1000).SetMaxSize(1000000).SetAutoIndexId(false);
建了一个Capped表,去MongoDB里面看,发现,他还是建了索引。头大了,又开始找资料,发现了官方提供的驱动版本是1.7版本以前的,网站空间,也就是说,这个版本有可能不会支持2.2的新功能,在2.2以前,Capped默认是不建索引的,2.2是默认建索引了。查找官方驱动源码,下载地址:https://github.com/mongodb/mongo-csharp-driver
Sets whether the collection is capped. CollectionOptionsBuilder SetCapped(bool value) { if (value) { _document[] = value; } else { _document.Remove(); } return this; }
发现他的源码是这样写的,因为早期版本默认情况下是不建索引的,所以,如果 SetCapped传入的参数是false的话,他就直接执行了_document.Remove("capped");这一句,直接把这个参数选项从CollectionOptions项中删除了,没有带这个参数传入至数据库,而默认情况下,它是要建索引的,也就是说,在这个驱动版本,你是怎么样做Capped都会给你建索引,最后没办法,只好改了他的源码
Sets whether the collection is capped. CollectionOptionsBuilder SetCapped(bool value) { _document.Remove(); }
让它不管输入什么参数,这项都得输入,然后再执行时 ,发现MongoDB里面的Capped就没有建索引了。