Compartilhar via


Práticas recomendadas de indexação no Azure Cosmos DB for MongoDB vCore

APLICA-SE AO: MongoDB vCore

Os campos consultáveis ​​devem sempre ter índices criados

As operações de leitura baseadas em predicados e agregações consultam o índice para os filtros correspondentes. Na ausência de índices, o mecanismo de banco de dados executa uma varredura de documentos para recuperar os documentos correspondentes. As varreduras são sempre caras e ficam cada vez mais caras à medida que o volume de dados em uma coleção aumenta. Para um desempenho de consulta ideal, os índices devem sempre ser criados para todos os campos consultáveis.

Evite índices desnecessários e indexe todos os campos por padrão

Os índices devem ser criados apenas para campos consultáveis. A indexação de caracteres curinga deve ser usada somente quando os padrões de consulta são imprevisíveis, onde qualquer campo na estrutura do documento pode fazer parte dos filtros de consulta.

Dica

O Azure Cosmos DB for MongoDB vCore indexa apenas o campo _id por padrão. Todos os outros campos não são indexados por padrão. Os campos a serem indexados devem ser planejados com antecedência para maximizar o desempenho da consulta e, ao mesmo tempo, minimizar o impacto nas gravações decorrentes da indexação de muitos campos.

Quando um novo documento é inserido pela primeira vez ou um documento existente é atualizado ou excluído, cada um dos campos especificados no índice também é atualizado. Se a política de indexação contiver um grande número de campos (ou todos os campos do documento), mais recursos serão consumidos pelo servidor na atualização dos índices correspondentes. Ao executar em escala, apenas os campos consultáveis ​​devem ser indexados, enquanto todos os campos restantes não usados ​​nos predicados de consulta devem permanecer excluídos do índice.

Crie os índices necessários antes da ingestão de dados

Para um desempenho ideal, os índices devem ser criados antecipadamente, antes que os dados sejam carregados. Todas as gravações, atualizações e exclusões de documentos atualizarão de forma síncrona os índices correspondentes. Se os índices forem criados após a ingestão dos dados, mais recursos do servidor serão consumidos para indexar dados históricos. Dependendo do tamanho dos dados históricos, essa operação é demorada e afeta o desempenho de leitura e gravação em estado estacionário.

Observação

Para cenários em que os padrões de leitura mudam e os índices precisam ser adicionados, a indexação em segundo plano deve ser habilitada, o que pode ser feito por meio de um ticket de suporte.

Para vários índices criados em dados históricos, emita comandos createIndex sem bloqueio para cada campo

Nem sempre é possível planejar antecipadamente todos os padrões de consulta, principalmente à medida que os requisitos do aplicativo evoluem. A alteração das necessidades do aplicativo inevitavelmente exige que campos sejam adicionados ao índice em um cluster com uma grande quantidade de dados históricos.

Nesses cenários, cada comando createIndex deve ser emitido de forma assíncrona, sem aguardar uma resposta do servidor.

Observação

Por padrão, o Azure Cosmos DB for MongoDB vCore responde a uma operação createIndex somente depois que o índice é totalmente criado com base em dados históricos. Dependendo do tamanho do cluster e do volume de dados ingeridos, isso pode levar algum tempo e parecer que o servidor não está respondendo ao comando createIndex.

Se os comandos createIndex estiverem sendo emitidos por meio do Mongo Shell, use Ctrl + C para interromper o comando para parar de esperar por uma resposta e emitir o próximo conjunto de operações.

Observação

Usar Ctrl + C para interromper o comando createIndex após ele ter sido emitido não encerra a operação de criação de índice no servidor. Ele simplesmente impede que o Shell aguarde uma resposta do servidor, enquanto o servidor continua de forma assíncrona a construir o índice sobre os documentos existentes.

Crie índices compostos para consultas com predicados em vários campos

Os índices compostos devem ser usados ​​nos seguintes cenários:

  • Consultas com filtros em vários campos
  • Consultas com filtros em vários campos e com um ou mais campos classificados em ordem crescente ou decrescente

Considere o seguinte documento dentro do banco de dados “cosmicworks” e da coleção “employee”

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

Considere a seguinte consulta para encontrar todos os funcionários com sobrenome “Smith” na organização há mais de 5 anos:

db.employee.find({"lastName": "Smith", "timeInOrgInYears": {"$gt": 5}})

Um índice composto em “lastName” e “timeInOrgInYears” otimiza essa consulta:

use cosmicworks;
db.employee.createIndex({"lastName" : 1, "timeInOrgInYears" : 1})

Acompanhe o status de uma operação createIndex

Quando índices são adicionados e dados históricos precisam ser indexados, o progresso da operação de construção do índice pode ser rastreado usando db.currentOp().

Considere esse exemplo para acompanhar o progresso da indexação no banco de dados “cosmicworks”.

use cosmicworks;
db.currentOp()

Quando uma operação createIndex está em andamento, a resposta é semelhante a:

{
  "inprog": [
    {
      "shard": "defaultShard",
      "active": true,
      "type": "op",
      "opid": "30000451493:1719209762286363",
      "op_prefix": 30000451493,
      "currentOpTime": "2024-06-24T06:16:02.000Z",
      "secs_running": 0,
      "command": { "aggregate": "" },
      "op": "command",
      "waitingForLock": false
    },
    {
      "shard": "defaultShard",
      "active": true,
      "type": "op",
      "opid": "30000451876:1719209638351743",
      "op_prefix": 30000451876,
      "currentOpTime": "2024-06-24T06:13:58.000Z",
      "secs_running": 124,
      "command": { "createIndexes": "" },
      "op": "workerCommand",
      "waitingForLock": false,
      "progress": {},
      "msg": ""
    }
  ],
  "ok": 1
}

Habilitar chaves de índice grandes por padrão

Mesmo que os documentos não contenham chaves com um grande número de caracteres ou os documentos não contenham vários níveis de aninhamento, a especificação de chaves de índice grandes garante que esses cenários sejam cobertos.

Considere este exemplo para habilitar chaves de índice grandes na coleção “large_index_coll” no banco de dados “cosmicworks”.

use cosmicworks;
db.runCommand(
{
 "createIndexes": "large_index_coll",
 "indexes": [
    {
        "key": { "ikey": 1 },
        "name": "ikey_1",
        "enableLargeIndexKeys": true
    }
    ]
})

Priorizando construções de índice em vez de novas operações de gravação usando a opção de bloqueio

Para cenários em que o índice deve ser criado antes do carregamento dos dados, a opção de bloqueio deve ser usada para bloquear gravações de entrada até que a criação do índice seja concluída.

A configuração { "blocking": true } é particularmente útil em utilitários de migração onde os índices são criados em coleções vazias antes do início da gravação de dados.

Considere um exemplo da opção de bloqueio para criação de índice na coleção “employee” no banco de dados “cosmicworks”:

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"name":1}, "name":"name_1"}],
  blocking: true
})

Confira indexação de texto, que permite pesquisa e consulta eficientes de dados baseados em texto.

Próxima etapa