Já vimos algumas práticas recomendadas para definir um Índice FTS na parte 1Agora, vamos explorar algumas dicas úteis sobre os aspectos operacionais e de manutenção de um índice.
Um usuário que é novo no Recuperação de informações(RI) pode achar o processo de definição de índices do FTS um pouco tedioso, especialmente com a configuração do pipeline de análise de texto para um índice. Você pode ficar sobrecarregado com a sobrecarga de informações de todos os jargões de RI, como filtros de caracteres, tokenizadores e outros. inúmeros filtros de tokens como shingles, ngrams, edge_ngrams etc. Essas opções são infinitas quando você começa a configurar um analisador de texto personalizado. Depois que você define um índice com um analisador personalizado/integrado, devido a todas essas complexidades inerentes mencionadas anteriormente, torna-se uma tarefa cada vez mais complicada prever e verificar o resultado dos analisadores configurados.
Agora, você pode se perguntar por que uma visão detalhada do resultado da análise de texto é importante?
Isso é muito importante, pois a maioria dos usuários de pesquisa se depara com a seguinte pergunta durante sua experiência inicial com qualquer sistema de pesquisa de texto completo,
Qn. Por que a pesquisa não está retornando nenhum resultado, mesmo que eu tenha definido o índice de acordo com as diretrizes e saiba que os tokens de pesquisa existem nos documentos?
Isso ocorre principalmente devido a,
- Uma falha nos analisadores configurados na definição do índice - faz com que a tokenização ou a curadoria dos dados seja contrária às suas expectativas, ou seja, os tokens emitidos pelos analisadores (ou indexados no sistema) não são os que você espera que sejam.
- Sem saber, você escolheu um analisador diferente durante o tempo de pesquisa, em comparação com o que está definido de acordo com o mapeamento de campo na definição do índice.
O texto do documento é analisado quando é gravado no índice e, separadamente, os termos de pesquisa também são analisados quando se realiza uma pesquisa. Normalmente, por padrão, os analisadores de campo especificados na definição do índice serão escolhidos para analisar o conteúdo da consulta se for uma consulta com escopo de campo.
Para ajudar a facilitar a compreensão e a correção do pipeline de análise de índices, o FTS introduziu um endpoint de descanso na versão 6.5.0, /api/index/{indexName}/analyzeDoc que aceita um documento json no corpo da solicitação e retorna uma resposta json que contém os tokens analisados de acordo com os analisadores configurados com o índice fornecido.
Você pode usar esse endpoint para explorar e depurar os resultados do analisador em seus ambientes de desenvolvimento ou de preparação. Esse endpoint é seguro até mesmo para ser testado em um sistema de produção. A resposta mostra literalmente os tokens que teriam sido indexados como parte do índice se você tivesse indexado documentos semelhantes. Você pode usar o mesmo endpoint para verificar a saída da análise de consulta passando apenas o campo de consulta junto com o texto da consulta como o documento json com um tipo de documento correspondente, conforme definido pelo mapeamento do tipo de índice.
Para corrigir a incompatibilidade do analisador entre o índice e o tempo de consulta, você deve usar consultas com escopo de campo ou substituir os analisadores durante o tempo de consulta, pois muitas consultas oferecem uma opção para isso.
Qn. Como você sabe se o cluster FTS está dimensionado corretamente?Ignposts para detectar um cluster com provisionamento insuficiente?
O dimensionamento do cluster geralmente inclui a configuração de recursos suficientes do sistema, como cota de memória RAM/FTS, capacidade de processamento da CPU e a topologia correta do cluster. A topologia do cluster inclui ainda o número de partições e o número de nós adequados para um determinado volume de dados e a carga de consulta/indexação. Temos visto muitos de nossos clientes acabarem usando clusters subdimensionados sem seguir nenhuma diretriz de dimensionamento. Não vamos entrar em detalhes sobre o dimensionamento aqui, pois esse é um tópico muito específico para cada caso de uso do cliente. Recomenda-se que os usuários entrem em contato com a equipe do Couchbase para obter ajuda com as diretrizes de dimensionamento personalizadas para seus respectivos requisitos.
Mas há alguns indicadores fáceis já incorporados ao sistema que podem indicar que seu cluster está com provisionamento insuficiente.
- Progresso de indexação realmente lento, mesmo na ausência de qualquer carga de consulta ou mutações constantes de documentos.
- As consultas de pesquisa estão sendo rejeitadas com o código de status http 429. Isso mostra que seu sistema está com uma cota de memória FTS insuficiente.
- Muitas consultas lentas nos gráficos de estatísticas podem indicar um dimensionamento inadequado ou consultas de pesquisa abaixo do ideal.
As consultas abaixo do ideal aqui se referem àquelas consultas que não foram cuidadosamente escritas para obter os melhores resultados com as cláusulas de pesquisa corretas. Algumas vezes, vimos clientes tentando consultas compostas complexas com mais de 250 subconsultas. A maior ineficiência que se esconde aqui é que o sistema de pesquisa tem que varrer uma grande faixa de dados indexados (principalmente de discos) para obter os resultados corretos, em comparação com uma consulta mais bem direcionada que obteria os mesmos resultados apenas com uma área de superfície menor do índice. Isso resulta em um uso muito melhor dos recursos do sistema.
