1.MySQL來自女兒的名字；MongoDB來自humongous
2.MySQL使用Table/Row/Column；MongoDB使用Collection/Document
3.MySQL須要指定table的schema；MongoDB的collection的每一個document的schema能夠自由修改
4.MySQL支持join；MongoDB沒有join
5.MySQL使用SQL語言；MongoDB使用相似JavaScript的函數node
mongodb與mysql命令對比 傳統的關係數據庫通常由數據庫（database）、表（table）、記錄（record）三個層次概念組成，MongoDB是由數據庫（database）、集合（collection）、文檔對象（document）三個層次組成。MongoDB對於關係型數據庫裏的表，可是集合中沒有列、行和關係概念，這體現了模式自由的特色。mysql
MongoDB自己它還算比較年輕的一個產品，因此它的問題，就是成熟度確定沒有傳統MySQL那麼成熟穩定。因此在使用的時候，redis
第一，儘可能使用穩定版，不要在線上使用開發版，這是一個大原則；sql
另一點，備份很重要，MongoDB若是出現一些異常狀況，備份必定是要能跟上。除了經過傳統的複製的方式來作備份，離線備份也仍是要有，無論你是用什麼方式，都要有一個完整的離線備份。每每最後出現了特殊狀況，它能幫助到你；mongodb
另外，MongoDB性能的一個關鍵點就是索引，索引是否是能有比較好的使用效率，索引是否是可以放在內存中，這樣可以提高隨機讀寫的性能。若是你的索引不能徹底放在內存中，一旦出現隨機讀寫比較高的時候，它就會頻繁地進行磁盤交換，這個時候，MongoDB的性能就會急劇降低，會出現波動。數據庫
另外，MongoDB還有一個最大的缺點，就是它佔用的空間很大，由於它屬於典型空間換時間原則的類型。那麼它的磁盤空間比普通數據庫會浪費一些，並且到目前爲止它尚未實如今線壓縮功能，在MongoDB中頻繁的進行數據增刪改時，若是記錄變了，例如數據大小發生了變化，這時候容易產生一些數據碎片，出現碎片引起的結果，一個是索引會出現性能問題，json
另一個就是在必定的時間後，所佔空間會莫明其妙地增大，因此要按期把數據庫作修復，按期從新作索引，這樣會提高MongoDB的穩定性和效率。在最新的版本里，它已經在實如今線壓縮，估計應該在2.0版左右，應該可以實如今線壓縮，能夠在後臺執行如今repair DataBase的一些操做。若是那樣，就解決了目前困擾咱們的大問題。數據結構
三.問題
用戶數據庫是用mongodb好，仍是用mysql好？修改
打算給一系列產品統一帳戶，程序用的是nodejs寫的，用戶數據庫大概就是記錄用戶名、密碼、電子郵箱還有一些會高併發頻繁變動的信息，這種數據庫要用mongodb仍是mysql？或者有更好的推薦嗎？併發
答案:
a1: mysql更通用 若是不知道選什麼就選mysql錯不了. 而mongodb的存在更多的是對於mysql的一個細分需求領域中的補充.
好比在遊戲行業中 使用json格式的mongodb基本上能夠知足全部數據結構的存儲, 並且你不再必由於擴充一個小功能而糾結新建一個表來存儲 仍是新建一個字段並用字符串來存儲(每次讀/寫都要解析/序列化成字符串存儲), mysql是否是特別傻笨粗, 而遊戲基本上前面搭好框子後面寫業務的時候 一直都是在作這些東西.運維
但正如我上面說的 mongodb只是一個細分需求領域的補充, 不少東西他作不了也作很差 假如你的程序哪怕有1%的功能在這裏 這都容易悲劇.
另外說一下題主問題中提供的需求見解.
看上去是統一認證系統或者認證平臺之類的需求.
通常有如下特色.
1. 數據結構簡單. 因此用mysql仍是mongodb在這裏都同樣.
2. 可能對讀性能有要求 但寫速度關係不大, 通常都是大量已註冊用戶登陸. 所以mysql必定要配合redis或者memcache, 這樣的話 mongodb稍微勝出一點, mongodb自己的讀速度有優化, 很可觀.
3. 數據結構中含有一些特殊數據 好比玩家的充值信息. mysql明顯比mongodb好的太多.
4. 日誌統計, mysql的存儲過程能夠很方便的作不少統計工做, mongodb的話就要委屈後臺小哥多寫點代碼來作統計了(實際上由於數據簡單 可能也就幾行代碼).
所以呢 根據上面幾點來講, 用mongodb的意義不大, 但具體題主的需求, 本身根據上面我列舉的幾條能夠本身再度量一下.
a2: 推薦mysql
更主要仍是看你怎麼用，你要很悠閒，想學習，愛折騰那就mongodb吧。
存儲用戶數據，確定也要讀取吧，還要JOIN關聯，各類查詢，分析。
用mongdb可就麻煩了，group受限，map/reduce不爽
如今的mysql也不知有沒有對mongodb對接的支持。
mysql也就是幾條SQL的事,用mongodb不一樣庫，還得在代碼裏拼數據。
嚐鮮一時爽，卻埋下了之後更多的工做量。
我我的只是用mongodb做相對獨立的小系統，好比一些數據分析，抓取，彙總的工做。
1.3 MongoDB的應用場景
在另外一方面，對開發者來講，若是是由於業務需求或者是項目初始階段，而致使數據的具體格式沒法明肯定義的話，MongoDB的這一鮮明特性就脫穎而出了。相比傳統的關係型數據庫，它很是容易被擴展，這也爲寫代碼帶來了極大的方便。
不過MongoDB對數據之間事務關係支持比較弱，若是業務這一方面要求比較高的話，MongoDB仍是並不適合此類型的應用。
8.4 MongoDB的缺陷
1. 事務關係支持薄弱。這也是全部NoSQL數據庫共同的缺陷，不過NoSQL並非爲了事務關係而設計的，具體應用仍是很需求。
2. 穩定性有些欠缺，這點從上面的測試即可以看出。
3. MongoDB一方面在方便開發者的同時，另外一方面對運維人員卻提出了至關多的要求。業界並無成熟的MongoDB運維經驗，MongoDB中數據的存放格式也很隨意，等等問題都對運維人員的考驗。