您好,登錄后才能下訂單哦!
這篇文章給大家介紹怎么進行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進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。