O Couchbase FTS é nosso novo mecanismo de consulta e índice de texto completo. Nós o apresentamos anteriormente no ano passado. Convido você a ler esta postagem e o documentação de referência para entender melhor o que ele pode fazer por você.

Se você ainda está aqui, ou talvez tenha voltado, veja o que há de novo para o FTS nesta versão para desenvolvedores do Couchbase.

Mapeamento de tipos

No passado, havia apenas uma maneira de declarar um mapeamento de tipo, que era informar ao FTS qual campo (por padrão, o campo "type") você deseja usar para distinguir os tipos de documentos. Embora usar um campo comum como seletor de tipo para todos os seus documentos seja útil e uma prática comum, essa não é a única. Portanto, adicionamos outra maneira de distinguir tipos entre documentos.

  • ID do DOC até o separador: O identificador de tipo é o prefixo da chave do documento, até o caractere fornecido, mas não o inclui.
  • ID do DOC com regex: Para usuários avançados, é possível especificar uma expressão regular que corresponda ao identificador de tipo.

Como isso se traduz em nossa amostra de viagem? Todas as chaves dos documentos têm o mesmo padrão. Aqui estão alguns exemplos:

airline_10, airline_10748, hotel_6445, hotel_9905, landmark_10019, landmark_9838, route_10009, route_14273, route_9807

Como você pode ver, todos eles começam com um tipo, depois um sublinhado e depois um número. Se usarmos o sublinhado como separador, todos eles começarão com o tipo String, depois o sublinhado e o número. Portanto, podemos usar a opção DOC ID até o separador, definindo a opção como '_'. Isso será equivalente a dizer que o campo que contém o tipo do documento é 'type'. Que é exatamente o que usamos para fazer.

Agora podemos identificar outro padrão aqui. Todas as IDs de DOC começam com letras minúsculas até o caractere de sublinhado. Seu comprimento é de 5 a 8 caracteres. Em seguida, temos números. Podemos traduzir essa observação na seguinte expressão regular: ^[a-z]{5,8}

Essa expressão corresponderá ao início da cadeia de caracteres (graças a ^), a todos os caracteres entre 'a' e 'z' (graças a [a-z]) com um comprimento que vai de 5 a 8 (graças a {5,8}).
Portanto, você pode usar a opção DOC ID com regex definindo a opção como ^[a-z]{5,8}. Regex às vezes são complicados, mas permitem que você faça filtragens mais avançadas.

Classificar

Outro novo recurso desta versão é o Sort. E você vai dizer que o Sort já estava disponível na versão anterior. E você está certo. Todos os documentos que correspondem à pesquisa têm uma pontuação de relevância e os resultados são sempre classificados por pontuação decrescente. No entanto, agora você pode especificar sua própria ordem de classificação. Adicionamos um campo de classificação para a consulta FTS que funciona da seguinte forma:

"sort" : [ "country", "state", "city", "-score" ]

Aqui, os resultados serão classificados primeiro por país, depois por estado e cidade se o país, o estado e a cidade forem semelhantes. Em seguida, se todos forem iguais, serão classificados de forma decrescente por pontuação. Prefixe os campos de classificação com o caractere "-" para que a classificação seja descendente. Você também precisa se certificar de que todos os campos da matriz de classificação estejam armazenados no índice. Esta é a aparência de uma consulta completa do FTS:

{ "explain": false, "fields": [ "title" ], "highlight": {}, "sort": ["country", "state", "city", "-score", "-_id"], "query":{ "query": "beautiful pool" } }

Se você estiver usando Java, digamos que o aplicativo de amostra de viagem por exemplo, é fácil adicionar o Sort personalizado. Basta abrir o serviço Hotel e acessar o método findHotels. Ele deve ter a seguinte aparência:

A consulta a ser executada é basicamente esta linha de código: SearchQuery query = new SearchQuery("hotels", fts).limit(100);
E tudo o que você precisa fazer é anexar uma chamada ao método de classificação: SearchQuery query = new SearchQuery("hotels", fts).limit(100).sort("country", "state", "city", "-score")

Opções mais avançadas também estão disponíveis.

Backend

Algo que mudou, mas não será visível para o usuário final, é que alteramos o backend dos índices do FTS. Deixamos de usar o ForestDB e passamos a usar o Musgo. o moss é uma biblioteca de armazenamento de chave-valor simples, rápida, ordenada e persistente para golang. significa "memory-oriented sorted segments". Aqui está a lista de recursos extraída do LEIAME:

  • API de coleta de chave-vale ordenada
  • 100% go implementation
  • iteradores de intervalo de chaves
  • Os snapshots permitem leituras isoladas
  • mutações atômicas por meio de uma API em lote
  • as operações de mesclagem permitem otimizações de leitura-computação-gravação para casos de uso de gravação pesada (por exemplo, atualização de contadores)
  • leitores e escritores concorrentes não se bloqueiam mutuamente
  • APIs avançadas e opcionais para evitar cópias extras de memória
  • implementação opcional de armazenamento de nível inferior, denominada "mossStore", que usa um design append-only para gravações e mmap() para leituras, com política de compactação configurável; consulte: OpenStoreCollection()
  • O mossStore suporta a navegação para trás através de pontos de confirmação anteriores em modo somente leitura e suporta a reversão para pontos de confirmação anteriores.
  • ganchos de persistência opcionais para permitir o armazenamento em cache de write-back em uma implementação de armazenamento de nível inferior que os usuários avançados podem desejar fornecer (por exemplo, você pode conectar o moss ao leveldb, sqlite etc.)
  • as chamadas de retorno de eventos permitem o monitoramento de tarefas assíncronas
  • testes unitários
  • testes de fuzz via go-fuzz e smat (github.com/mschoch/smat); veja README-smat.md

Não entrarei em detalhes, pois isso é de nível bastante baixo. No entanto, gostaríamos de saber se você busca mais informações sobre coisas arquitetônicas de baixo nível como essa. Você gostaria de ver uma apresentação mais detalhada do moss ou de qualquer outro componente do Couchbase Server? Em caso afirmativo, fale com você no Twitter ou nos comentários abaixo.

Autor

Postado por Laurent Doguin

Laurent é um nerd metaleiro que mora em Paris. Em sua maior parte, ele escreve código em Java e texto estruturado em AsciiDoc, e frequentemente fala sobre dados, programação reativa e outras coisas que estão na moda. Ele também foi Developer Advocate do Clever Cloud e do Nuxeo, onde dedicou seu tempo e experiência para ajudar essas comunidades a crescerem e se fortalecerem. Atualmente, ele dirige as Relações com Desenvolvedores na Couchbase.

Deixar uma resposta