库表数太多导致实例卡顿或异常

移除不需要的集合

查询数据库中哪些集合是可以删除的（例如已过期或业务不再使用的集合），通过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. 数据校验一致后将业务切换到访问新的分片集群实例。