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
Requisitos de recursos
Tamanho e configuração do índice
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
parafalse
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.
Considerações
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:
Autocompletar
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
amaxGrams
.Definindo um valor
minGram
de1
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
emaxGrams
para o mínimo. Geralmente, recomendamos definirmaxGrams
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 valormaxGrams
de10
.Evite a estratégia de tokenização
nGram
pois, para uma determinada string, o Atlas Search cria mais tokens paranGram
do que para tokenizaçãoedgeGram
ourightEdgeGram
.
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:
Aumente a pontuação das correspondências exatas ao usar o operador de preenchimento automático. Para ver um exemplo, consulte o exemplo avançado no tutorial Como usar o preenchimento automático com o Atlas Search.
Consulte o mesmo campo na mesma query usando o operador autocomplete e outro operador que permita a pesquisa de string, como o operador text. Para obter um exemplo, consulte Pesquisar em vários campos.
Documentos incorporados
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:
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 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:
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 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:
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 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
.
Pesquisa facetada
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.
multi
Analisadores
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.
Pesquisa multilíngue
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.
Coleções de sinônimos
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.
Criar e atualizar um índice do Atlas Search
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.
Consistência eventual e latência de indexação
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.
Explosões de mapeamento de documentos
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>} ] }
Armazenar campos de origem
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.
Considerações sobre dimensionamento
Atualização do Atlas Search
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.
Elevar o desempenho de indexação
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.
Alteração de configurações do Atlas 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
.