本人最近做一個O2O平台專案（含管理、預約、付款、接取微信等），當初出於人員能力、成本等考慮，選擇了標準的MEAN作為技術選型。做起來確實很快，但隨著專案需求的迭代，我感覺該技術選型特別是mongodb存在非常多的局限，主要如下：
1、mongodb不支援join的操作，只能簡單透過populate擴展，因此，但凡有跨表的查詢、統計都非常麻煩；我們現在很多是透過資料的冗餘來做的，就是乾脆資料欄位在幾個集合裡都存。
2、mongodb不支援事務，因此許多回滾的操作我們現在是在業務的同步框架裡處理，程式碼顯得非常冗餘，且本質上仍然不是真正意義上的回滾；
我聽說業內現在有越來越多的純MEAN的大項目，我不知道大家是怎麼解決上述問題的？還是說核心業務邏輯仍然用的是關係型資料庫。
我的專案有些遇到join的問題。我的解決辦法就是儲存對應的ObjectId們,透過mongodb的aggregation來達到join的目的。我用了WiredTiger引擎,所以解決了在大量讀寫的時候鎖死資料庫的問題。還有在設計資料庫上面盡量避免傳統的sql設計思維跟開發邏輯。一個collection盡量對應一個事件。後來因為專案的擴大，我引入了worker的開發模式，將邏輯層的關係改成獨立的線程的worker，目前來說應對大量無上線並發效果不錯(類似於無上線人數搶紅包的效果）。一點兒拙見僅供參考。
還有就是對已習慣sql開發模式的人mongodb的限制會讓人很不習慣。但是在大數據時代mongodb的優勢是顯而易見。目前來說我的專案基本架構是:
伺服器： nginx+mongodb+php-fpm+ubuntu
主程式： MVC(php) // 值提供邏輯關係交換
輔程式： Workers // 多執行緒處理對應的邏輯關係做資料庫互交
技術選型時沒考慮到？沒必要只用mongo，可以多庫並存
各位，其實我的問題不在於Mongo有沒有缺陷，或者該不該換。而是，在假設不切換資料庫的情況下，有沒有什麼方案可以解決上述問題。我相信業內一定有其他人遇到並解決了這些問題。
mongodb不適合這種項目，他適合查詢類的，而且是簡單的，關係強的項目還是用關係資料庫