前言
身邊一直都有小夥伴在問：MongoDB到底是什麼？它有到底什麼特性？有什麼與眾不同？在什麼情況下使用MongoDB最合適？以什麼樣的姿勢是最好的？難道就一定要用嗎？....說實話，這些問題都問到精髓了，也看得出來你們的急切和真切。有時候大家都比較忙，很難抽出一天的時間，坐而論道，把這些問題掰扯清楚，然後忽如睡醒，豁然開悟。當然，個人也不是專業的”佈道者“，所以，通過電話、微信、QQ、釘釘或者其它的辦公聊天軟體，讓我幾句話給大家說明白，有些困難，也不切實際。所以，難免有時候，你們是曼聯藏不住的哀怨，我也是意猶未盡。現在，我把我前兩年分享的一個PPT，分享給大家，希望通過這個分享，能讓大家對MongoDB有一個相對完整的全面認識。
第一部分 概述
1.1 MongoDB 初識
1.2 MongoDB“江湖”地位
名副其實的 名列前茅、青年才俊
廣受好評 迷弟迷妹 眾多
未來可期，潛力股
兩年已過，熱度不減，你的地位依然無可替代
1.3 業界案例
第二部分 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打工人，碼字不易，轉載分享請註明出處,謝謝配合！！！