Desde que o mais ágil e refinado queimar lançado no Couchbase 6.0.0, a equipe do FTS ficou bastante empolgada com o potencial de otimização futuro revelado com o esquema de indexação mais recente. Com a versão 6.5.0, embarcamos essencialmente em uma jornada sem fim de otimização e ajuste do desempenho do mecanismo de pesquisa de texto completo.
Deixe-me compartilhar algumas informações sobre as otimizações interessantes que estamos introduzindo na próxima versão 6.5.0.
Consultas geográficas
O FTS oferece suporte a dois tipos de consultas geográficas Distância de pontos e retângulo delimitado. Desde o início do recurso, não tivemos a chance de revisar e aprimorar esse recurso, embora fosse quase certo que a implementação da consulta precisasse de melhorias em termos de utilização da memória e da CPU. A boa notícia é que, de todos os aprimoramentos de desempenho futuros na versão 6.5.0, vimos os maiores ganhos com as alterações geográficas.
Oportunidade
Como parte da análise do alto uso de memória pelas consultas geográficas, ficou claro que há um enorme potencial de ajuste de desempenho que ainda não foi explorado. No caso dos tipos de consulta de distância de ponto e retângulo delimitado, o mecanismo de indexação (sangrar) precisa descobrir o intervalo de pontos geográficos a serem pesquisados (termos candidatos) que qualificam os critérios de pesquisa a partir dos parâmetros de consulta fornecidos. O Bleve deriva esses termos geográficos candidatos por meio de determinadas etapas matemáticas.
Mas ele não estava fazendo nenhuma filtragem dos termos geográficos candidatos gerados matematicamente. Em outras palavras, uma amplificação não intencional do espaço de pesquisa estava ocorrendo em segundo plano. E isso estava desencadeando a criação de muitos iteradores de pesquisa de termos desnecessários ou irrelevantes (por exemplo, termos que nem sequer existem no índice), o que leva a muitos objetos temporários internos para gerenciar e, além disso, adiciona uma grande sobrecarga ao coletor de lixo.
Resposta
Otimizamos esse caso aplicando uma filtragem de termos geográficos que basicamente valida os pontos geográficos gerados matematicamente quanto à sua existência no dicionário de termos e os qualifica somente se estiverem presentes no dicionário de termos. Essa abordagem reduziu significativamente o número de pontos geográficos/termos candidatos que estão sendo pesquisados no índice invertido e, portanto, melhorou os números de latência e taxa de transferência para consultas geográficas.
Recompensa
Isso resultou em uma melhoria de até 6X redução de latência para consultas geográficas em nossos benchmarks internos.
Consultas difusas
Em pré queimar dias, quando um fuzzy/edit-distance Quando a consulta é recebida, o mecanismo de indexação examina todos os termos indexados em relação ao campo determinado na consulta para calcular a distância de edição e descobrir se o termo atual está dentro da distância de edição solicitada com o termo da consulta. E se ele se qualificar para esse critério de distância de edição, ele procurará o termo no índice invertido para buscar a lista de documentos em que o termo aparece e os detalhes necessários, conforme exigido pela consulta. (vetores de termos, valores de documentos etc)
O recente formato de indexação scorch usa FiniteStateTransducers(FST) para implementar o Dicionário de Termos, que tem o seguinte DFA propriedade. Isso nos ajudou a aprimorar a abordagem novata para encontrar os termos candidatos em uma determinada distância de edição da consulta.
A abordagem é criar um Levenshtein Automaton(LA) para o termo dado na consulta de distância de edição. Esse LA é um DFA que tem a propriedade de corresponder a todos os termos que estão, no máximo, a uma distância de edição de um determinado "d" na consulta. E esse LA DFA seria então feito para se juntar ou fazer uma interseção com o corpus de termos indexados/dicionário de termos original (FST DFA) para filtrar os termos candidatos que precisam ser eventualmente pesquisados como parte da consulta.
Oportunidade
Até o lançamento da versão 6.0, estávamos criando o LA DFA novamente a cada consulta recebida, e essa parte da construção do LA DFA acabou sendo desgastante em termos de uso de memória e velocidade da construção do DFA.
Resposta
Inspirado no original papel e a postagem no blog - LevenshteinA construção mais recente do autômato de Levenshtein adota uma abordagem de duas etapas. Na primeira etapa, ele pré-computa um DFA paramétrico para um conjunto de distâncias de edição predefinidas* e essa parte é completamente independente da string de consulta e, portanto, pode ser pré-computada. Na segunda etapa, esse DFA paramétrico é usado para calcular o DFA LA por consulta. Isso faz com que a construção do DFA seja bastante rápida e fácil de usar na memória.
Recompensa
Os benchmarks do Go micro mostraram que a implementação mais recente é capaz de 5X mais rápido e 12X melhor no uso da memória. E, em nossos testes internos de desempenho, isso trouxe até ~50% melhorias no rendimento da consulta.
Fico feliz em ver que você rolou a tela até aqui.
Vou fazer uma parada abrupta aqui para facilitar sua atenção e guardar as histórias restantes para a Parte 2. A próxima parte abordará os ganhos de desempenho com a adoção do gRPC no FTS, bem como com consultas como intervalo numérico, prefixo, curinga etc.
… Parte 2
{Distâncias de edição pré-definidas => no momento, o FTS suporta distâncias de edição de até 2, ou seja, apenas 1 e 2.
A principal razão para isso é que, em qualquer corpus de documentos de tamanho razoável, haverá muitos termos que correspondem a uma distância de edição > 2 do termo de consulta. Portanto, qualquer pesquisa adicional no índice se torna muito intensiva em termos de recursos, além de diminuir a relevância da pesquisa}.
