1、首先到官網(http://www.mongodb.org/downloads)或者(https://www.mongodb.org/dl/win32/x86_64-2008plus-ssl)下載合適的安裝包，推薦下載zip壓縮版。
mongodb-win32-x86_64-2008plus-ssl-4.0.5.zip
下載地址：
https://fastdl.mongodb.org/win32/mongodb-win32-x86_64-2008plus-ssl-4.0.5.zip
因爲我這裏已經下載過3.4的 因此直接使用我現在版本的
2、解壓下載的mongodb-win32-x86_64-2008plus-ssl-v3.4-latest.zip 到指定的盤，我解壓到了 D:\tools\mongodb3.4，目錄如下：
3、創建D:\tools\mongodb3.4\data目錄，並在D:\tools\mongodb3.4\bin目錄下執行命令：
mongod --dbpath D:\tools\mongodb3.4\data
在cmd最後出現以下信息證明啓動成功：
2017-03-1T14:10:48.391+0800[initandlisten] waitingforconnections on port27017
在瀏覽器中輸入：http://localhost:27017/
出現
It looks like you are trying to access MongoDB over HTTP on the native driver port.
4、在D:\tools\mongodb3.4文件夾下創建：
文件夾 conf,data,logs
創建D:\tools\mongodb3.4\conf\mongo.conf 文件
mongo.conf文件內容：
#端口號 默認爲27017
port=27017
#數據庫路徑
dbpath=D:\tools\mongodb3.4\data
#日誌輸文件路徑
logpath=D:\tools\mongodb3.4\logs\mongo.log
#錯誤日誌採用追加模式
logappend=true
#啓用日誌文件，默認啓用
journal=true
#這個選項可以過濾掉一些無用的日誌信息，若需要調試使用請設置爲false
quiet=true
4、在D:\tools\mongodb3.4\bin目錄下執行命令：
啓動服務
mongod --config "D:\tools\mongodb3.4\conf\mongo.conf"
在瀏覽器中輸入：http://localhost:27017/
出現：It looks like you are trying to access MongoDB over HTTP on the native driver port.
5、如果每次都按照步驟4啓動非常麻煩，直接將mongodb作爲服務：
在D:\tools\mongodb3.4\bin目錄下執行命令：
mongod --config "D:\tools\mongodb3.4\conf\mongo.conf" --install --serviceName "MongoDB3.4"
啓動：
net start MongoDB
至此mongodb安裝完畢。
如果需要卸載MongoDB服務，首先進入D:\tools\mongodb3.4\bin（依安裝目錄而定）目錄下，執行如下命令：
mongod --remove --serviceName "MongoDB3.4"
6、配置環境變量
在path環境變量增加：D:\tools\mongodb3.4\bin路徑
特點
與關係型數據庫相比，MongoDB的優點：
①弱一致性（最終一致），更能保證用戶的訪問速度：
舉例來說，在傳統的關係型數據庫中，一個COUNT類型的操作會鎖定數據集，這樣可以保證得到“當前”情況下的較精確值。這在某些情況下，例 如通過ATM查看賬戶信息的時候很重要，但對於Wordnik來說，數據是不斷更新和增長的，這種“較精確”的保證幾乎沒有任何意義，反而會產生很大的延 遲。他們需要的是一個“大約”的數字以及更快的處理速度。
但某些情況下MongoDB會鎖住數據庫。如果此時正有數百個請求，則它們會堆積起來，造成許多問題。我們使用了下面的優化方式來避免鎖定：
每次更新前，我們會先查詢記錄。查詢操作會將對象放入內存，於是更新則會儘可能的迅速。在主/從部署方案中，從節點可以使用“-pretouch”參數運行，這也可以得到相同的效果。
使用多個mongod進程。我們根據訪問模式將數據庫拆分成多個進程。
②文檔結構的存儲方式，能夠更便捷的獲取數據。
對於一個層級式的數據結構來說，如果要將這樣的數據使用扁平式的，表狀的結構來保存數據，這無論是在查詢還是獲取數據時都十分困難。
③內置GridFS，支持大容量的存儲。
GridFS是一個出色的分佈式文件系統，可以支持海量的數據存儲。
內置了GridFS了MongoDB，能夠滿足對大數據集的快速範圍查詢。
④內置Sharding。
提供基於Range的Auto Sharding機制：一個collection可按照記錄的範圍，分成若干個段，切分到不同的Shard上。
Shards可以和複製結合，配合Replica sets能夠實現Sharding+fail-over，不同的Shard之間可以負載均衡。查詢是對 客戶端是透明的。客戶端執行查詢，統計，MapReduce等操作，這些會被MongoDB自動路由到後端的數據節點。這讓我們關注於自己的業務，適當的 時候可以無痛的升級。MongoDB的Sharding設計能力較大可支持約20 petabytes，足以支撐一般應用。
這可以保證MongoDB運行在便宜的PC服務器集羣上。PC集羣擴充起來非常方便並且成本很低，避免了“sharding”操作的複雜性和成本。
⑤第三方支持豐富。(這是與其他的NoSQL相比，MongoDB也具有的優勢)
現在網絡上的很多NoSQL開源數據庫完全屬於社區型的，沒有官方支持，給使用者帶來了很大的風險。
而開源文檔數據庫MongoDB背後有商業公司10gen爲其提供供商業培訓和支持。
而且MongoDB社區非常活躍，很多開發框架都迅速提供了對MongDB的支持。不少知名大公司和網站也在生產環境中使用MongoDB，越來越多的創新型企業轉而使用MongoDB作爲和Django，RoR來搭配的技術方案。
⑥性能優越：
在使用場合下，千萬級別的文檔對象，近10G的數據，對有索引的ID的查詢不會比mysql慢，而對非索引字段的查詢，則是全面勝出。 mysql實際無法勝任大數據量下任意字段的查詢，而mongodb的查詢性能實在讓我驚訝。寫入性能同樣很令人滿意，同樣寫入百萬級別的數 據，mongodb比我以前試用過的couchdb要快得多，基本10分鐘以下可以解決。補上一句，觀察過程中mongodb都遠算不上是CPU殺手。
與關係型數據庫相比，MongoDB的缺點
①mongodb不支持事務操作。
所以事務要求嚴格的系統（如果銀行系統）肯定不能用它。(這點和優點①是對應的)
②mongodb佔用空間過大。
關於其原因，在官方的FAQ中，提到有如下幾個方面：
1、空間的預分配：爲避免形成過多的硬盤碎片，mongodb每次空間不足時都會申請生成一大塊的硬盤空間，而且申請的量從64M、128M、256M那 樣的指數遞增，直到2G爲單個文件的較大體積。隨着數據量的增加，你可以在其數據目錄裏看到這些整塊生成容量不斷遞增的文件。
2、字段名所佔用的空間：爲了保持每個記錄內的結構信息用於查詢，mongodb需要把每個字段的key-value都以BSON的形式存儲，如果 value域相對於key域並不大，比如存放數值型的數據，則數據的overhead是較大的。一種減少空間佔用的方法是把字段名儘量取短一些，這樣佔用 空間就小了，但這就要求在易讀性與空間佔用上作爲權衡了。我曾建議作者把字段名作個index，每個字段名用一個字節表示，這樣就不用擔心字段名取多長 了。但作者的擔憂也不無道理，這種索引方式需要每次查詢得到結果後把索引值跟原值作一個替換，再發送到客戶端，這個替換也是挺耗費時間的。現在的實現算是 拿空間來換取時間吧。
3、刪除記錄不釋放空間：這很容易理解，爲避免記錄刪除後的數據的大規模挪動，原記錄空間不刪除，只標記“已刪除”即可，以後還可以重複利用。
4、可以定期運行db.repairDatabase()來整理記錄，但這個過程會比較緩慢
③MongoDB沒有如MySQL那樣成熟的維護工具，這對於開發和IT運營都是個值得注意的地方。
MongoDB適合存儲一些關係簡單、數據量又很大的數據，比如我們的平臺上虛擬機的監控信息，包括內存、IO、CPU、網絡等數據，每隔幾秒就採集一次數據，每週、每月，量很大，而且舊的監控數據也不會保留太長時間，就使用的mongodb來存儲這些數據；
另外mongodb的集羣部署相對比較簡單，易於擴展；比如主從複製，在mongo.conf配置幾個參數就OK了；分片集羣的配置也比較簡單。還支持使用命令行來進行動態地添加和刪除節點；
Mongodb的優點與不足
（1）Mongodb的不足之處
1、在集羣分片中的數據分佈不均勻
2、單機可靠性比較差
3、大數據量持續插入，寫入性能有較大波動
4、磁盤空間佔用比較大
（2）Mongodb的過人之處
1、無模式
2、查詢與索引方式靈活，是最像SQL的Nosql
3、支持複製集、主備、互爲主備、自動分片等特性
Mongodb與redis相比較
mongoDB 源碼語言是C++,redis也是C或C++,
mongodb 文件存儲是BSON格式類似JSON，或自定義的二進制格式。
mongodb與redis性能都很依賴內存的大小，mongodb 有豐富的數據表達、索引；最類似於關係數據庫，支持豐富的查詢語言，redis數據豐富，較少的IO ，這方面mongodb優勢明顯。
mongodb不支持事物，靠客戶端自身保證，redis支持事物，比較弱，僅能保證事物中的操作按順序執行，這方面 redis優於mongodb。
mongodb對海量數據的訪問效率提升，redis 較小數據量的性能及運算,這方面 mongodb性能優於redis .monbgodb 有mapredurce功能，提供數據分析，redis 沒有 ，這方面 mongodb優於redis
使用場景
介紹了MongoDB的優勢，也不得不提MongoDB的不足，MongoDB僅支持文檔內的事務，所以對於需要跨文檔或跨集合事務的應用，請謹慎使用MongoDB；另外，對於需要多表複雜Join的業務，還是使用關係型數據庫爲好，MongoDB還在改善的路上；最後，對於PB級大數據量，且需要進行大規模計算的場景，使用MongoDB時需要配套使用Spark、Hadoop等大數據套件，讓MongoDB做正確的事情。總結起來，如果你的業務滿足一個或多個特點，那麼選擇MongoDB是個正確的決定：
1、無需要跨文檔或跨表的事務及複雜的join查詢支持
2、敏捷迭代的業務，需求變動頻繁，數據模型無法確定
3、存儲的數據格式靈活，不固定，或屬於半結構化數據
4、業務併發訪問量大，需數千的QPS
5、TB級以上的海量數據存儲，且數據量不斷增加
6、要求存儲的數據持久化、不丟失
7、需要99.999%的數據高可用性
8、需要大量的地理位置查詢、文本查詢
典型場景：商品的不規則屬性
商品除了共有屬性之外還有一些特殊屬性，比如上衣圓領，方領，之類的，可以單獨和商品放在一起，一同查詢出來，避免關係數據庫上的join查詢。
後臺管理系統的層級菜單欄，直接可以保存和查詢，避免了關係數據庫的多次層級遍歷。
物聯網中的設備傳感器實時上報監測數據等，比如GPS運動軌跡
地理位置：mongoDB,elastic-searcht，redis他們都提供,但是redis不推薦存儲大數據量
