MongoDB 數據庫的命名和設計也有一套規范。只不過，由于用的人不多，目前在業界還沒有形成權威的共識，今天根據我個人平時的一些經驗，總結了一些規范

第一部分，我們先說命名規范。

文檔

設計約束

UTF-8 字符

不能包含 \0 字符(空字符)，這個字符標識建的結尾

. 和 $ 有特殊含義，需要避免

區分大小寫

鍵不能重復

鍵/值對有序

實踐約束

【強制】文檔中的key禁止使用_以外的特殊字符

【強制】key全部小寫，多個單詞可以下劃線分割

【強制】禁止使用數字打頭的key

【強制】禁止自定義_id（_id一般自增，使用無序id極有可能降低寫入性能）

【建議】相似類型文檔放在一個集合中，能大幅提高索引利用率

【建議】若業務上對于存放數據大小寫不敏感，則使用全部大寫/小寫存放（或者增加一個統一了大小寫寫的輔助字段）。 使用忽略大小寫的查詢極其耗費性能

【建議】不要存放太長的字符串

注意：MongoDB 索引僅支持 1KB 以內的字段

【強制】禁止使用數字打頭的key

【強制】禁止自定義_id（_id一般自增，使用無序id極有可能降低寫入性能）

【建議】相似類型文檔放在一個集合中，能大幅提高索引利用率

【建議】若業務上對于存放數據大小寫不敏感，則使用全部大寫/小寫存放（或者增加一個統一了大小寫寫的輔助字段）。 使用忽略大小寫的查詢極其耗費性能

【建議】不要存放太長的字符串

注意：MongoDB 索引僅支持 1KB 以內的字段

集合

設計約束

UTF-8 字符

不能是空字符串(“”)

不能包含 \0 字符(空字符)，這個字符標識集合名的結束

不能以 “system.” 開頭，這是為系統保留的前綴

不在集合中包含字符 “$”

使用 “.” 來分隔不同命名空間的子集合，如一個博客可能包含兩個子集合，blog.posts和blog.authors，而blog本身可以不存在

實踐約束

【強制】禁止使用_以外的特殊字符

【強制】集合名稱不超過64字符

【強制】集合名稱全部小寫

【強制】禁止使用數字打頭的集合名，禁止使用system打頭的集合名（system為系統集合前綴）

【建議】為了避免庫級鎖帶來的問題，應盡量對寫入較大的集合使用“單庫單集合”的結構，所以對于新增業務應盡量創建新庫，而不是在現有庫中創建新集合

數據庫

設計約束

UTF-8 字符

不能是空字符串(“”)

基本上只能使用 ASCII 中的字母和數字。

不能含有 /、\、.、”、*、、>、:、|、?、$、(空格)、\0(空字符)

全部使用小寫。（支持大寫，不建議使用）

不超過64字節

存在保留數據庫如：admin、local、config

注意：數據庫名稱限制主要是由于數據庫最終會變成文件系統里的文件，而數據庫名就是相應的文件名，因此才有很多約束

實踐約束

【強制】數據庫名稱全部小寫

【強制】數據庫名稱不超過64字符

【強制】禁止使用_以外的特殊字符

【強制】禁止使用數字打頭的數據庫名

【強制】禁止與保留的數據庫重名，如： admin，local，config等

索引

【強制】索引名稱長度不超過128字節

【強制】禁止在數組字段上創建索引

【強制】創建組合索引時，盡量將數據基數大（唯一值多的數據）的字段放在組合索引前面

查詢

【建議】先做等值查詢，再做排序，再做范圍查詢

【建議】查詢中的某些 $ 操作符可能會導致性能低下，盡量避免

注意：

ne，ne， ne，ne，not，exists，exists， exists，exists，nin，$or，盡量在業務中不要使用

$exist：因為松散的文檔結構導致查詢必須遍歷每一個文檔

$ne：如果當取反的值為大多數，則會掃描整個索引

$not：可能會導致查詢優化器不知道應當使用哪個索引，所以會經常退化為全表掃描

$nin：全表掃描

$or：有多少個條件就會查詢多少次，最后合并結果集，所以盡可能的使用 $in

命名空間

將數據庫名添加到集合前，得到集合的完全限定名，稱為命名空間（namespace），如cms數據庫的blog.posts集合，命名空間即為：

cms.blog.posts。實際使用中命名空間長度不得超過100字節。

第二部分，設計規范。

數據庫設計規范

數據庫名約定為小寫。

數據庫名稱不能包含除'_'以外的特殊字符，例如：/ \ . “ $。

數據庫名稱最多為64個字符。

數據庫上線需經過DBA評審。

集合設計規范

集合名稱約定為小寫。

集合名稱不能包含除‘'以外的特殊字符字符；集合名稱禁止以system.開頭。

集合名稱的最大長度為64個字符，包括前綴的【database.】內容。

集合名稱的命名規則和MySQL數據庫表的命名規則相同。 a) 同一模塊的集合盡可能使用相同的前綴名，集合名稱盡可能表達用途。 b) 數據表 模塊標識>表標識> 例如：order_header , order_detail

c) 編碼表 base_模塊標識>表標識> d) 日志表 log模塊標識>表標識>

固定集合可以用于記錄日志，其插入數據更快，可以實現在插入數據時，淘汰最早的數據。固定集合需要顯式創建，指定Size的大小，還能夠指定文檔的數量。集合不管先達到哪一個限制，之后插入的新文檔都會把最老的文檔移出。

索引命名：idx構成索引的字段名>。如果字段名字過長，可采用字段縮寫。

文檔設計規范

Key的命名規范：不能以$開頭;不能包含.(點號)。

文檔中的_id鍵推薦使用默認值，禁止向_id中保存自定義的值。MongoDB文檔中都會有一個“_id”鍵，默認是個ObjectID對象（標識符中包含時間戳、機器ID、進程ID和計數器）。MongoDB在指定_id與不指定_id插入時速度相差很大，指定_id會減慢插入的速率。

推薦使用短字段名。與關系型數據庫不同，MongoDB集合中的每一個文檔都需要存儲字段名，長字段名會需要更多的存儲空間。

禁止在同一個集合字段中存儲多個數據類型的數據。

如若將日期類型選擇為string,不同的日期格式的文檔，不支持等值查詢，不支持范圍查詢。創建一個測試集合product，分別向集合插入Date:”20180425″和Date:”2018-04-25″兩筆數據。等值查詢、范圍查詢（$gte, $lte）只能查到日期格式相同的數據，都為一筆數據。

MongoDB大小寫敏感，如果字段無需大小寫敏感，為了提高查詢效率，應盡量在統一了大小寫之后再插入到數據庫中。

MongoDB是文檔型數據庫，數據以BSON形式存儲在文檔中。MongoDB能夠支持最大16 MB的文檔大小。建議盡量不要存儲大型對象，將文檔控制在16 MB以內。

通過$size查詢數組大小，但是$size運算符不使用索引和限制準確匹配（不能指定$Sized 范圍）。因此，如果需要基于數組的大小執行查詢，可以在文檔設計中增加size屬性。例如在商品評價中，其他人可以對評價進行投票。為了阻止用戶多次投票和對有幫助的評論進行排序，所以，評價文檔設計是：在一個數組字段（voter_ids）保存了所有評論用戶的ID，而數組大小緩存在helpful_votes字段里。

分片鍵必須有索引，分片鍵大小限制為512byte，一旦集合已經分片，不可以直接修改分片鍵。不接受向已進行分片的collection上插入無分片鍵的文檔，也不支持空值插入。

片鍵的設計原則：

a) 所有的插入、更新、刪除將會均勻發送到集群的所有分片中。

b) 所有的查詢將會在集群中的所有分片中均勻地分發。

c) 所有的更新或者刪除操作將會只面向相關的分片，不會發送到一個沒有存儲被修改數據的分片上。

d) 一個查詢將不會被發送到沒有存儲被查詢數據的分片上。

連接規范

正確連接副本集，副本集提供了數據的保護、高可用和災難恢復的機制。如果主節點宕機，其中一個從節點會自動提升為從節點。

合理控制連接池的大小，限制連接數資源，可通過Connection String URL中的maxPoolSize 參數來配置連接池大小。Mongod 的服務模型是每個網絡連接由一個單獨的線程來處理，每個線程配置了1MB 的棧空間，當網絡連接數太多時，過多的線程會導致上下文切換開銷變大，同時內存開銷也會上漲。

復制集讀選項。默認情況下，復制集的所有讀請求都發到Primary，Driver可通過設置的Read Preference 來將讀請求路由到其他的節點。

a) Primary:默認規則，所有讀請求發到Primary。

b) PrimaryPreferred: Primary優先，如果Primary不可達，請求Secondary。

c) Secondary：所有的讀請求都發到Secondary。

d) SecondaryPreferred：Secondary優先，當所有的Secondary不可達時，請求Primary。

e) Nearest：讀請求發送到最近的可達節點上（通過ping探測得出最近的節點）。

操作規范

MongoDB數據庫更新文檔有兩種實現方式—文檔替換和目標字段更新。既可以完整替換現有的文檔，也可以使用更新操作符來修改某個字段。使用操作符，例如$set操作符和$push操作符，無論原始的大小，可以更新文檔里的指定字段。頻繁文檔更新的場景下，使用目標更新可以在序列化和傳輸數據上花費更少的時間，獲得更好的性能。

多文檔更新，在默認情況下，只會更新匹配查詢器的第一個文檔。要更新所有的匹配文檔，需要顯式指定多文檔更新模式–添加參數multi:true。

在文檔級別更新是原子性的，這意味著一條更新10個文檔的語句可能在更新3個文檔后由于某些原因失敗。應用程序必須根據自己的策略來處理這些失敗。

update結合upsert可以用來處理，當文檔存在時更新，文檔不存在時插入。如果查詢選擇器匹配，更新就正常執行；如果沒有匹配的文檔，就會插入新的文檔。新文檔的字段是查詢選擇器和目標更新文檔的邏輯合并。

復制集的數據安全及寫策略，Write Concern 用于控制寫入安全的級別。Write Concern 是一個性能和數據一致性的權衡，應根據業務場景進行設定。對于強一致性場景，建議w>1或者等于majority。

聚合框架是MongoDB的高級查詢語言，它允許通過轉換和合并由多個文檔中的數據來生成新的單個文檔里不存在的文檔信息。可以把MongoDB的聚合框架等價于SQL的Group By 語句。

更多關于MongoDB 數據庫的文章大家可以點擊下面的相關鏈接