庫設計規范

• 數據庫命名規范：db_xxxx。
• 庫名全部小寫，盡量不要使用任何_以外的特殊字符，盡量使用數字打頭的庫名，如：123_abc。庫以文件夾的形式存在，使用特殊字符或其它不規范的命名方式會導致命名混亂。
• 數據庫名稱最多為 64 個字符。
• 在創建新的庫前應盡量評估該庫的體積、QPS等，提前與DBA討論是應該新建一個庫還是專門為該庫創建一個新的集群。

集合設計規范

• 集合名全部小寫，禁止使用任何_以外的特殊字符，禁止使用數字打頭的集合名，如：123_abc，禁止system打頭; system是系統集合前綴。
• 集合名稱最多為64字符。
• 一個庫中寫入較大的集合會影響其它集合的讀寫性能，如果業務比較繁忙的集合在一個DB中，建議最多80個集合，同時也要考慮磁盤I/O的性能。
• 如果評估單集合數據量較大，可以將一個大表拆分為多個小表，然后將每一個小表存放在獨立的庫中或者sharding分表。
• 文檔數據庫服務的集合擁有”自動清理過期數據”的功能，只需在該集合中文檔的時間字段增加一個TTL索引即可實現該功能，但需要注意的是該字段的類型則必須是mongoDate()，一定要結合實際業務設計是否需要。
• 設計輪詢集合—集合是否設計為Capped限制集，一定要結合實際業務設計是否需要。

創建集合規則

不同的業務場景是可以使用不同的配置;

db.createCollection("logs",
{ "storageEngine": { "wiredTiger":
		      { "configString": "internal_page_max=16KB,leaf_page_max=16KB,leaf_value_max=8KB,os_cache_max=1GB"} }
})

• 如果是讀多寫少的表在創建時我們可以盡量將 page size 設置的比較小 ，比如 16KB，例如：“internal_page_max=16KB，leaf_page_max=16KB，leaf_value_max=8KB，os_cache_max=1GB”。
• 如果這個讀多寫少的表數據量比較大，可以為其設置一個壓縮算法，例如：”block_compressor=zlib， internal_page_max=16KB，leaf_page_max=16KB，leaf_value_max=8KB”。

文檔設計規范

• 集合中的 key盡量不要使用任何 “_”（下劃線）以外的特殊字符。
• 盡量將同樣類型的文檔存放在一個集合中，將不同類型的文檔分散在不同的集合中；相同類型的文檔能夠大幅度提高索引利用率，如果文檔混雜存放則可能會出現查詢經常需要全表掃描的情況。
• 盡可能不要使用 _id ，如：向 _id 中寫入自定義內容。
  文檔數據庫服務的表與InnoDB相似，都是索引組織表,數據內容跟在主鍵后，而 _id 是文檔數據庫服務中的默認主鍵,一旦 _id 的值為非自增，當數據量達到一定程度之后，每一次寫入都可能導致主鍵的二叉樹大幅度調整，這將是一個代價極大的寫入，所以寫入就會隨著數據量的增大而下降，所以一定不要在 _id 中寫入自定義的內容。
• 盡量不要讓數組字段成為查詢條件。
• 如果字段較大，應盡量壓縮存放。
  不要存放太長的字符串，如果這個字段為查詢條件，那么確保該字段的值不超過1KB；MongoDB的索引僅支持1K以內的字段，如果你存入的數據長度超過1K，那么它將無法被索引。
• 盡量存放統一了大小寫后的數據 。
• 如果評估單集合數據量較大，可以將一個大表拆分為多個小表，然后將每一個小表存放在獨立的庫中或者sharding分表。

索引設計規范

• 文檔數據庫服務的組合索引使用策略與 MySQL 一致，遵循”最左原則”。
• 索引名稱長度不要超過 128 字符。
• 應盡量綜合評估查詢場景,通過評估盡可能的將單列索引并入組合索引以降低所以數量，結合1，2點。
• 優先使用覆蓋索引。
• 創建組合索引的時候，應評估索引中包含的字段，盡量將數據基數大(唯一值多的數據)的字段放在組合索引的前面。
• 文檔數據庫服務支持 TTL 索引，該索引能夠按你的需要自動刪除XXX秒之前的數據并會盡量選擇在業務低峰期執行刪除操作；看業務是否需要這一類型索引。
• 在數據量較大的時候，文檔數據庫服務索引的創建是一個緩慢的過程，所以應當在上線前或數據量變得很大前盡量評估，按需創建會用到的索引。

分片設計規范

在文檔數據庫服務分片集群中，分片的設計規范是非常重要的，它可以影響集群的性能、可擴展性和可靠性。以下是一些常見的文檔數據庫服務分片設計規范：

• 分片鍵的選擇：分片鍵是用于分片集合的字段或字段組合。應該選擇具有高選擇性（即有區分度）的字段作為分片鍵，例如訪問頻率較高的字段或具有高度唯一性的字段。應該避免使用隨機值或低選擇性的字段作為分片鍵，因為這會導致數據分布不均衡，影響集群性能和可擴展性。
• 分片鍵的數據類型：分片鍵的數據類型應該選擇適合應用程序和數據的數據類型。例如，如果查詢經常使用時間戳，則可以將時間戳作為分片鍵，并選擇適合的日期時間數據類型。
• 分片鍵的范圍：分片鍵的范圍應該選擇適當的范圍，以便在數據分片時能夠均勻分布。例如，如果使用范圍查詢，則應該選擇具有大范圍的分片鍵，以便在多個分片上均勻分布數據。
• 分片集群的節點數：分片集群的節點數應該根據數據量、負載和可擴展性需求來選擇。通常建議將分片集群的節點數設置為2的冪次方，例如2、4、8、16等，以便更好地管理和維護集群。
• 避免 _id 作為分片鍵 。_id 通常是有序的,不太符合分布廣泛的要求。并且經常使用 _id 作為查詢條件，不利于分片。
• 分片的備份和恢復：在使用文檔數據庫服務分片集群時，應該定期備份和恢復數據，以保證數據的安全性和可靠性。可以使用文檔數據庫服務提供的備份和恢復工具或第三方工具來完成這些操作。

需要留意的是，在設計文檔數據庫服務分片集群時，應該根據具體的應用程序和文檔數據庫服務環境來選擇合適的分片設計規范。在分片集群的運維和維護過程中，應該遵循文檔數據庫服務的最佳實踐和規范，例如合理管理數據、監控集群性能和故障等。