-
1 # 老顧聊技術
-
2 # 極客宇文氏
剛好最近接觸的專案是一個商城專案並且使用了MongoDB資料庫。
該商城系統使用MongoDB的目的是儲存大量的商品資訊,並且結合了搜尋引擎lucene,以便於維護商品資訊和進行查詢。
說明商城系統使用MongoDB不是稀奇的事情。
一分鐘了解MongoDBMongoDB最大的特點是與MySQL等關係型資料庫不同的是,他是基於分散式檔案儲存的資料庫。它的儲存的資料格式是最接近自然最面向物件的Json格式。
最重要的是,MongoDB,不支援複雜事務和連表查詢。
請注意這一點也就意味著MongoDB的適用場景是有一定侷限性的,如果你想要複雜連表查詢和事務,那麼MongoDB將做不到。
如果你是想維護單表資訊並且做頻繁得更新和查詢,而且資料量增長指數很嚇人,MongoDB非常適合。
宇文氏建議:
這也就意味著如果MongoDB用於電商系統,那麼很可能作為其中的一個數據儲存部分,多半會和MySQL等資料庫聯合使用。
-
3 # 小小CTO
效能不如mysql,唯一的好處就分散式方便,只能用來做日誌系統,計算用的大資料儲存。要不還是乖乖用MySQL吧,一個稍微複雜點的查詢效能可以比mysql慢十多倍。 另外一點好處就是寫入特快,不會因為單表資料越來越多就越來越慢。只合適做低頻查詢的資料儲存
-
4 # 會點程式碼的大叔
個人認為,MongoDB不太適合用作商城APP的資料庫:
能用是肯定能用的,但是不適合,開發過程中需要解決的問題會比較多且嚴峻;
單獨只使用MongoDB是不適合的,可以用它解決一部分的問題,也就是關係型資料庫和MongoDB配合著使用。
MongoDB是什麼,以及它的優點概括地說一下MongoDB是什麼:它是一個基於分散式檔案儲存的非關係型資料庫;我們常見的MySQL、Oracle都是關係型資料庫,資料在關係型資料庫中都是通過表的格式展現,可以看做二維表格;而MongoDB中的資料,類似於JSON格式(BSON)。
MongoDB除了效能上的優勢之外,我認為最大的優點就是資料模式自由,如果你願意的話,可以將任何資料都儲存到同一張表中(MongoDB中叫做Collection,等同於關係型資料庫中的Table);
比如像這樣,一條客戶資訊,一條產品資訊,兩條毫無交集的資料,可以儲存到同一個Collection中(比較極端的做法,實際使用的時候還是要區分開):
為什麼說MongoDB不太適合用作商城應用的資料庫首先,商城應用對事務一致性要求非常高,而MongoDB在事務的支援上,比較晚熟;MongoDB在3.0左右的版本,開始支援單文件的事務,到了4.0以上的版本,開始支援多文件事務;MongoDB發展的越來越好,但是在事務支援上,和關係型資料庫相比確實還是有差距。
第二,通常商城相關的業務,表結構相對都是比較成熟且固定的,比如客戶表、商品表、訂單表、支付表等等,同一個維度的資料結構基本都是相同的,比如客戶都會有姓名、手機號、收貨地址,這並沒有發揮MongoDB資料結構自由的優勢,關係型資料庫已經可以很好地支撐。
第三,MongoDB在多表關聯方面,優勢不大,比如需要查詢客戶下面所有的訂單,那麼可能需要關聯客戶表和訂單表;而讓MongoDB來實現,訂單可以作為客戶下面的一個子文件來儲存,大概就是這個樣子:
總結來說,MongoDB更多適用於大資料量、高併發、弱事務、資料結構“隨意”且“善變”的場景,是對關係型資料庫的補充。
-
5 # IT我的小熊不見了丶
首先,mongdb一個最大的缺點就是不能進行多表聯合查詢,也就是說像mysql等關係型資料庫裡面的join語法在mongdb是不存在的。所以說如果你想要的資料確保在一張表裡就能查出來就還好,如果涉及到多表的話難道你想用各種for迴圈去實現表的聯合查詢嗎?
而實際上商城系統還是比較複雜的,業務不可能用一張表來表達,肯定會涉及到多表查詢,因此mongdb可以用在商城系統中的一環,但是不能用於全部。
回覆列表
這個問題要看是什麼樣的商城?如果是作者可以小東西,商城非常簡單,那還是可以的。現在比較火的前後端分離,以及全棧工程師,從前端寫到後端,老顧看到有些視訊和文章就是用MongoDB作為資料庫進行開發的。
因地制宜真實已經運營上線的商城系統是比較複雜的,設計到的技術點也是比較多的。好的系統不會只選擇一種方案,而是遇到什麼業務場景,選擇不同的方案。
持久化方案我們這裡溝通一下持久化方案。小夥伴們經常掛到嘴邊的資料庫其實就是一種持久化方案,把資料儲存到磁碟上面。經常用到的產品如:oracle,mysql,MongoDB,elasticsearch,hdfs,甚至redis都是。
不同的持久化產品有不同的特性,mongoDB採用的是kv儲存的方式,高效能,天生支援分散式,常常是用來做資料分析的。他的弱點就是關聯查詢就比較麻煩。
而傳統的mysql資料庫關聯查詢就比較方便,但效能不高,搭建叢集也比較麻煩。
總結:要看具體的業務場景,選擇不同的持久化方案;不能脫離了業務,脫離業務就是耍流氓了。