前言
身邊一直都有小伙伴在問：MongoDB到底是什么？它有到底什么特性？有什么與眾不同？在什么情況下使用MongoDB最合適？以什么樣的姿勢是最好的？難道就一定要用嗎？....說實話，這些問題都問到精髓了，也看得出來你們的急切和真切。有時候大家都比較忙，很難抽出一天的時間，坐而論道，把這些問題掰扯清楚，然后忽如睡醒，豁然開悟。當然，個人也不是專業的”布道者“，所以，通過電話、微信、QQ、釘釘或者其它的辦公聊天軟件，讓我幾句話給大家說明白，有些困難，也不切實際。所以，難免有時候，你們是滿臉藏不住的哀怨，我也是意猶未盡。現在，我把我前兩年分享的一個PPT，分享給大家，希望通過這個分享，能讓大家對MongoDB有一個相對完整的全面認識。
第一部分 概述
1.1 MongoDB 初識
1.2 MongoDB“江湖”地位
名副其實的 名列前茅、青年才俊
廣受好評 迷弟迷妹 眾多
未來可期，潛力股
兩年已過，熱度不減，你的地位依然無可替代
1.3 業界案例
第二部分 MongoDB 特性
MongoDB：為提升開發效率而生。
2.1 特性之動態文檔模型
2.2 特性之副本集
復制集的作用：
（1）高可用，防止設備（服務器、網絡）故障。提供自動FailOver功能；
（2）災難恢復，當發生故障時，可以從其它節點快速恢復；
（3）功能隔離，用於分析、報表，數據挖掘，系統任務等；用於備份。
復制集成員最多50個。參與Primary選舉投票的成員最多7個，其他成員的votes屬性必須設置為0，即不參與投票。
寫關注機制WriteConcert；用來指定MongoDB對寫操作的回執行為。
可在connection level 或者寫操作level指定。
2.3 特性之分片
分片（sharding）的優勢
A.對集群進行抽象，讓集群“不可見”，分片對應用系統是透明的
MongoDB自帶了一個叫做mongos的專有路由進程。mongos就是掌握統一路口的路由器，其會將客戶端發來的請求准確無誤的路由到集群中的一個或者一組服務器上，同時會把接收到的響應拼裝起來發回到客戶端。
B.保證集群總是可讀寫
MongoDB通過多種途徑來確保集群的可用性和可靠性。將MongoDB的分片和復制集功能結合使用，在確保數據分片到多台服務器的同時，也確保了每分數據都有相應的備份，可以確保有服務器壞掉時，其他的從庫可以立即接替壞掉的部分繼續工作。
C.使集群易於擴展
當系統需要更多的空間和資源的時候，MongoDB使我們可以按需方便的擴充系統容量。
分片（sharding）的組件
A. Mongos
Mongos作為Sharding Cluster的訪問入口，所有的請求都由mongos來路由、分發、合並，這些動作對客戶端driver透明，用戶連接mongos就像連接mongod一樣使用。Mongos會根據請求類型及shard key將請求路由到對應的Shard。
B.Config Server
Config Server 存儲Sharding Cluster 的所有元數據，所有的元數據都存儲在config數據庫：
*保存每個分片上的chunk的信息 * 保存chunk上的片鍵范圍。
C.Shard
Shard 存儲應用數據記錄。Chunk size 默認是64M。
（1）分片鍵決定了文檔在集群中的位置；（2）分片鍵必須有索引；（3）分片鍵大小限制在512bytes；（4）MongoDB不接受已進行collection 級分片的collection上插入無分片鍵的文檔（也不支持空值插入）；（5） 一旦集合已經分片，就不可以直接修改分片鍵。
分片（sharding）的分割和遷移
分割和遷移 MongoDB底層依賴2個機制來保持集群的平衡：分割和遷移。分割是把一個大的數據塊分割為2個更小的數據塊的過程。遷移就是在分片之間移動數據塊的過程。當某些分片服務器包含的數據塊數據量大大超過其他分片服務器時就會觸發遷移的過程，這個觸發器叫做遷移回合（migration round）
| Number of Chunks Migration | Threshold |
| Less then 20 | 2 |
| 21-80 | 4 |
| Greater than 80 | 8 |
遷移工作誰來做？
自動：3.2 版本里，Mongos有個后台的Balance任務，該任務不斷來判斷是否需要遷移，如果需要，則發送moveChunk命令到源shard上開始遷移。
手動：用戶能主動觸發數據遷移，還可以手動關停、指定運行時間窗口。
2.4 使用MongoDB的場景
第三部分 基本操作
3.1 查詢操作
3.2 插入操作
3.3 更新操作
3.4 聚合操作
（1）MongoDB提供了兩種內置分析數據的方法：Map Reduce和Aggregation框架。聚合框架，第一在MongoDB2.2 中引入，每一次新版本發布都會更新。MongoDB 2.6 加入了許多更新，框架也相對成熟了。
（2）其他聚合功能：.count() 和.distinct()。
（3）map-reduces是MongoDB提供靈活聚合功能的首次嘗試。使用map-reduce,可以使用JavaScript定義整個處理流程。這提供了很大的靈活性，但是比聚合框架性能要低得多。此外，編寫map-reduce的過程相對復雜，比聚合框架更加難以理解。
（4）雖然map-reduce提供了JavaScript的靈活性，但是它限制了必須是單線程和解釋性的模式。聚合框架是作為原生C++和多線程模式執行的。雖然map-reduce沒有被淘汰，但是未來的改進都會在集合框架上進行的。
第四部分 性能優化
4.1 性能診斷
4.2 性能優化之模式設計
（1）業務驅動，而非數據驅動；
（2）不要按照關系型來設計表結構，建議更多使用內嵌方式；
（3）數據庫集合（collection）的數量不宜太多；
（4）數據冗余是可以接受的。
4.3 性能優化之索引設計
（1）重復率越低越適合做索引；狀態、性別等不適合建立索引；
（2）對於包含多個鍵的查詢，創建包含這些鍵的復合索引是個不錯的解決方案。復合索引的鍵值順序很重要，理解索引最左前綴原則；
（3）有添加盡量匹配覆蓋索引；
（4）稀疏索引：不存儲Null信息的索引，（3.2以上才有，不能當做分片的片鍵）；局部索引（稀疏索引進化版）；
（5）后台創建索引；
（6）文本索引一個重要的不同是一個集合只有一個文本索引；
（7）文字搜索索引提供的功能快速單詞搜素的索引、匹配精確字段、使用特定單詞或者句子排序文檔、支持多語言、基於匹配度對查詢結果打分。
IT打工人，碼字不易，轉載分享請注明出處,謝謝配合！！！