首先，mongdb一個最大的缺點就是不能進行多表聯合查詢，也就是說像mysql等關係型資料庫裡面的join語法在mongdb是不存在的。所以說如果你想要的資料確保在一張表裡就能查出來就還好，如果涉及到多表的話難道你想用各種for迴圈去實現表的聯合查詢嗎？

而實際上商城系統還是比較複雜的，業務不可能用一張表來表達，肯定會涉及到多表查詢，因此mongdb可以用在商城系統中的一環，但是不能用於全部。

這個問題要看是什麼樣的商城？如果是作者可以小東西，商城非常簡單，那還是可以的。現在比較火的前後端分離，以及全棧工程師，從前端寫到後端，老顧看到有些影片和文章就是用MongoDB作為資料庫進行開發的。

真實已經運營上線的商城系統是比較複雜的，設計到的技術點也是比較多的。好的系統不會只選擇一種方案，而是遇到什麼業務場景，選擇不同的方案。

我們這裡溝通一下持久化方案。小夥伴們經常掛到嘴邊的資料庫其實就是一種持久化方案，把資料儲存到磁碟上面。經常用到的產品如：oracle，mysql，MongoDB，elasticsearch，hdfs，甚至redis都是。

不同的持久化產品有不同的特性，mongoDB採用的是kv儲存的方式，高效能，天生支援分散式，常常是用來做資料分析的。他的弱點就是關聯查詢就比較麻煩。

而傳統的mysql資料庫關聯查詢就比較方便，但效能不高，搭建叢集也比較麻煩。

總結：要看具體的業務場景，選擇不同的持久化方案；不能脫離了業務，脫離業務就是耍流氓了。

剛好最近接觸的專案是一個商城專案並且使用了MongoDB資料庫。

該商城系統使用MongoDB的目的是儲存大量的商品資訊，並且結合了搜尋引擎lucene，以便於維護商品資訊和進行查詢。

說明商城系統使用MongoDB不是稀奇的事情。

MongoDB最大的特點是與MySQL等關係型資料庫不同的是，他是基於分散式檔案儲存的資料庫。它的儲存的資料格式是最接近自然最面向物件的Json格式。

最重要的是，MongoDB，不支援複雜事務和連表查詢。

請注意這一點也就意味著MongoDB的適用場景是有一定侷限性的，如果你想要複雜連表查詢和事務，那麼MongoDB將做不到。

如果你是想維護單表資訊並且做頻繁得更新和查詢，而且資料量增長指數很嚇人，MongoDB非常適合。

宇文氏建議:

這也就意味著如果MongoDB用於電商系統，那麼很可能作為其中的一個數據儲存部分，多半會和MySQL等資料庫聯合使用。

個人認為，MongoDB不太適合用作商城APP的資料庫：

能用是肯定能用的，但是不適合，開發過程中需要解決的問題會比較多且嚴峻；

單獨只使用MongoDB是不適合的，可以用它解決一部分的問題，也就是關係型資料庫和MongoDB配合著使用。

概括地說一下MongoDB是什麼：它是一個基於分散式檔案儲存的非關係型資料庫；我們常見的MySQL、Oracle都是關係型資料庫，資料在關係型資料庫中都是透過表的格式展現，可以看做二維表格；而MongoDB中的資料，類似於JSON格式（BSON）。

MongoDB除了效能上的優勢之外，我認為最大的優點就是資料模式自由，如果你願意的話，可以將任何資料都儲存到同一張表中（MongoDB中叫做Collection，等同於關係型資料庫中的Table）；

比如像這樣，一條客戶資訊，一條產品資訊，兩條毫無交集的資料，可以儲存到同一個Collection中（比較極端的做法，實際使用的時候還是要區分開）：

首先，商城應用對事務一致性要求非常高，而MongoDB在事務的支援上，比較晚熟；MongoDB在3.0左右的版本，開始支援單文件的事務，到了4.0以上的版本，開始支援多文件事務；MongoDB發展的越來越好，但是在事務支援上，和關係型資料庫相比確實還是有差距。

第二，通常商城相關的業務，表結構相對都是比較成熟且固定的，比如客戶表、商品表、訂單表、支付表等等，同一個維度的資料結構基本都是相同的，比如客戶都會有姓名、手機號、收貨地址，這並沒有發揮MongoDB資料結構自由的優勢，關係型資料庫已經可以很好地支撐。

第三，MongoDB在多表關聯方面，優勢不大，比如需要查詢客戶下面所有的訂單，那麼可能需要關聯客戶表和訂單表；而讓MongoDB來實現，訂單可以作為客戶下面的一個子文件來儲存，大概就是這個樣子：

總結來說，MongoDB更多適用於大資料量、高併發、弱事務、資料結構“隨意”且“善變”的場景，是對關係型資料庫的補充。

非常不推薦，mongo的話是文件型非關係型資料庫，弱化了物件的概念，像這種大型的系統還是推薦mysql這種關係型資料庫，mongo的話，你在使用的過程中，維護這些表的相互關係，時間上會花掉更多的時間。

記憶體老虎，誰用坑誰，不知道現在還是不是，小專案小流量千萬別用，本來1c1g機器能跑全套，跑mongo要8g記憶體才行，純給雲服務商打工了。

效能不如mysql，唯一的好處就分散式方便，只能用來做日誌系統，計算用的大資料儲存。要不還是乖乖用MySQL吧，一個稍微複雜點的查詢效能可以比mysql慢十多倍。 另外一點好處就是寫入特快，不會因為單表資料越來越多就越來越慢。只合適做低頻查詢的資料儲存

先說結論，沒有什麼適合不適合，技術都是相通的。

離開業務空談技術原型就是耍流氓。

電商的哪個環節可能可以使用文件型資料庫mongodb