舉個例子：

mysql:一個表格中有5個字段，你程式已經寫好了，然後這邊要加兩個字段，於是你先去資料庫修改表格結構，增加字段，然後回到程序，修改sql程式碼。

mongodb ： 一個物件有5個屬性，你程式已經寫好了，然後這邊要加兩個屬性（欄位），你直接在程式裡加上，就OK了。

關係型資料庫，一筆記錄是一行，一個欄位是一列，資料處在行與列的交叉處。多行多列必須遵循相同的二維結構。

非關係型資料庫，屬性只屬於物件。對象之間是獨立的。

長線業務用mysql+memcache組合，統計日誌類業務或PM拍腦門硬上的臨時事務用mongodb+redis的組合。
mongodb的優點是靈活，劣勢也是靈活，穩定性不如mysql

相對於傳統的關係型資料庫，MongoDB是非關係型資料庫的代表之一。要知道什麼時候應該使用MongoDB，首先應該知道它具有一些什麼特性，能做什麼和不能做什麼，然後根據具體情況決定是否使用。建議先閱讀一下官方文件中的介紹部分，其中列舉的是MongoDB最關鍵的特性，而其他所有功能幾乎都是圍繞著這些特性。這些特性大部分時候也是決定是否要採用MongoDB的關鍵因素。
這裡有一篇文章也簡單粗暴地介紹瞭如何選擇的問題。
然而，隨著技術發展，所謂「關係型」和「非關係型」的界線已經越來越模糊，一方面Postgre、MySQL這些傳統RDBMS開始支援JSON這樣的非關係模型，另一方面MongoDB也開始支持JOIN，甚至將來會支援事務。既然界線變得模糊，那麼什麼時候應該使用哪種技術也就不能一概而論了，比較結果往往是既能用這個，又能用那個。但你確實可以比較如果在專案中使用了某種技術，會得到什麼，失去什麼，然後權衡得到的部分是否能彌補損失的部分，最終決定是否採用這種技術。

資料的結構不一定的時候用mongodb最好，例如你sql資料庫中要先定義所有欄位的類型，名字，長度什麼的，這就缺少了彈性，mongodb在某個欄位資料不存在的時候就當他沒有。

舉個例子，假設我們的伺服器要在資料庫裡保存系統發生的事件event。某某用戶做了某某事，有時候你要紀錄他發送的post的原始的body內容以備查詢，有的時候又不要，那麼在不需要紀錄post內容的時候，假如你在sql中定義string長度為1000，就浪費了這段空間，mongodb就不會。而且在取出這條記錄的時候，sql資料庫會傳回你定義的那個結構，即使其中的一個字段為空，而mongodb由於保存的時候就沒有包含那個為空的字段，取出來的時候也同樣不會有。

還有就是mongodb對於json的各種結構所支援的很不錯，當然這應該不是你採用mongodb的主要目的。