MongoDB 那些事（一文以蔽之）

前言

身邊一直都有小夥伴在問：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打工人，碼字不易，轉載分享請註明出處,謝謝配合！！！