Menu Docs
Página inicial do Docs
/
MongoDB Atlas
/ /

Desempenho de índices do Atlas Search

Nesta página

  • Requisitos de recursos
  • Tamanho e configuração do índice
  • Considerações
  • Criar e atualizar um índice do Atlas Search
  • Consistência eventual e latência de indexação
  • Explosões de mapeamento de documentos
  • Armazenar campos de origem
  • Considerações sobre dimensionamento
  • Atualização do Atlas Search
  • Elevar o desempenho de indexação
  • Alteração de configurações do Atlas Cluster

Importante

Se você criar um índice do Atlas Search para uma coleção que tem ou terá em breve mais de 2.100.000.000 objetos de índice, você deve fragmentar seu cluster.

Quando você cria um índice do Atlas Search, o mapeamento de campo é padronizado como dinâmico, o que significa que o Atlas Search indexa dinamicamente todos os tipos de dados que podem ser indexados dinamicamente em sua collection. Outras opções, como ativar destaques, também podem fazer com que seu índice ocupe mais espaço em disco. Você pode reduzir o tamanho e o impacto de desempenho do seu índice Atlas Search fazendo o seguinte:

  • Especificar uma definição de índice personalizada para restringir a quantidade e o tipo de dados indexados.

  • Definindo a opção store para false ao especificar um tipo de string em uma definição de índice.

Observação

Algumas limitações se aplicam ao Atlas Search somente em clusters M0, M2 e M5. Para saber mais, consulte Limitações de nível grátis e compartilhadas do Atlas Search.

Algumas opções de configuração de índice podem levar a índices que ocupam uma proporção significativa do espaço em disco. Em alguns casos, o seu índice pode ser muitas vezes maior do que o tamanho dos seus dados. Embora esse seja o comportamento esperado, é importante estar ciente das seguintes funcionalidades de indexação intensiva:

O operador de preenchimento automático do Atlas Search pode ser usado para criar uma funcionalidade semelhante à pesquisa à medida que você digita no seu aplicativo. O tipo de campo autocomplete do Atlas Search pode gerar índices grandes, especialmente nos seguintes casos:

  • Usando a tokenização nGram.

  • Configurando um amplo intervalo de minGrams a maxGrams .

  • Definindo um valor minGram de 1 em uma collection com milhões de documentos.

É possível reduzir o espaço usado pelo índice de tipo autocomplete fazendo o seguinte:

  • Reduza a faixa de minGrams e maxGrams para o mínimo. Geralmente, recomendamos definir maxGrams como o número de caracteres da palavra mais longa no campo que você deseja fazer query. Se não tiver certeza, para campos no idioma inglês, recomendamos começar com um valor maxGrams de 10.

  • Evite a estratégia de tokenização nGram pois, para uma determinada string, o Atlas Search cria mais tokens para nGram do que para tokenização edgeGram ou rightEdgeGram .

Ao indexar um campo string como o tipo preenchimento automático, recomendamos que você também indexe o campo como o tipo string do Atlas Search pelas seguintes vantagens:

O Atlas Search para de replicar alterações para índices maiores que 2.100.000.000 objetos de índice, em um conjunto de réplicas ou único fragmento, em que cada documento incorporado indexado conta como um único objeto. O uso do tipo de campo embeddedDocuments pode resultar na indexação de objetos acima desse limite, o que faz com que um índice passe para um estado consultável Stale e pode resultar em resultados obsoletos.

O número exato de objetos de índice pode variar com base na taxa de alterações e exclusões de documentos. A métrica Pesquisar número máximo de Lucene Docs fornece o limite superior do número atual de objetos de índice em todos os índices por conjunto de réplicas ou fragmento. Você pode aproximar o número esperado de objetos de índice em um único índice fazendo o seguinte:

  1. Calcule o número de objetos de índice por documento. Para cada nível de aninhamento, cada documento incorporado conta como um objeto de índice separado.

    total number of index objects = 1 + number of nested embedded documents
  2. Multiplique o número de objetos de índice por documento pelo número total de documentos na coleção

    total number of index objects x total number of documents in collection

Observe que essa aproximação é um limite inferior.

Exemplo

Considere a coleção nomeada schools, descrita neste tutorial, e considere que a coleção contém 1000 documentos semelhantes ao seguinte:

{
"_id": 0,
"name": "Springfield High",
"mascot": "Pumas",
"teachers": [
{
"first": "Jane",
"last": "Smith",
"classes": [
{
"subject": "art of science",
"grade": "12th"
},
... // 2 more embedded documents
]
},
... // 1 more embedded document
],
"clubs": {
"stem": [
{
"club_name": "chess",
"description": "provides students opportunity to play the board game of chess informally and competitively in tournaments."
},
... // 1 more embedded document
],
... // 1 more embedded document
}
}

Agora, considere a definição do índice para os seguintes campos na coleção schools:

A array de documentos denominados teachers é indexada como o tipo embeddedDocuments com mapeamentos dinâmicos habilitados. No entanto, o campo classes não é indexado. Use o seguinte para calcular os objetos de índice:

  1. Calcula o número de objetos de índice por documento.

    Number of ``teachers`` embedded documents = up to 2
    Total number of index objects per document = 1 + 2 = 3
  2. Multiplique pelo número total de documentos na coleção.

    Number of documents in the collection = 1000
    Number of index objects per document = 3
    Total number of index objects for collection = 1000 x 3 = 3000

As arrays de documentos denominadas teachers e teachers.classes são indexadas como o tipo embeddedDocuments com mapeamentos dinâmicos habilitados. Use o seguinte para calcular os objetos de índice:

  1. Calcule o número de objetos de índice por documento:

    Number of documents = 1
    Number of ``teachers`` embedded documents = up to 2
    Number of ``classes`` embedded documents = up to 3
    Number of index objects per document = 1 + ( 2 x 3 ) = 7
  2. Multiplique pelo número total de documentos na coleção.

    Number of documents in the collection = 1000
    Number of index objects per document = 7
    Total number of index objects: 1000 x 7 = 7000

Se sua coleção tiver grandes arrays que possam gerar 2.100.000.000 objetos de índice, você deve fragmentar todos os clusters que contenham índices com o tipo embeddedDocuments.

Se você quiser filtrar e facetar seus dados usando o mesmo campo, recomendamos indexar o campo conforme os seguintes tipos do Atlas Search:

Para ver um exemplo de filtragem dos dados por outro campo para fazer faceta, consulte o tutorial Como usar facetas com o Atlas Search.

Usar um analisador multi para analisar o mesmo campo de várias maneiras diferentes pode gerar grandes índices, especialmente ao analisar campos com valores muito longos.

Você pode usar os Atlas Search Language Analyzers para indexar muitos idiomas. Para obter a lista de idiomas para os quais o Atlas Search fornece analisadores integrados, consulte Analisadores de idiomas. Para um exemplo, consulte o tutorial Como Executar Queries de Pesquisa Multilingue do Atlas. Para indexar e consultar idiomas que não estão atualmente na lista de Analisadores de Linguagem integrados , você pode criar um analisador personalizado. Para ver um exemplo, consulte o Exemplo do Custom Language Analyzer.

Suponha que você tenha um documento para cada idioma em sua coleção. Considere o seguinte:

  • Você pode indexar os campos separadamente no mesmo índice usando os analisadores de idioma. Um único índice pode ter suporte para vários idiomas na mesma query.

  • Como alternativa, você pode criar um índice por idioma, o que é útil para isolar os diferentes documentos de idiomas. Observe que cada índice é um cursor de fluxo de alterações e, portanto, pode ser caro mantê-lo.

  • Se você tiver documentos de linguagem aninhados em um documento principal, poderá criar um único índice. No entanto, a carga útil da definição do índice pode ser grande e a query pode ser complexa.

Para saber mais sobre esses modelos de dados e definições de índice, consulte o MongoDB Blog.

As inserções e atualizações de uma coleção de fontes de sinônimos serão rápidas somente se a coleção de fontes de sinônimo for pequena. Para obter o melhor desempenho, recomendamos inserir e atualizar em lote as coleções de origem de sinônimos.

Uma definição de mapeamento de sinônimos não exige mais espaço em disco além do espaço em disco usado pela collection de sinônimos no banco de dados. No entanto, mapeamentos de sinônimos criam artefatos na memória e, portanto, para collections de sinônimos com muitos documentos, o Atlas Search cria artefatos que consomem mais memória.

A criação de um índice do Atlas Search exige muitos recursos. O desempenho do seu agrupamento do Atlas pode ser afetado enquanto o índice é desenvolvido.

O Atlas replica todas as gravações da coleção. Isso significa que, para cada coleção com índices do Atlas Search, as gravações são ampliadas para a quantidade de índices do Atlas Search definidos para essa coleção.

Em alguns casos, seu índice do Atlas Search deve ser reconstruído. Reconstruir o índice do Atlas Search também consome recursos e pode afetar o desempenho do banco de dados. O Atlas Search reconstrói automaticamente o índice apenas no caso de:

  • Alterações na definição do índice

  • Atualizações de versão do Atlas Search que incluem alterações significativas

  • Problemas relacionados ao hardware, como corrupção de índice

Observação

O Atlas Search suporta indexação sem tempo de inatividade, o que significa que você pode continuar a executar consultas de query enquanto o Atlas Search reconstrói seu índice. O Atlas Search mantém seu índice antigo atualizado enquanto o novo índice está sendo criado. Recomendamos alocar espaço livre em disco igual a 125% do espaço em disco usado pelo índice antigo para essa operação. Você pode visualizar a quantidade de espaço em disco usado atualmente pelo seu índice na métrica Pesquisar espaço em disco usado.

Se a reconstrução do índice falhar devido a espaço em disco insuficiente, recomendamos que você expanda temporariamente a capacidade do cluster para atender ao aumento da demanda. Você pode fazer essa alteração manualmente, conforme descrito em Corrigir problemas de armazenamento, mesmo para clusters com dimensionamento automático habilitado.

Se você implantou nós de pesquisa separados, o Atlas implantará automaticamente nós de pesquisa adicionais durante a reconstrução do índice e você não precisará alocar nenhum espaço livre adicional em disco.

Depois que o Atlas Search reconstrói o índice, o índice antigo é automaticamente substituído sem nenhuma ação adicional da sua parte.

O Atlas Search aceita a consistência eventual e não fornece garantias de consistência mais sólidas. Isso significa que os dados inseridos em uma collection do MongoDB e indexados pelo Atlas Search não estarão disponíveis imediatamente para queries do $search.

O Atlas Search lê dados de fluxos de alterações do MongoDB e indexa esses dados em um processo assíncrono. Esse processo geralmente é muito rápido, mas, às vezes, pode ser afetado pela latência de replicação, a disponibilidade de recursos do sistema e a complexidade da definição de índices. Um grande número de índices do Atlas Search também pode contribuir para o atraso de replicação e a latência dos índices do Atlas Search.

Mapeamento de explosões ocorrem quando o Atlas Search indexa um documento com chaves arbitrárias e você tem um mapeamento dinâmico. O processo mongot pode consumir quantidades cada vez maiores de memória e travar. Se você adicionar muitos campos a um índice, podem ocorrer explosões de mapeamento. Para resolver esse problema, você pode atualizar o cluster ou usar um mapeamento estático que não indexe todos os campos nos dados.

Ao pesquisar campos usando um caminho curinga, crie sua pesquisa para usar um esquema semelhante a uma tupla. Se você fizer uma pesquisa com um caminho curinga que use um esquema de valor-chave, o Atlas Search indexará cada chave como seu próprio campo, o que pode causar explosões de mapeamento.

Exemplo

Segue um exemplo de esquema de valor-chave:

ruleBuilder: {
ruleName1: <data>,
ruleName2: <data>,
.....
ruleName1025: <data>
}

Um exemplo dos mesmos dados reestruturados para usar um esquema de tupla é o seguinte:

{
ruleBuilder: [
{name: ruleName1, data: <data>},
{name: ruleName2, data: <data>},
...
{name: ruleName1025, data: <data>}
]
}

Você pode configurar campos para armazenar no Atlas Search e melhorar o desempenho de estágios do pipeline de agregação subsequentes como $sort, $match, $group e $skip. Use essa otimização se os documentos originais e o conjunto de dados correspondentes forem tão grandes que uma pesquisa de dados completa seja ineficiente. Para saber mais sobre como armazenar campos específicos na Atlas Search e retornar somente esses campos armazenados, consulte Definir campos de origem armazenados no seu índice do Atlas Search e Retornar campos de origem armazenados.

Recomendamos armazenar somente o número mínimo de campos necessários para as fases subsequentes. Se necessário, você pode usar $lookup no final da fase do pipeline para recuperar documentos inteiros conforme mostrado nos exemplos. Armazenar campos desnecessários aumenta a utilização do disco e pode afetar negativamente o desempenho durante a indexação e a query.

O Atlas Search é implantado no seu cluster Atlas. Quando uma nova versão do Atlas Search é implantada, seu cluster Atlas pode apresentar breves falhas de rede no retorno dos resultados da consulta. Para mitigar problemas durante a implantação e minimizar o impacto em seu aplicativo, considere o seguinte:

  • Implemente a lógica de repetição em seu aplicativo.

  • Configurar janelas de manutenção do Atlas.

    Observação

    As atualizações do Atlas Search iniciam somente durante o período de manutenção e podem continuar após esse período.

Para saber mais sobre as alterações em cada versão, consulte Atlas Search Changelog.

Você pode ampliar a sincronização inicial e a indexação de estado constante de um índice do Atlas Search atualizando o cluster para um nível mais alto com mais núcleos. O Atlas Search utiliza uma porcentagem de todos os núcleos disponíveis para executar a sincronização inicial e a indexação de estado constante, e o desempenho melhora à medida que novos núcleos são disponibilizados com a atualização do cluster.

Se você reconfigurar seu sistema para usar o tipo de armazenamento local do NVMe ou fazer upscale de um cluster baseado em NVMe, o Atlas Search executará uma sincronização inicial de todos os índices do Atlas Search configurados após cada nó completar sua configuração subjacente ou ação de upscale. Se a sincronização inicial do índice do Atlas Search demorar mais do que o tempo que levou para completar a alteração de configuração do cluster, você não poderá executar queries do $search até a conclusão da sincronização inicial em todos os nós no seu Atlas cluster.

Recomendamos distribuir nós de pesquisa dedicados para dimensionar seu cluster do Atlas e suas cargas de trabalho $search de forma independente. Os nós de pesquisa dedicados executam somente o processo mongot e, portanto, melhoram a disponibilidade, o desempenho e o balanceamento da carga de trabalho do processo mongot.

Voltar

Melhore o desempenho