MongoDB是非關係型資料庫的典型代表，DB-Engines Ranking 數據顯示，近年來，MongoDB在NoSQL領域一直獨占鰲頭。MongoDB是為快速開發互聯網應用 而設計的資料庫系統，其數據模型和持久化策略就是為了構建高讀/寫的性能，並且可以方面的彈性拓展。目前公司使用到的Mongo ...
MongoDB是非關係型資料庫的典型代表，DB-Engines Ranking 數據顯示，近年來，MongoDB在NoSQL領域一直獨占鰲頭。MongoDB是為快速開發互聯網應用 而設計的資料庫系統，其數據模型和持久化策略就是為了構建高讀/寫的性能，並且可以方面的彈性拓展。目前公司使用到的MongoDB的主要場景有 庫存中心(原料出入庫、商品出入庫、商品上下架變動、與其它系統平臺的交互報文等)、物流配送（訂單的物流信息、配送信息、地理位置信息等）、日誌中心（系統應用和APP的log信息、調用依賴信息等）、商品中心（商品數據、推送信息等）、運維管理平臺（收集記錄的變更信息等）等。隨著MongoDB的普及和使用量的快速增長，為了規範使用，便於管理和獲取更高的性能，整理此文檔。我們從 資料庫設計規範、集合設計規範、文檔設計規範、連接規範、操作規範等5個方面進行闡述和要求。
1. 資料庫設計規範
（1）資料庫名約定為小寫。
（2）資料庫名稱不能包含除’_’以外的特殊字元，例如：/ \ . “ $。
（3）資料庫名稱最多為64個字元。
（4）資料庫上線需經過DBA評審。
2. 集合設計規範
（1）集合名稱約定為小寫。
（2）集合名稱不能包含除’_’以外的特殊字元字元；集合名稱禁止以system.開頭。
（3）集合名稱的最大長度為64個字元，包括首碼的【database.】內容。
（4）集合名稱的命名規則和MySQL資料庫表的命名規則相同。
a) 同一模塊的集合儘可能使用相同的首碼名，集合名稱儘可能表達用途。
b) 數據表 <模塊標識>_<表標識> 例如： order_header , order_detail
c) 編碼表 base_<模塊標識>_<表標識>
d) 日誌表 log_<模塊標識>_<表標識>
（5）固定集合可以用於記錄日誌，其插入數據更快，可以實現在插入數據時，淘汰最早的數據。固定集合需要顯式創建，指定Size的大小，還能夠指定文檔的數量。集合不管先達到哪一個限制，之後插入的新文檔都會把最老的文檔移出。
（6）索引命名：idx_<構成索引的欄位名>。如果欄位名字過長，可採用欄位縮寫。
3. 文檔設計規範
（1）Key的命名規範：不能以$開頭;不能包含.(點號)。
（2）文檔中的_id鍵推薦使用預設值，禁止向_id中保存自定義的值。
解讀：MongoDB文檔中都會有一個“_id”鍵，預設是個ObjectID對象（標識符中包含時間戳、機器ID、進程ID和計數器）。MongoDB在指定_id與不指定_id插入時速度相差很大，指定_id會減慢插入的速率。
（3）推薦使用短欄位名。
解讀：與關係型資料庫不同，MongoDB集合中的每一個文檔都需要存儲欄位名，長欄位名會需要更多的存儲空間。
（4）禁止在同一個集合欄位中存儲多個數據類型的數據。
（5）如若將日期類型選擇為string,不同的日期格式的文檔，不支持等值查詢，不支持範圍查詢。
解讀：創建一個測試集合product，分別向集合插入Date:"20180425"和Date:"2018-04-25"兩筆數據。等值查詢、範圍查詢（$gte, $lte）只能查到日期格式相同的數據，都為一筆數據。
（6）MongoDB大小寫敏感，如果欄位無需大小寫敏感，為了提高查詢效率，應儘量在統一了大小寫之後再插入到資料庫中。
（7）MongoDB是文檔型資料庫，數據以BSON形式存儲在文檔中。MongoDB能夠支持最大16 MB的文檔大小。建議儘量不要存儲大型對象，將文檔控制在16 MB以內。
（8）通過$size查詢數組大小，但是$size運算符不使用索引和限制準確匹配（不能指定$Sized 範圍）。因此，如果需要基於數組的大小執行查詢，可以在文檔設計中增加size屬性。
解讀：例如在商品評價中，其他人可以對評價進行投票。為了阻止用戶多次投票和對有幫助的評論進行排序，所以，評價文檔設計是：在一個數組欄位（voter_ids）保存了所有評論用戶的ID，而數組大小緩存在helpful_votes欄位里。
（9）分片鍵必須有索引，分片鍵大小限製為512byte，一旦集合已經分片，不可以直接修改分片鍵。不接受向已進行分片的collection上插入無分片鍵的文檔，也不支持空值插入。
（10）片鍵的設計原則：
a) 所有的插入、更新、刪除將會均勻發送到集群的所有分片中。
b) 所有的查詢將會在集群中的所有分片中均勻地分發。
c) 所有的更新或者刪除操作將會只面向相關的分片，不會發送到一個沒有存儲被修改數據的分片上。
d) 一個查詢將不會被髮送到沒有存儲被查詢數據的分片上。
4. 連接規範
（1）正確連接副本集，副本集提供了數據的保護、高可用和災難恢復的機制。如果主節點宕機，其中一個從節點會自動提升為從節點。
（2）合理控制連接池的大小，限制連接數資源，可通過Connection String URL中的maxPoolSize 參數來配置連接池大小。
（3）複製集讀選項
預設情況下，複製集的所有讀請求都發到Primary，Driver可通過設置的Read Preference 來將讀請求路由到其他的節點。
a) Primary:預設規則，所有讀請求發到Primary。
b) PrimaryPreferred: Primary優先，如果Primary不可達，請求Secondary。
c) Secondary：所有的讀請求都發到Secondary。
d) SecondaryPreferred：Secondary優先，當所有的Secondary不可達時，請求Primary。
e) Nearest：讀請求發送到最近的可達節點上（通過ping探測得出最近的節點）。
5. 操作規範
（1）MongoDB資料庫更新文檔有兩種實現方式—文檔替換和目標欄位更新。既可以完整替換現有的文檔，也可以使用更新操作符來修改某個欄位。
解讀：使用操作符，例如$set操作符和$push操作符，無論原始的大小，可以更新文檔里的指定欄位。頻繁文檔更新的場景下，使用目標更新可以在序列化和傳輸數據上花費更少的時間，獲得更好的性能。
（2）多文檔更新，在預設情況下，只會更新匹配查詢器的第一個文檔。要更新所有的匹配文檔，需要顯式指定多文檔更新模式--添加參數multi:true。
（3）在文檔級別更新是原子性的，這意味著一條更新10個文檔的語句可能在更新3個文檔後由於某些原因失敗。應用程式必鬚根據自己的策略來處理這些失敗。
（4）update結合upsert可以用來處理，當文檔存在時更新，文檔不存在時插入。如果查詢選擇器匹配，更新就正常執行；如果沒有匹配的文檔，就會插入新的文檔。新文檔的欄位是查詢選擇器和目標更新文檔的邏輯合併。
（5）複製集的數據安全及寫策略，Write Concern 用於控制寫入安全的級別。
解答：Write Concern 是一個性能和數據一致性的權衡，應根據業務場景進行設定。對於強一致性場景，建議w>1或者等於majority。
（6）聚合框架是MongoDB的高級查詢語言，它允許通過轉換和合併由多個文檔中的數據來生成新的單個文檔里不存在的文檔信息。可以把MongoDB的聚合框架等價於SQL的Group By 語句。
（7）在聚合框架中，$project操作符允許過濾傳遞給管道下一個階段的欄位。限制每個文檔傳遞的大小，可以改善性能，尤其是在處理大文檔且只需要每個文檔一部分數據的場景下。
本文版權歸作者所有，未經作者同意不得轉載,謝謝配合！！！
本文版權歸作者所有，未經作者同意不得轉載,謝謝配合！！！
