dbasql

一、存儲引擎緩存：storage.wiredTiger.engineConfig.cacheSizeGB

1. 配置基礎

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: <數值>  # 單位：GB

• 默認規則：MongoDB 會自動分配緩存大小，公式為min(50%×系統內存 - 1GB, 256MB)，取兩者中的較大值。例如 16GB 內存的服務器，默認緩存為0.5×(16-1)=7.5GB。
• 核心作用：緩存用于存放未壓縮的熱點數據（工作集），避免頻繁從磁盤讀取數據，是提升讀性能的關鍵。

2. 性能影響與調整依據

// 1. 查看系統內存限制（單位：MB）
db.hostInfo().system.memLimitMB

// 2. 查看WiredTiger緩存詳細統計
db.serverStatus().wiredTiger.cache

3. 實踐建議

• 核心原則：緩存大小需能容納業務的 “工作集”（即高頻訪問的數據集），通常建議分配系統內存的 40%-60%（預留部分給操作系統和其他進程）。
• 例外場景：若 MongoDB 部署在容器或共享服務器上，需手動限制緩存（如 8GB 內存的容器，建議設為 4GB），避免內存溢出。

二、索引與數據分離：storage.wiredTiger.engineConfig.directoryForIndexes

1. 配置基礎

storage:
  wiredTiger:
    engineConfig:
      directoryForIndexes: <true/false>  # 默認false

• 功能生效：設為true后，MongoDB 會在storage.dbPath（數據庫根目錄）下創建兩個子目錄：
  • collection：存放集合數據文件；
  • index：存放索引文件。

2. 性能影響與適用場景

• 核心價值：索引 I/O（小而頻繁）與數據 I/O（大而偶發）分離，避免互相搶占磁盤讀寫資源，尤其適合 “索引查詢密集” 的業務（如電商商品搜索、用戶信息查詢）。
• 替代方案：若服務器只有單塊磁盤，開啟該配置收益有限 —— 此時通過 RAID 0 將磁盤條帶化，可達到類似的 I/O 分散效果。

3. 實踐建議

• 開啟時機：當服務器有多個物理磁盤或邏輯卷時，可將collection和index目錄掛載到不同卷上，最大化 I/O 并行性。
• 注意事項：該配置需在 MongoDB 實例初始化時設置，已運行實例修改后需遷移數據才能生效。

三、數據壓縮：storage.wiredTiger.collectionConfig.blockCompressor

1. 配置基礎

storage:
  wiredTiger:
    collectionConfig:
      blockCompressor: <壓縮算法>  # 可選：none、snappy、zlib、zstd

• 默認值：snappy（MongoDB 3.0+），兼顧壓縮率和 CPU 開銷。
• 壓縮邏輯：WiredTiger 緩存中存儲未壓縮數據（保證訪問速度），寫入磁盤時才進行壓縮，因此壓縮算法的選擇主要影響 “寫性能” 和 “磁盤占用”。

2. 四種壓縮算法對比

3. 實踐建議

• 寫入密集：優先選snappy，避免高 CPU 開銷拖慢寫入速度；
• 讀取密集 + 存儲緊張：選zstd，其解壓縮效率比 zlib 高 30% 以上，且壓縮率更優；
• 禁用場景：若數據本身是不可壓縮格式（如二進制文件），設為none可避免無效 CPU 消耗。

四、多數據庫目錄隔離：storage.directoryPerDB

1. 配置基礎

storage:
  directoryPerDB: <true/false>  # 默認false

• 功能生效：設為true后，MongoDB 會在storage.dbPath下為每個數據庫創建獨立目錄（以數據庫名命名）。
• 組合使用：若與directoryForIndexes配合，每個數據庫目錄下會進一步拆分collection和index子目錄，形成 “數據庫 - 數據 / 索引” 的二級隔離結構：

  - dbPath/
    - 電商庫/
      - collection/
      - index/
    - 日志庫/
      - collection/
      - index/
  

   

2. 性能影響與適用場景

• 核心價值：避免多數據庫共享磁盤時的 I/O 爭搶。例如 “日志庫” 的高頻寫入不會影響 “電商庫” 的查詢性能，尤其適合多業務共享 MongoDB 實例的場景。
• 管理優勢：便于按數據庫進行備份、遷移（直接復制對應目錄），降低運維復雜度。

3. 實踐建議

• 開啟時機：實例中存在 3 個以上數據庫，且部分數據庫有高 I/O 需求（如日志、實時數據）；
• 存儲搭配：可將高 I/O 數據庫目錄掛載到高性能磁盤（如 SSD），低 I/O 數據庫掛載到普通 HDD，平衡成本與性能。

五、網絡傳輸壓縮：net.compression.compressors

1. 配置基礎

net:
  compression:
    compressors: <壓縮算法列表>  # 可選：snappy、zlib、zstd，多算法用逗號分隔

• 默認規則：
  • MongoDB 3.6/4.0：默認snappy；
  • MongoDB 4.2+：默認snappy,zstd,zlib（按優先級排序，兩端協商最優算法）。
• 生效條件：網絡兩端（如 mongo shell 與 mongod）必須至少有一個共同支持的壓縮算法，否則不啟用壓縮。

2. 性能影響與適用場景

• 核心收益：減少網絡傳輸數據量，降低副本集同步延遲（尤其跨地域部署），同時在云環境中減少帶寬費用（如 AWS、阿里云的流量收費場景）。
• 潛在開銷：壓縮 / 解壓縮會消耗少量 CPU，但通常遠低于網絡延遲的優化收益。

3. 實踐建議

• 云環境 / 跨機房：優先啟用zstd（壓縮率高，帶寬節省更明顯）；
• 低延遲內網：若網絡延遲已低于 1ms，可僅啟用snappy（CPU 開銷最小）；
• 兼容性檢查：修改前需確認所有客戶端（如應用服務器、備份工具）支持所選壓縮算法，避免連接失敗。

六、配置優化總結：從 “參數調整” 到 “場景匹配”

1. 讀密集場景：優先優化緩存（cacheSizeGB）和數據壓縮（blockCompressor: zstd），減少磁盤 I/O 和數據傳輸量；
2. 寫密集場景：選擇低 CPU 開銷的壓縮（blockCompressor: snappy），避免緩存過大搶占內存；
3. 多業務共享實例：通過directoryPerDB和directoryForIndexes實現 I/O 隔離，避免業務間干擾；
4. 跨地域部署：啟用net.compression.compressors: zstd，降低網絡延遲和帶寬成本。