您好,登錄后才能下訂單哦!
小編給大家分享一下關于mongodb數據庫的使用方法,希望大家閱讀完這篇文章后大所收獲,下面讓我們一起去探討吧!
mongodb眾所周知不支持事務,所以需要強事務的業務根本不能考慮mongodb。
mongodb的優勢就是文檔存儲:
1. 業務經常變動,需要不時的添加字段,那么mongodb比較適合,關系型數據庫添加字段的復雜度也還好
2. 嵌套文檔,業務數據比較復雜,適合嵌套文檔式存儲,那么mongodb非常合適,這個關系型數據庫比較難搞,雖然MySQL和pg也有文檔存儲,但MySQL的不成熟,pg畢竟現在生產中使用還是偏少,個人也不了解,這里不談。但這不僅僅這一點優勢,具體下面會細說。
3. upsert支持,查詢速度也不慢
4. 高可用的副本集支持
5. 查詢語法非常豐富,嵌套文檔查詢功能非常強大,不是重度用戶可能不能理解
下面說說一個具體的使用事例:
項目的一條數據在10kb左右,如果使用關系型數據庫那么需要將這條數據拆分成大概幾百條左右,建造多個表,設計較復雜,這種數據大概在一百萬條左右,想想拆分后在十幾億的數據量就可怕。打平后的數據什么DB也都可以拿下,只是一百萬變十幾億比較恐怖而已。
如果采用MySQL存儲,每次查詢需要使用外鍵查詢多個表,從這些表中拉取數據,性能肯定要下降很多,比不上只在一個表查詢,而且只拉取少兩個數量級的數據。查詢也還好,業務允許可以對結果做緩存,放到redis里去。
但是重點來了,需求要增量更新部分數據,這時候需要更新多個表,根本沒法做到原子性(注意事務不是原子操作),當然也可以使用cas等技術補償,達到最終一致性。但使用mongodb存儲只需要update一條數據,對相應的嵌套文檔中內容更新,可以做到原子性,是不是很方便?
具體說說該項目的難點,查詢無法使用緩存,可能會很吃驚,但是業務決定了確實做不了,而且增量更新的量達到上萬的QPS,如果不能保證原子性想想多么可怕!
所以mongodb在這里幫了大忙,關系型數據庫解決不了這個難題。
有人可能要問,mongodb沒有事務,上游數據寫入也會有問題,你不可能所有數據都存一個表吧?
當然不是的,我們mongodb里的數據是從MySQL中清洗出來存到mongodb中的,mongodb只做單點的業務需求,綜合的數據還是在MySQL中。
此項目我們用了上百個副本集,保證系統的高可用,這些副本集配置只要一條shell就搞定,如果用MySQL的主從不知道怎么配(我自己不懂),估計DBA得忙死,而該項目完全不需要也沒用到DBA。
說了這么多mongo的優點,也說說他的缺點:
1. 查詢優化器和MySQL沒法比
2. 不支持reload,只能冷重啟,初始化配置的時候比較麻煩
3. 沒有事務,不敢存儲第一手數據,多用來做備份數據的存儲
mongodb可以做很多事情,取決于你腦洞,性能不差,存一些相對不重要的數據,mongodb嵌套文檔功能強大,多看看官方文檔挖掘挖掘有用信息,每次都能發現驚喜。
看完了這篇文章,相信你對關于mongodb數據庫的使用方法有了一定的了解,想了解更多相關知識,歡迎關注億速云行業資訊頻道,感謝各位的閱讀!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。