ApsaraDB for MongoDB:Problemas de desempenho causados por excesso de bancos de dados e coleções

Remover coleções desnecessárias

Identifique coleções no banco de dados que podem ser excluídas, como aquelas expiradas ou que não estão mais em uso. Utilize o comando dropCollection para removê-las. Para mais informações, consulte dropCollection().

Utilize os seguintes comandos para visualizar informações sobre bancos de dados e coleções:

• Execute o comando abaixo para ver a quantidade de coleções em um banco de dados.

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

• Execute este comando para obter informações detalhadas sobre um banco de dados, incluindo o número de coleções, índices e documentos, além do tamanho total dos dados.

  // View statistics for a specific database.
  db.getSiblingDB(<dbName>).stats()

• Use o comando a seguir para ver detalhes específicos de uma coleção.

  // View statistics for a specific collection.
  db.getSiblingDB(<dbName>).<collectionName>.stats()

Remover índices desnecessários

Reduzir a quantidade de índices diminui também o número de arquivos em disco e as estruturas dhandle correspondentes mantidas pelo mecanismo de armazenamento WiredTiger, ajudando a mitigar esse problema.

Siga estes princípios básicos para otimização de índices:

• Evite índices não utilizados

  Se uma consulta nunca acessa um campo específico, qualquer índice nesse campo não será usado. Tais índices são considerados inutilizados e podem ser removidos.

• Respeite as regras de prefixo de índice

  Por exemplo, se você tiver os índices {a:1} e {a:1,b:1}, o primeiro é um prefixo redundante do segundo e pode ser removido.

• Considere a ordem dos campos do índice para consultas de igualdade

  Para correspondências de igualdade, a ordem dos campos em um índice composto não importa. Por exemplo, para consultas nos campos a e b, os índices {a:1,b:1} e {b:1,a:1} são funcionalmente equivalentes. Você pode remover aquele que é usado com menos frequência.

• Use a regra ESR para consultas de intervalo

  Para criar um índice composto ideal para suas consultas, organize os campos na ordem de Equality, Sort, Range. Para mais informações, consulte The ESR (Equality, Sort, Range) Rule.

• Revise índices com baixa contagem de acertos

  Um índice com poucos acertos geralmente se sobrepõe a um índice mais eficiente. Analise todos os padrões de consulta relevantes para determinar se é seguro removê-lo.

É possível usar o estágio de agregação $indexStats do MongoDB para visualizar estatísticas de todos os índices em uma coleção. Certifique-se de ter as permissões necessárias antes de executar o comando abaixo.

// View index statistics for a specific collection.
db.getSiblingDB(<dbName>).<collectionName>.aggregate({"$indexStats":{}})

O comando retorna uma saída semelhante ao exemplo a seguir.

{
   "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")
   }
}

A tabela a seguir descreve os parâmetros nas informações retornadas.

Caso observe que um índice tem uma contagem de acertos muito baixa, por exemplo, se accesses.ops for 1, provavelmente trata-se de um índice redundante ou não utilizado que pode ser considerado para exclusão. Se sua instância MongoDB for versão 4.4 ou superior, use o comando hideIndex para ocultar o índice antes de excluí-lo. Isso permite confirmar que não há impacto negativo na sua aplicação por um período, reduzindo o risco da exclusão do índice.

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

Consolidar dados de múltiplas coleções

Consolide dados de várias coleções em uma única coleção para reduzir a contagem total de coleções.

Por exemplo, um banco de dados chamado temperatures armazena dados de temperatura de sensores. Um sensor opera das 10:00 às 22:00, lendo e armazenando dados de temperatura a cada meia hora. Ele guarda os dados de temperatura de cada dia em uma coleção separada, nomeada conforme a data.

Os trechos abaixo mostram dados parciais de duas coleções, temperatures.march-09-2020 e temperatures.march-10-2020.

• Coleção 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
  }

• Coleção 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
  }
  

Com o tempo, o número de coleções no banco de dados aumenta. Como o MongoDB não impõe um limite rígido para a quantidade de coleções e esse modelo carece de uma política clara de ciclo de vida dos dados, o número de coleções e seus índices correspondentes cresce indefinidamente.

Além do problema do crescimento contínuo do número de coleções, esse modelo de dados dificulta a execução de consultas que abrangem vários dias. Para consultar dados ao longo de vários dias e analisar tendências de temperatura de longo prazo, seria necessário usar consultas $lookup, que têm desempenho inferior comparado a consultas dentro de uma única coleção.

Um modelo de dados melhor consiste em armazenar todas as leituras de temperatura em uma única coleção, com os dados de cada dia armazenados em um único documento. Essa abordagem é um exemplo do Bucket Pattern. O exemplo a seguir mostra o modelo otimizado.

// 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
    }
  ]
}

O modelo otimizado consome muito menos recursos que o modelo original. Não é mais necessário criar índices baseados na hora do dia, e o índice padrão _id na coleção facilita consultas por data. Isso também resolve o problema de um número ilimitado de coleções.

Dividir a instância

Se não for possível reduzir o número total de bancos de dados e coleções dentro de uma única instância MongoDB, considere uma divisão lógica da instância do banco de dados, juntamente com as alterações correspondentes na sua aplicação.

Você pode abordar isso em dois cenários:

Migrar para um cluster fragmentado com shard tags

Se todas as suas coleções estiverem em um único banco de dados e você quiser gerenciá-las como uma única instância lógica, considere migrar seus dados para uma arquitetura de cluster fragmentado e usar shard tags para gerenciamento. O método de gerenciamento por shard tag é um pouco mais complexo e requer etapas operacionais extras (usando sh.addShardTag e sh.addTagRange). No entanto, uma única instância MongoDB ainda gerencia todas as coleções, exigindo mudanças mínimas na sua aplicação. Você só precisa substituir a string de conexão pela da nova instância de cluster fragmentado.

Por exemplo, se sua instância tem 100.000 coleções ativas, você pode adquirir uma nova instância de cluster fragmentado com 10 shards. Siga o processo abaixo para configurar a instância e migrar os dados, o que resultará em 10.000 coleções ativas por shard. O procedimento é o seguinte:

1. Adquira uma nova instância de cluster fragmentado. Este exemplo usa uma instância com 2 shards. Para instruções sobre como criar um cluster fragmentado, consulte Criar uma instância de cluster fragmentado.

2. Conecte-se ao nó mongos da instância de cluster fragmentado. Para mais informações, consulte Conectar-se a uma instância de cluster fragmentado do ApsaraDB for MongoDB usando o mongo shell.

3. Execute os comandos abaixo para adicionar uma shard tag a cada shard.

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

   Nota

   • Antes de executar esses comandos, certifique-se de que a conta em uso tenha as permissões necessárias.

   • O DMS (Data Management) atualmente não suporta o comando sh.addShardTag. Recomendamos conectar-se à instância com o mongo shell ou mongosh para executar esses comandos.

4. Pré-configurar as regras de distribuição de intervalo baseadas em tags para todas as coleções fragmentadas.

   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")

   Este exemplo usa _id como chave de fragmentação. Escolha uma chave de fragmentação adequada à sua carga de trabalho e garanta que todas as operações de consulta incluam o campo da chave de fragmentação. A chave de fragmentação deve ser consistente com o campo usado na próxima etapa. Você também deve usar os limites [MinKey,MaxKey] para garantir que todos os dados de uma única coleção residam em um único shard.

5. Executar a operação shardCollection para todas as coleções a serem migradas.

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

6. Execute o comando sh.status() para confirmar que as regras estão em vigor.

   zhongli.test
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag1  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
   zhongli.test1
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag2  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. Migrar dados de uma instância de conjunto de réplicas para uma instância de cluster fragmentado.

   Nota

   Como você já pré-fragmentou as coleções na instância de destino, todas as informações de bancos de dados e coleções já existem. Portanto, você deve definir o Processing Mode of Conflicting Tables como Ignore Errors and Proceed na sua tarefa DTS.

8. Após verificar a consistência dos dados, altere suas aplicações para acessar a nova instância de cluster fragmentado.

Migrar para um cluster fragmentado com zonas

Este método é semelhante ao uso de shard tags, mas utiliza o recurso Zones do MongoDB. Requer etapas operacionais extras, especificamente sh.addShardToZone() e sh.updateZoneKeyRange().

O procedimento é o seguinte:

1. Adquira uma nova instância de cluster fragmentado. Este exemplo usa uma instância com 2 shards. Para instruções sobre como criar um cluster fragmentado, consulte Criar uma instância de cluster fragmentado.

2. Conecte-se ao nó mongos da instância de cluster fragmentado. Para mais informações, consulte Conectar-se a uma instância de cluster fragmentado do ApsaraDB for MongoDB usando o mongo shell.

3. Execute os comandos abaixo para atribuir cada shard a uma zona.

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

   Nota

   • Antes de executar esses comandos, certifique-se de que a conta em uso tenha as permissões necessárias.

   • O DMS atualmente não suporta o comando sh.addShardToZone. Recomendamos conectar-se à instância com o mongo shell ou mongosh para executar esses comandos.

4. Pré-configurar as regras de distribuição de intervalo baseadas em zonas para todas as coleções.

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

   Este exemplo usa _id como chave de fragmentação. Escolha uma chave de fragmentação adequada à sua carga de trabalho e garanta que todas as operações de consulta incluam o campo da chave de fragmentação. A chave de fragmentação deve ser consistente com o campo usado na próxima etapa. Você também deve usar os limites [MinKey,MaxKey] para garantir que todos os dados de uma única coleção residam em um único shard.

5. Executar a operação shardCollection para todas as coleções a serem migradas.

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

6. Execute o comando sh.status() para visualizar a distribuição da fragmentação e confirmar que a configuração de zona está em vigor. A saída de exemplo é a seguinte:

   {  "_id" : "shardDistributionDB",  "primary" : "d-xxx24",  "partitioned" : false,  "version" : {  "uuid" : UUID("1dc635xxx"),  "lastMod" : 1 } }
           shardDistributionDB.test
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2ze9797089ef3704      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx04 Timestamp(1, 0)
                    tag: ZoneA  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
           shardDistributionDB.test1
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2zed2e752c35af24      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx24 Timestamp(1, 0)
                    tag: ZoneB  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. Migrar dados de uma instância de conjunto de réplicas para uma instância de cluster fragmentado.

   Nota

   Como você já pré-fragmentou as coleções na instância de destino, todas as informações de bancos de dados e coleções já existem. Portanto, você deve definir o Processing Mode of Conflicting Tables como Ignore Errors and Proceed na sua tarefa DTS.

8. Após verificar a consistência dos dados, altere suas aplicações para acessar a nova instância de cluster fragmentado.