您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關如何優化Mongodb 數據庫,文章內容質量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關知識有一定的了解。
在項目設計階段,明確集合的用途是對性能調優非常重要的一步。
從性能優化的角度來看,集合的設計我們需要考慮的是集合中數據的常用操作,例如我們需要設計一個日志(log)集合,日志的查看頻率不高,但寫入頻率卻很高,那么我們就可以得到這個集合中常用的操作是更新(增刪改)。如果我們要保存的是城市列表呢?顯而易見,這個集合是一個查看頻率很高,但寫入頻率很低的集合,那么常用的操作就是查詢。
對于頻繁更新和頻繁查詢的集合,我們最需要關注的重點是他們的范式化程度,假設現在我們需要存儲一篇圖書及其作者,在MongoDB中的關聯就可以體現為以下幾種形式:
1.完全分離(范式化設計)
示例1:
View Code { "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ ObjectId("144b5d83041c7dca84416"), ObjectId("144b5d83041c7dca84418"), ObjectId("144b5d83041c7dca84420"), ] }
我們將作者(comment) 的id數組作為一個字段添加到了圖書中去。這樣的設計方式是在非關系型數據庫中常用的,也就是我們所說的范式化設計。在MongoDB中我們將與主鍵沒有直接關系的圖書單獨提取到另一個集合,用存儲主鍵的方式進行關聯查詢。當我們要查詢文章和評論時需要先查詢到所需的文章,再從文章中獲取評論id,最后用獲得的完整的文章及其評論。在這種情況下查詢性能顯然是不理想的。但當某位作者的信息需要修改時,范式化的維護優勢就凸顯出來了,我們無需考慮此作者關聯的圖書,直接進行修改此作者的字段即可。
2.完全內嵌(反范式化設計)
示例2:
View Code { "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ { "name" : "丁磊" "age" : 40, "nationality" : "china", }, { "name" : "馬云" "age" : 49, "nationality" : "china", }, { "name" : "張召忠" "age" : 59, "nationality" : "china", }, ] }
在這個示例中我們將作者的字段完全嵌入到了圖書中去,在查詢的時候直接查詢圖書即可獲得所對應作者的全部信息,但因一個作者可能有多本著作,當修改某位作者的信息時時,我們需要遍歷所有圖書以找到該作者,將其修改。
3.部分內嵌(折中方案)
示例3:
View Code { "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ { "_id" : ObjectId("144b5d83041c7dca84416"), "name" : "丁磊" }, { "_id" : ObjectId("144b5d83041c7dca84418"), "name" : "馬云" }, { "_id" : ObjectId("144b5d83041c7dca84420"), "name" : "張召忠" }, ] }
這次我們將作者字段中的最常用的一部分提取出來。當我們只需要獲得圖書和作者名時,無需再次進入作者集合進行查詢,僅在圖書集合查詢即可獲得。
這種方式是一種相對折中的方式,既保證了查詢效率,也保證的更新效率。但這樣的方式顯然要比前兩種較難以掌握,難點在于需要與實際業務進行結合來尋找合適的提取字段。如同示例3所述,名字顯然不是一個經常修改的字段,這樣的字段如果提取出來是沒問題的,但如果提取出來的字段是一個經常修改的字段(比如age)的話,我們依舊在更新這個字段時需要大范圍的尋找并依此進行更新。
關于如何優化Mongodb 數據庫就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。