身邊一直都有小夥伴在問：MongoDB到底是什麼？它有到底什麼特性？有什麼與衆不同？在什麼情況下使用MongoDB最合适？以什麼樣的姿勢是最好的？難道就一定要用嗎？....說實話，這些問題都問到精髓了，也看得出來你們的急切和真切。有時候大家都比較忙，很難抽出一天的時間，坐而論道，把這些問題掰扯清楚，然後忽如睡醒，豁然開悟。當然，個人也不是專業的”布道者“，是以，通過電話、微信、QQ、釘釘或者其它的辦公聊天軟體，讓我幾句話給大家說明白，有些困難，也不切實際。是以，難免有時候，你們是滿臉藏不住的哀怨，我也是意猶未盡。現在，我把我前兩年分享的一個PPT，分享給大家，希望通過這個分享，能讓大家對MongoDB有一個相對完整的全面認識。
名副其實的 名列前茅、青年才俊
廣受好評 迷弟迷妹 衆多
未來可期，潛力股
兩年已過，熱度不減，你的地位依然無可替代
MongoDB：為提升開發效率而生。
複制集的作用：
（1）高可用，防止裝置（伺服器、網絡）故障。提供自動FailOver功能；
（2）災難恢複，當發生故障時，可以從其它節點快速恢複；
（3）功能隔離，用于分析、報表，資料挖掘，系統任務等；用于備份。
複制內建員最多50個。參與Primary選舉投票的成員最多7個，其他成員的votes屬性必須設定為0，即不參與投票。
寫關注機制WriteConcert；用來指定MongoDB對寫操作的回執行為。
可在connection level 或者寫操作level指定。
A.對叢集進行抽象，讓叢集“不可見”，分片對應用系統是透明的
MongoDB自帶了一個叫做mongos的專有路由程序。mongos就是掌握統一路口的路由器，其會将用戶端發來的請求準确無誤的路由到叢集中的一個或者一組伺服器上，同時會把接收到的響應拼裝起來發回到用戶端。
B.保證叢集總是可讀寫
MongoDB通過多種途徑來確定叢集的可用性和可靠性。将MongoDB的分片和複制集功能結合使用，在確定資料分片到多台伺服器的同時，也確定了每分資料都有相應的備份，可以確定有伺服器壞掉時，其他的從庫可以立即接替壞掉的部分繼續工作。
C.使叢集易于擴充
當系統需要更多的空間和資源的時候，MongoDB使我們可以按需友善的擴充系統容量。
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） 一旦集合已經分片，就不可以直接修改分片鍵。
分割和遷移 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上開始遷移。
手動：使用者能主動觸發資料遷移，還可以手動關停、指定運作時間視窗。
（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沒有被淘汰，但是未來的改進都會在集合架構上進行的。
（1）業務驅動，而非資料驅動；
（2）不要按照關系型來設計表結構，建議更多使用内嵌方式；
（3）資料庫集合（collection）的數量不宜太多；
（4）資料備援是可以接受的。
（1）重複率越低越适合做索引；狀态、性别等不适合建立索引；
（2）對于包含多個鍵的查詢，建立包含這些鍵的複合索引是個不錯的解決方案。複合索引的鍵值順序很重要，了解索引最左字首原則；
（3）有添加盡量比對覆寫索引；
（4）稀疏索引：不存儲Null資訊的索引，（3.2以上才有，不能當做分片的片鍵）；局部索引（稀疏索引進化版）；
（5）背景建立索引；
（6）文本索引一個重要的不同是一個集合隻有一個文本索引；
（7）文字搜尋索引提供的功能快速單詞搜素的索引、比對精确字段、使用特定單詞或者句子排序文檔、支援多語言、基于比對度對查詢結果打分。
IT打勞工，碼字不易，轉載分享請注明出處,謝謝配合！！！