ApsaraDB for MongoDB：庫表數太多導致執行個體卡頓或異常

移除不需要的集合

查詢資料庫中哪些集合是可以刪除的（例如已到期或業務不再使用的集合），通過dropCollection命令直接刪除這些無用表。關於刪除命令的介紹，請參見dropCollection()。

查看資料庫和集合資訊的命令如下：

• 執行以下命令查看資料庫中集合的數量。

  db.getSiblingDB(<dbName>).getCollectionNames().length

• 執行以下命令查看關於資料庫的具體資訊，包括集合的數量，索引的數量，文檔條數，總資料量大小等資訊。

  //查看某個庫的統計資訊
  db.getSiblingDB(<dbName>).stats()

• 執行以下命令查看某個集合的具體資訊。

  //查看某個表的統計資訊
  db.getSiblingDB(<dbName>).<collectionName>.stats()

移除不需要的索引

降低索引的數量也可以減少WiredTiger儲存引擎層維護的磁碟檔案以及相應的dhandle結構，同樣有助於緩解本問題。

索引最佳化的一些基本原則如下：

• 避免無用索引

  查詢根本不會訪問到的欄位，索引也自然不會命中，屬於無用索引，可以刪除。

• 索引的首碼匹配規則

  例如{a:1}和{a:1,b:1}兩個索引，前者就屬於首碼匹配的冗餘索引，可以刪除。

• 等值查詢時的索引欄位順序

  例如{a:1,b:1}和{b:1,a:1}兩個索引，在等值匹配中，順序並不會有影響，可以刪除其中叫用次數更少的一個。

• 範圍查詢時參考ESR規則

  根據實際的業務範圍查詢，按照quality, Sort, Range的順序來構造最優的複合索引。更多資訊，請參見The ESR Rule。

• review叫用次數低的索引

  叫用次數低的索引基本上都和另外一個高效索引存在一定的重複，需要結合業務的所有查詢模式來判斷是否可以刪除。

您可以通過MongoDB的$indexStats彙總階段來查看某個表中所有索引的統計資訊。請在確保有相關許可權的前提下，執行下面的命令。

//查看某個表的索引統計資訊
db.getSiblingDB(<dbName>).<collectionName>.aggregate({"$indexStats":{}})

返回樣本如下。

{
   "name" : "item_1_quantity_1",
   "key" : { "item" : 1, "quantity" : 1 },
   "host" : "examplehost.local:27018",
   "accesses" : {
      "ops" : NumberLong(1),
      "since" : ISODate("2020-02-10T21:11:23.059Z")
   }
}

返回資訊參數說明如下。

如果觀察到索引叫用次數很少（例如樣本中的accesses.ops為1），則很大機率該索引是冗餘索引或無用索引，可以考慮刪除。如果您的MongoDB執行個體版本為4.4及以上，為了進一步降低刪除索引的風險，您可以在dropIndex之前通過hiddenIndex命令先隱藏對應索引，確認一段時間內業務無異常後再進行索引刪除的操作。

// players collection
{
  "_id": "ObjectId(123)",
  "first_name": "John",
  "last_name": "Doe",
  "coins": 11,
  "stars": 2
}

整合多表資料

將多個集合中的資料整合到單個集合中以減少集合數量。

例如，資料庫中有一個temperatures庫，用來儲存從感應器獲得的所有溫度資料。感應器從上午10點工作到晚上10點，每半小時讀取一次當時的溫度資料並儲存在資料庫中。每一天的溫度資料存放在一個單獨的以日期為命名的集合中。

以下展示了2個集合（分別是temperatures.march-09-2020和temperatures.march-10-2020）的部分資料的內容。

• 集合temperatures.march-09-2020

  {
    "_id": 1,
    "timestamp": "2020-03-09T010:00:00Z",
    "temperature": 29
  }
  {
    "_id": 2,
    "timestamp": "2020-03-09T010:30:00Z",
    "temperature": 30
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-09T022:00:00Z",
    "temperature": 26
  }

• 集合temperatures.march-10-2020

  {
    "_id": 1,
    "timestamp": "2020-03-10T010:00:00Z",
    "temperature": 30
  }
  {
    "_id": 2,
    "timestamp": "2020-03-10T010:30:00Z",
    "temperature": 32
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-10T022:00:00Z",
    "temperature": 28
  }
  

隨著時間的推移，資料庫中的集合數量也在增加，由於MongoDB並沒有明確的集合數量上限，而且樣本中也並沒有明確的資料生命週期關係，因此資料庫所維護的集合數量及其相應索引數量不斷增長。

除了庫表數不斷上漲的問題，這種建模還不便於執行跨天查詢。若要查詢多天的資料以獲得較長時間內的溫度趨勢，您需要執行基於$lookup的查詢，其效能不如針對同一集合內的查詢。

更優的資料建模是將所有溫度讀數儲存在單個集合中，並將每天的溫度資料存放區在單個文檔中。最佳化後的樣本如下。

// temperatures.readings
{
  "_id": ISODate("2020-03-09"),
  "readings": [
    {
      "timestamp": "2020-03-09T010:00:00Z",
      "temperature": 29
    },
    {
      "timestamp": "2020-03-09T010:30:00Z",
      "temperature": 30
    },
    ...
    {
      "timestamp": "2020-03-09T022:00:00Z",
      "temperature": 26
    }
  ]
}
{
  "_id": ISODate("2020-03-10"),
  "readings": [
    {
      "timestamp": "2020-03-10T010:00:00Z",
      "temperature": 30
    },
    {
      "timestamp": "2020-03-10T010:30:00Z",
      "temperature": 32
    },
    ...
    {
      "timestamp": "2020-03-10T022:00:00Z",
      "temperature": 28
    }
  ]
}

最佳化後的模式需要消耗的資源比原始模式少得多。現在，您不再需要根據每天讀取溫度的時間建立索引，集合上的預設索引_id有助於按日期進行查詢。同時也解決了庫表數不斷增長的問題。

執行個體拆分

在MongoDB單一實例下總庫表數無法降低的情況下，可以考慮對該資料庫執行個體進行邏輯拆分並進行配套的業務整改。

可以分成以下兩種情境處理：

遷移到分區叢集執行個體並使用分區標籤（Shard Tag）來管理

如果所有的集合都集中在一個庫中，而且還希望通過一個邏輯上的資料庫執行個體來管理的話，您可以考慮將資料移轉到分區叢集架構並使用分區標籤（Shard Tag）來進行管理。shard tag管理方式稍微複雜一些，需要一些額外的營運操作（sh.addShardTag和sh.addTagRange），但所有的表依然由同一個MongoDB執行個體管理，業務上基本不需要改造，只需要將串連串替換為新的分區叢集執行個體的串連串即可。

假如您的執行個體中有10萬個活躍集合，可以新購一個10個Shard節點的分區叢集執行個體，通過以下流程完成設定並遷移資料，可實現每個Shard節點上各1萬個活躍集合。操作步驟如下：

1. 新購一個分區叢集執行個體，本文以2個分區的執行個體為例。如何建立分區叢集，請參見建立分區叢集執行個體。

2. 串連分區叢集執行個體的mongos節點，如何串連資料庫，請參見通過Mongo Shell串連MongoDB分區叢集執行個體。

3. 執行如下命令為所有分區添加標籤（Shard Tag）。

   sh.addShardTag("d-xxxxxxxxx1", "shard_tag1")
   sh.addShardTag("d-xxxxxxxxx2", "shard_tag2")

   說明

   • 執行相關命令前請確保您使用的賬戶具備相應的許可權。

   • DMS暫不支援sh.addShardTag，建議您使用mongo shell或者mongosh串連執行個體執行相關命令。

4. 為所有的分區表提前設定範圍的標籤分布規則。

   use <dbName>
   sh.enableSharding("<dbName>")
   
   sh.addTagRange("<dbName>.test", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag1")
   sh.addTagRange("<dbName>.test1", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag2")

   樣本中選擇_id作為分區鍵，實際使用時請按需選擇，確保所有的查詢操作都包含分區鍵欄位。分區鍵需要與下一個操作裡的欄位保持一致。同時需要使用[MinKey,MaxKey]的上下邊界，使得一個表的所有資料僅存在於單個分區上。

5. 對於所有的待遷移表都執行shardCollection操作。

   sh.shardCollection("<dbName>.test", {"_id":1})
   sh.shardCollection("<dbName>.test1", {"_id":1})

6. 通過sh.status()命令來確認相關規則已生效。

7. 將資料從複本集執行個體遷移到分區叢集執行個體中。

   說明

   由於已經在目標執行個體上進行了分區操作，所有庫表資訊已存在，因此需要配置目標已存在表的處理模式為忽略報錯並繼續執行。

8. 資料校正一致後將業務切換到訪問新的分區叢集執行個體。

遷移到分區叢集執行個體並使用分區（Zones）來管理

本方法與使用分區標籤管理方法類似，不過使用的是MongoDB的分區（Zones）功能，需要額外的營運操作（分別為sh.addShardToZone()以及sh.updateZoneKeyRange()）。

操作步驟如下：

1. 新購一個分區叢集執行個體，本文以2個分區的執行個體為例。如何建立分區叢集，請參見建立分區叢集執行個體。

2. 串連分區叢集執行個體的mongos節點，如何串連資料庫，請參見通過Mongo Shell串連MongoDB分區叢集執行個體。

3. 執行如下命令為所有分區指定分區（Zones）。

   sh.addShardToZone("d-xxxxxxxxx1", "ZoneA")
   sh.addShardToZone("d-xxxxxxxxx2", "ZoneB")

   說明

   • 執行相關命令前請確保您使用的賬戶具備相應的許可權。

   • DMS暫不支援sh.addShardToZone，建議您使用mongo shell或者mongosh串連執行個體執行相關命令。

4. 為所有的表提前設定範圍的分區分布規則。

   use <dbName>
   sh.enableSharding("<dbName>")
   
   sh.updateZoneKeyRange("<dbName>.test", { "_id": MinKey }, { "_id": MaxKey }, "ZoneA")
   sh.updateZoneKeyRange("<dbNmae>.test1", { "_id": MinKey }, { "_id": MaxKey }, "ZoneB")

   樣本中選擇_id為分區鍵，實際使用時請按需選擇，確保所有的查詢操作都包含分區鍵欄位。分區鍵需要跟下一個操作裡的欄位保持一致。同時需要使用[MinKey,MaxKey]的上下邊界，使得一個表的所有資料僅存在於單個分區上。

5. 對於所有的待遷移表都執行shardCollection操作。

   sh.shardCollection("<dbName>.test", { _id: "hashed" })
   sh.shardCollection("<dbName>.test1", { _id: "hashed" })

6. 通過sh.status()命令來確認相關規則已生效。

7. 將資料從複本集執行個體遷移到分區叢集執行個體中。

   說明

   由於已經在目標執行個體上進行了分區操作，所有庫表資訊已存在，因此需要配置目標已存在表的處理模式為忽略報錯並繼續執行。

8. 資料校正一致後將業務切換到訪問新的分區叢集執行個體。