MongoDB 將資料儲存為一個文件，資料結構由鍵值(key=>value)對組成。MongoDB 文件類似於 JSON 物件。欄位值可以包含其他文件，陣列及文件陣列。

主要特點
MongoDB的提供了一個面向文件儲存，操作起來比較簡單和容易。

MongoDB的提供了一個面向文件儲存，操作起來比較簡單和容易。
你可以在MongoDB記錄中設定任何屬性的索引 (如：FirstName="Sameer",Address="8 Gandhi Road")來實現更快的排序。

GridFS是MongoDB中的一個內建功能，可以用於存放大量小檔案。
MongoDB允許在服務端執行指令碼，可以用Javascript編寫某個函式，直接在服務端執行，也可以把函式的定義儲存在服務端，下次直接呼叫即可。
MongoDB支援各種程式語言:RUBY，PYTHON，JAVA，C++，PHP，C#等多種語言。
MongoDB安裝簡單。

二.MongoDB和MySQL比較

MongoDB本身它還算比較年輕的一個產品，所以它的問題，就是成熟度肯定沒有傳統MySQL那麼成熟穩定。所以在使用的時候，
第一，儘量使用穩定版，不要在線上使用開發版，這是一個大原則；
另外一點，備份很重要，MongoDB如果出現一些異常情況，備份一定是要能跟上。除了通過傳統的複製的方式來做備份，離線備份也還是要有，不管你是用什麼方式，都要有一個完整的離線備份。往往最後出現了特殊情況，它能幫助到你；

更主要還是看你怎麼用，你要很清閒，想學習，愛折騰那就mongodb吧。

儲存使用者資料，肯定也要讀取吧，還要JOIN關聯，各種查詢，分析。

用mongdb可就麻煩了，group受限，map/reduce不爽

現在的mysql也不知有沒有對mongodb對接的支援。

mysql也就是幾條SQL的事,用mongodb不同庫，還得在程式碼裡拼資料。

嚐鮮一時爽，卻埋下了以後更多的工作量。

我個人只是用mongodb作相對獨立的小系統，比如一些資料分析，抓取，彙總的工作。

MongoDB是一種檔案導向的資料庫管理系統，屬於一種通稱為NoSQL的資料庫，是10gen公司旗下的開源產品，其內部資料儲存的方式與傳統的關係型資料有很大差別。

NoSQL的全稱是Not Only SQL，也可以理解非關係型的資料庫，是一種新型的革命式的資料庫設計方式，不過它不是為了取代傳統的關係型資料庫而被設計的，它們分別代表了不同的資料庫設計思路。

在傳統的關係型資料庫中，資料是以表單為媒介進行儲存的，每個表單均擁有縱向的列和橫向的行。由此可見，相比較MySQL，MongoDB以一種直觀文件的方式來完成資料的儲存。它很像JavaScript中定義的JSON格式，不過資料在儲存的時候MongoDB資料庫為文件增加了序列化的操作，最終存進磁碟的其實是一種叫做BSON的格式，即Binary-JSON。

1.3 MongoDB的應用場景
在另一方面，對開發者來說，如果是因為業務需求或者是專案初始階段，而導致資料的具體格式無法明確定義的話，MongoDB的這一鮮明特性就脫穎而出了。相比傳統的關係型資料庫，它非常容易被擴充套件，這也為寫程式碼帶來了極大的方便。

不過MongoDB對資料之間事務關係支援比較弱，如果業務這一方面要求比較高的話，MongoDB還是並不適合此型別的應用。

另外，MongoDB出現的時機比較晚，還具備一些非常鮮明的特性。比如：

1. 它裡面自帶了一個名叫GirdFS的分散式檔案系統，這就為MongoDB的部署提供了很大便利。而像MySQL這種比較早的資料庫，雖然市面上有很多不同的分表部署的方案，但這種終究不如MongoDB直接官方支援來得便捷實在。

2. 另外，MongoDB內部還自建了對map-reduce運算框架的支援，雖然這種支援從功能上看還算是比較簡單的，相當於MySQL裡GroupBy功能的擴充套件版，不過也為資料的統計帶來了方便。

3. MongoDB在啟動後會將資料庫中的資料以檔案對映的方式載入到記憶體中。如果記憶體資源相當豐富的話，這將極大地提高資料庫的查詢速度，畢竟記憶體的I/O效率比磁碟高多了。

 MongoDB的缺陷
1. 事務關係支援薄弱。這也是所有NoSQL資料庫共同的缺陷，不過NoSQL並不是為了事務關係而設計的，具體應用還是很需求。

2. 穩定性有些欠缺，這點從上面的測試便可以看出。

3. MongoDB一方面在方便開發者的同時，另一方面對運維人員卻提出了相當多的要求。業界並沒有成熟的MongoDB運維經驗，MongoDB中資料的存放格式也很隨意，等等問題都對運維人員的考驗。

對比MySQL，你究竟在什麼時候更需要MongoDB：

摘要：對比傳統關係型資料庫，NoSQL有著非常顯著的效能和擴充套件性優勢，然而這些優點卻建立在一些關鍵功能的丟失之上，比如事務、join等。那麼在資料體積激增的當下，究竟哪個資料庫才會適合你的場景，下面看Moshe的分享。

【編者按】隨著資料的爆發性增長，NoSQL得到的關注已越來越多，然而你的用例真正需要使用NoSQL資料庫嗎？又真的適合使用NoSQL嗎？近日，Bright Aqua研發副總裁Moshe Kaplan以BillRun系統為例，分析了MongoDB的優勢和使用場景：

以下為譯文： 
NoSQL已經流行了很長一段時間，那麼究竟是什麼場景下你才更需要用到這些“新興事物”，就比如MongoDB？下面是一些總結

對比傳統關係型資料庫，NoSQL有著非常顯著的效能和擴充套件性優勢，然而這些優點卻建立在一些關鍵功能的丟失之上，比如事務、join等。那麼在資料體積激增的當下，究竟哪個資料庫才會適合你的場景，下面看Moshe的分享。

【編者按】隨著資料的爆發性增長，NoSQL得到的關注已越來越多，然而你的用例真正需要使用NoSQL資料庫嗎？又真的適合使用NoSQL嗎？近日，Bright Aqua研發副總裁Moshe Kaplan以BillRun系統為例，分析了MongoDB的優勢和使用場景：

以下為譯文： 
NoSQL已經流行了很長一段時間，那麼究竟是什麼場景下你才更需要用到這些“新興事物”，就比如MongoDB？下面是一些總結：

你期望一個更高的寫負載

預設情況下，對比事務安全，MongoDB更關注高的插入速度。如果你需要載入大量低價值的業務資料，那麼MongoDB將很適合你的用例。但是必須避免在要求高事務安全的情景下使用MongoDB，比如一個1000萬美元的交易。

不可靠環境保證高可用性

設定副本集（主-從伺服器設定）不僅方便而且很快，此外，使用MongoDB還可以快速、安全及自動化的實現節點（或資料中心）故障轉移。

未來會有一個很大的規模

資料庫擴充套件是非常有挑戰性的，當單表格大小達到5-10GB時，MySQL表格效能會毫無疑問的降低。如果你需要分片並且分割你的資料庫，MongoDB將很容易實現這一點。

使用基於位置的資料查詢

MongoDB支援二維空間索引，因此可以快速及精確的從指定位置獲取資料。

非結構化資料的爆發增長

給RDBMS增加列在有些情況下可能鎖定整個資料庫，或者增加負載從而導致效能下降，這個問題通常發生在表格大於1GB（更是下文提到BillRun系統中的痛點——單表格動輒幾GB）的情況下。鑑於MongoDB的弱資料結構模式，新增1個新欄位不會對舊錶格有任何影響，整個過程會非常快速；因此，在應用程式發生改變時，你不需要專門的1個DBA去修改資料庫模式。

mongodb與mysql命令對比 傳統的關係資料庫一般由資料庫（database）、表（table）、記錄（record）三個層次概念組成，MongoDB是由資料庫（database）、集合（collection）、文件物件（document）三個層次組成。MongoDB對於關係型資料庫裡的表，但是集合中沒有列、行和關係概念，這體現了模式自由的特點。

專案中使用MySql與MongoDb的一些對比：

MySQL是關係型資料庫中的明星，MongoDB是文件型資料庫中的翹楚。下面通過一個設計例項對比一下二者：假設我們正在維護一個手機產品庫，裡面除了包含手機的名稱，品牌等基本資訊，還包含了待機時間，外觀設計等引數資訊，應該如何存取資料呢？

如果使用MySQL的話，應該如何存取資料呢？

如果使用MySQL話，手機的基本資訊單獨是一個表，另外由於不同手機的引數資訊差異很大，所以還需要一個引數表來單獨儲存。

如果想查詢待機時間大於100小時，並且外觀設計是直板的手機，需按照如下方式查詢：

1 SELECT * FROM `mobile_params` WHERE name = '待機時間' AND value > 100;
2 SELECT * FROM `mobile_params` WHERE name = '外觀設計' AND value = '直板'

如果使用MongoDB的話，雖然理論上可以採用和MySQL一樣的設計方案，但那樣的話就顯得無趣了，沒有發揮出MongoDB作為文件型資料庫的優點，實際上使用MongoDB的話，和MySQL相比，形象一點來說，可以合二為一：

 db.getCollection("mobiles").ensureIndex({
 "params.name": 1,
 "params.value": 1
});

 db.getCollection("mobiles").insert({
"_id": 1,
 "name": "ME525",
 "brand": "摩托羅拉",
"params": [
 {"name": "待機時間", "value": 200},
{"name": "外觀設計", "value": "直板"}
]});

db.getCollection("mobiles").insert({
 "_id": 2,
 "name": "E7",
"brand": "諾基亞",
"params": [
{"name": "待機時間", "value": 500},
{"name": "外觀設計", "value": "滑蓋"}
]
});

如果想查詢待機時間大於100小時，並且外觀設計是直板的手機，需按照如下方式查詢：

view sourceprint?
 db.getCollection("mobiles").find({
 "params": {
 $all: [
 {$elemMatch: {"name": "待機時間", "value": {$gt: 100}}},
 {$elemMatch: {"name": "外觀設計", "value": "直板"}}
]
}
});