这篇文章给大家介绍怎么进行MONGODB 查询,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。
惯了SQL 语句的开发人员,在使用MONGODB 的时候,很可能会误会这个数据库。 纠正三点
1 MONGODB 虽然是存储 JOSN 串,但不是你想怎样存就可以怎样存,虽然已经比传统数据库在处理数据的SCHEMA 上开放的多,但如果你真的开打发了,那MONGODB 数据库的归属性质,也的把你打回原形。
2 MONGODB 的查询语句虽然不如传统SQL语句,可以进行那么多的判断(刚刚更新,MONGO语句可以有IF THEN 在查询语句中,逆天了),转换,但数据库的本性使然,撰写MONGODB 的查询语句,也是要有点技巧,否则查询中可以让你等到天昏地暗,这不怪MONGODB ,这就要怪你不懂她的原理和秉性。
3 MONGODB 的使用也是有规范的,不是程序员想怎样就怎样,世间任何东西都有他的规律和属性,所以使用MONGO DB 自然也是要有规范的。
以下就从上面三个方面来让不清楚如何使用的MONGODB 的亲们,来熟悉一下。
ONE , MONGODB 没有数据库SCHEMA,每个collection 的document 我想怎么存就怎么存,上一个docuemnt 我可以存我的某个贷款的记录,下一个Document 我就可以存 还款的违约记录。
如果你问我,可以这样做吗,从MONGODB 的原理上,你可以,你当然可以,可我想问,MONGODB 的数据库属性,你是不是忘记了,她不是记事本,她是一个要供你插入可能比传统数据库多几十倍的数据,并且最终你要从这几千万,几十亿条的数据量里面过滤出你要几十条数据,你觉得你上面如此,每个DOCUMENT 毫无联系的存储方法,对你的系统有何帮助,不如你就用文本文件吧,那个更适合你。
MONGODB 的COLLECTION (表),是有表的含义的,一个MONGODB的表(collection)虽然可以让你的SCHEMA 没有任何的规律,但你心里要有谱,这个collection 应该有什么,他们这些由documentS 组成的 collection 对我未来的数据处理要起到什么样的作用。
这里就的谈谈,为什么有MONGODB 这样的数据库了,还的说,大数据量和微服务,以及敏捷开发。 试想如果你有一个项目,你不知道他有多少个字段,未来一年内要有多少字段的添加,和删减,并且你不知道这些字段命名,而且马上就要开始在目前的状态下,调试你的项目,并上线,你感觉如何, F打头的英文单词是不是想马上脱口而出。
STOP,MONGODB 可以帮助你快速的响应和处理这样的项目,但这不意味着MONGO DB 是这样项目的 垃圾场和背锅侠。 就是这样无厘头的项目和不能确定的表设计,让MONGODB 凸显而出。 (什么,没有这样的项目,你确定?)
另外微服务中的信息汇聚,如果你有这样一套MONGODB 帮助你将微服务中的多个组件的信息交流,集中化,透明化,这也不失为另一种使用的另辟蹊径,因为微服务中,信息传递和信息丢失,已经让你感到不爽,而MONGODB,算是一个你的管家,将这些信息都保存后,方便你用MONGODB 的语句进行查询,而不是在文件日志中,查来查去,并且速度那是相当快,us纳秒的速度,亿万级的数据量,当然这一切是集中在你能理解她的结构和使用方式,甚至你已经可以将MONGODB 作为BI 的基础数据库,将及乱又复杂的信息,通过套件的方式输出。(MONGO 支持BI自有套件)
如果英语是世界的通行的语句,JOSN 就是计算机程序中,消息传递的世界通用语句,各种消息可以通过通用的JOSN 格式,将你的数据从一个微服务的世界,传递到另一个世界,而不用在去理会是 WINDOWS系统,还是LINUX 系统,是JAVA 还是 .NET CORE 或者 PYTHON, GO 之类的,因为你只要符合JOSN 的格式存储的数据,计算机界的处理方式都可以,因为他是世界语。
而MONGO DB 具有强大的 处理JOSN 格式数据的能力,你可以利用各种MONGO DB 的语法,将JOSN 层层嵌套和数组都扒个精光,将你要的呈现在你的眼前。
STOP , 又扯远了。
下面的说说使用 MONGO DB 的语句如何查询出你要的信息,并且通过索引的方式来进行。 所以下面要谈两个问题, 1 查询的方式 2 索引的建立技巧(MONGODB 的查询也是博大精深,索引更是丰富多彩,能力有限,能讲多少就多少)
1 查询数据中,请注意,没有事务性,也就是没有多表关联这样的事情出现在MONGODB 中,你的注意力,只需要定位到你要查的 一张表上。
注:MONGODB 更新很快,有些在网上查到的语句,已经过时或不在能使用,对应的语句请查看你对应的版本。以下语句,均已 MONGODB 3.6 作为标准。
举个简单的例子,我们下面又一个 collection 下面有如下数据 2700百万(数据量比较少,凑后吧)
我们想通过filesource 和 filetype 两个属性,来查找匹配的数据,那我们有以下的一条查询语句可以做这件事。
db.dbmongolog2.find({"filesource":0,"filetype":"1"})
通过上面这条语句,数据很快就查出来了,(画外音:这么简单),当然不是,难度的一点点的来,饭的一口口的吃。
那么问题来了,我们查询MONGO DB 中的数据,如果仅仅只需要显示部分数据,而不需要全部将所有的数据显示,是否可以节省查询的时间。
YES 是的,和传统数据库的查询一样,你要展示那些数据就标识出,你要看那些,你不看的,一定不要让他SHOW出来。
这就是 MONGODB 查询规则 1
用那个字段,就显示那个字段,不用的别展示。 具体语句怎么写
db.dbmongolog2.find({"filesource":0,"filetype":"1"},{"_id":0,"filename":0,"createdate":0,"filetype":0,"filesource":0})
db.dbmongolog2.find({"filesource":0,"filetype":"1"})
那这样写的语句,在执行效率上有什么差别,这里做了比较,效率提高10%,由原来的0.020 秒,变为0.018秒,当然如果数据量再大,过滤的字段的大小在大,则速度会更快,这点可以说和传统数据库没有差别。
所以开发的DEVELOPER们,使用MONGODB ,一样不要把你不要的字段SHOW 出来,要禁止他。语法就是在后面加 {} 然后将字段名字后面 冒号加0 。
当然开发说,你这个不科学,MONGODB 每个DOCUEMNT (行),都不一样的情况下,我这样怎么干。
好干:那就只显示你要的字段不就完了
db.dbmongolog2.find({"filesource":0,"filetype":"1"},{"_id":1})
、
你只需要,将标识0的地方,标识为 1 即可,另外从截图也看出了,执行的时间,已经到了 0.08秒,快了 百分之60%。 所以这个规矩,你们是要知道的。
那我们继续,加大难度,现在我们认为,查询的时间还是过长,你(我一直宣称MONGODB 的查询速度可以达到 纳秒),那我们就来看看,MONGODB 查询继续加速。
索引,MONGODB 和传统数据库一样,是有索引的,而且索引的种类更多。
针对上面的查询,我们怎么来搞一下。
1 其实我们还是要知
db.dbmongolog2.find({"filesource":0,"filetype":"1"},{"_id":0,"filename":0,"createdate":0,"filetype":0,"filesource":0})
这个语句其实是在走全表扫描,这样是不OK 的,我们需要建立索引
(当然在建立索引前我们是应该,进行分析,索引建立的是否能更有效,索引建立的值得不值得,今天时间比较紧,暂不讨论,当然我们一般还是要建立采样率的分析),其实这个采样率来看,添加索引并不理想。但这里我们仅仅是演示,来建立一个索引。
db.dbmongolog2.createIndex({filesource:1,filetype:1},{name:"idx_dbmongolog2_filesource_filetype",background:true})
可以通过执行计划来验证,当前的查询已经可以走刚刚建立的索引了
但是别高兴的太早,如果把查询语句改写为
db.dbmongolog2.find({"filesource":0,"filetype":"1"},{"_id":0,"filename":0,"createdate":0,"filetype":0,"filesource":0}).sort({_id:1})
马上在看执行计划,已经不再走刚建好的索引了,走了OBJECT_ID 主键,当然执行的效率比全表扫描的效率还差。 这里我们到底做了什么,让MONGODB 不再走我们刚刚建立好的索引,答案就是 sort({_id:1})
所以一般查询语句,如果不需要排序,就不要使用排序,否则很可能你刚刚辛苦建立好的索引,就不在生效了。但如果必须要进行排序怎么办。
在重新建立了索引后,我们的查询速度又和飞一样了,看下图
db.dbmongolog2.createIndex({filesource:1,filetype:1,_id:-1},{name:"idx_dbmongolog2_filesource_filetype_id",background:true})
上面的建立索引的语句,请注意每个字段的后面的数字, 1是升序,-1是降序,尤其排序,如果经常降序,则就别把索引建立成升序。
讲完简单的查询和索引的建立,其实一个MONGODB 数据库的系统能顺畅建立,主要还要考虑你的collection,当然如果你仅仅将MONGODB 作为日志的系统,你可以考虑的更少。
但实际上,MONGODB 的collection 的确是可以做很多事,例如他可以轻松将传统数据库上的几个负载的 JOIN 操作,在一个collection就完成了,通过嵌套,将这些JOIN 就体现在一个 collection上,所以查询的速度会很快,是传统数据库望尘莫及的。缺点吗, 可能会损失空间,是一种用空间,换时间的方式。(MONGODB 的数据会自动压缩,进入就压缩,所以非要找点缺点,也的说点)。
下面在对表的查询和索引,在进一步,既然是晋级,
1 索引的建立技巧,我们继续看下面的查询语句,我们查询一个时间在2018年12月18日后的记录,并且filetype字段,是
db.dbmongolog2.find({"createdate":{$gte:ISODate("2018-12-18T17:39:43.207+08:00")},"filetype":1}
很明显查询已经走了全表扫描,不是建立了索引,为什么不可以了,我们换一种写法
db.dbmongolog2.find({"filetype":1,"createdate":{$gte:ISODate("2018-12-18T17:39:43.207+08:00")}},{"_id":1}).explain()
换一种写法,查看执行计划,还是不可以,还是全表扫描
这里总结一个MONGODB 的建立索引的规律
索引建立有技巧,可以先算采样率,分布离散字段放前边,符合字段索引,必查字段放前边,一个查询可以多个字段,多个索引,可以使用索引的交集(MYSQL中的INDEX MERGE的概念有点像),如何使用还要看优化引擎的选择。但如果一个复合索引能解决的,最好不要使用
所以一个MONGODB 看上去就是一个文档数据库,整体执行文件才百兆,但里面的东西,不比 ORACLE SQL SERVER 的知识少,也够喝一壶。
另外小小的MONGODB ,也可以做聚合,类似传统数据库的 GROUP BY HAVING SUM ,AVAGE 等运算,所以这个MONGODB 绝非善类,4.0开始支持事务,所以NO-SQL 数据库,哪天发力也不光抢光非关系的市场,连你关系型的市场,也要分一杯羹。
MONGODB的聚合操作
db.dbmongolog2.aggregate([{"$match":{"createdate":{$gte:ISODate("2018-12-18T17:39:43.207+08:00")}}},{$group:{_id:{filetype:"$filetype",filesource:"$filesource"},"count":{"$sum":1}}}]).explain()
关于怎么进行MONGODB 查询就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。