Apresentando o FTS com N1QL

Tópicos que este artigo abordará

1. O que há de bom no N1QL?
2. E quanto ao FTS?
3. Mas por que o FTS dentro do N1QL?
4. Consultas básicas N1QL+FTS
5. Implantação do N1QL+FTS
   1. Sintaxe(s)
   2. Habilidades e limitações
6. N1QL+FTS Internos
7. Consultas com índice coberto vs. consultas sem índice coberto
8. Mais exemplos de consultas N1QL+FTS
9. O que vem a seguir?

1. O Couchbase N1QL

• N1QL é a oferta de SQL do Couchbase para manipular dados JSON armazenados no servidor couchbase.
• As instruções N1QL podem ser usadas para criar, modificar, eliminar índices e selecionar, inserir, atualizar, excluir e fazer upsert de dados em documentos JSON.
• As expressões N1QL permitem que o usuário execute operações de agregação, aritméticas, de coleta, de comparação, condicionais e várias outras.
• Tudo isso vem com o suporte de índices secundários para permitir essas operações com muita eficiência.

2. O Couchbase FTS

• A oferta de pesquisa de texto completo do Couchbase fornece recursos abrangentes para consultas em linguagem natural e destina-se a permitir que os usuários pesquisem texto em vários campos em documentos JSON armazenados em um servidor couchbase.
• Ele suporta pesquisa com reconhecimento de idioma e resultados de pontuação com base na relevância que pode ser configurada pelo usuário.
• O FTS configura índices rápidos que são especialmente projetados e destinados a lidar com uma ampla gama de cargas de trabalho de pesquisa de texto com muita eficiência.

3. Por que apoiar o FTS via N1QL?

• As consultas N1QL podem realizar uma pesquisa em cadeias de caracteres, números, matrizes etc. e com indexação secundária (índice b-tree) - também suportam pesquisas de pontos e varreduras de intervalos, mas o FTS oferece desempenho para pesquisa de texto (consultas compostas simples e complexas) com o suporte de seu índice invertido subjacente.
• Os aplicativos precisam ter a capacidade de aproveitar ambos os recursos usando uma única API e uma única linguagem.
• Suporte a operações compostas/complexas, como a aplicação de agregações, aritmética e outras operações SQL sobre os resultados do FTS para facilitar o desenvolvimento.
• Ampliar a visibilidade do FTS (mais do que apenas via SDK, curl ou interface do usuário do Couchbase).

4. N1QL + FTS

O Couchbase 6.5 oferecerá suporte à interface proposta entre o N1QL e o FTS. O usuário ainda precisará configurar os índices do FTS para dar suporte ao seu caso de uso, assim como com GSI (Indexação Secundária Global). Com essa nova interface, os usuários poderão mesclar e executar consultas FTS a partir de consultas N1QL sem problemas.

Um novo predicado SEARCH(...) agora será suportado como parte da sintaxe de consulta N1QL. Antes de entrar nos detalhes internos do que acontece quando uma consulta N1QL com o predicado SEARCH(...) é executada, aqui há alguma documentação sobre como criar e gerenciar índices FTS e aqui estão alguns exemplos de consultas ...

Por exemplo, digamos que eu tenha um índice FTS configurado em alguns documentos de viagem e queira buscar os resultados do FTS (apenas ids) para todos os documentos que contenham "San Francisco" no campo de cidade ...

Como você pode ver acima, a string de consulta FTS 'city: "San Francisco"' está incorporada na consulta N1QL. Como alternativa, a consulta N1QL também suportará um objeto de consulta FTS, como ...

O exemplo acima limitará o conjunto de resultados do FTS a 10.

Ou até mesmo um objeto de solicitação de pesquisa do FTS.

O exemplo acima também limita o conjunto de resultados a 10, mas o FTS o aplicará.

Os filtros OFFSET/LIMIT podem ser definidos na sintaxe da consulta N1QL ou no objeto de solicitação de pesquisa do FTS. Se esses parâmetros forem definidos na solicitação de pesquisa do FTS, o FTS transmitirá apenas o número solicitado de resultados. Os parâmetros N1QL serão aplicados a todos os resultados enviados pelo FTS. Se essas configurações não estiverem definidas no objeto FTS, mas estiverem definidas na consulta N1QL, o FTS transmitirá todos os resultados para o N1QL até que o N1QL tenha recebido todos os resultados necessários.

Além disso, como nos três últimos exemplos, não é necessário especificar explicitamente o nome do índice FTS a ser escolhido - o N1QL determinará qual é o melhor índice entre os disponíveis para executar a consulta FTS. Se alguém quiser que o N1QL use um índice específico (por exemplo, um índice chamado "travel"), veja como ...

Observe que, em todas as consultas de exemplo acima, os resultados são transmitidos e não são classificados com base na relevância (pontuação - comportamento padrão do FTS). A classificação pode ser obtida declarando-a explicitamente na solicitação de pesquisa ou usando o ORDER BY cláusula. A paginação dos resultados também pode ser obtida apenas com a declaração explícita na solicitação de pesquisa ou usando a cláusula DESLOCAMENTO e LIMITE cláusulas.

5. Implantação do N1QL + FTS

• Para permitir consultas N1QL com o recurso SEARCH(...), o cluster do couchbase precisa ter pelo menos um nó que execute o serviço Search e um nó que execute o serviço Query (esses dois serviços também podem ser configurados no mesmo nó).
• Os índices FTS devem ser configurados pelo usuário para indexar o conteúdo necessário que se deseja pesquisar.
• Se nenhum índice FTS for encontrado pelo N1QL para executar a consulta, ele procurará por índices GSI que possam potencialmente lidar com a consulta. Nesse caso, o predicado SEARCH(...) é aplicado aos resultados intermediários obtidos. Embora isso funcione, não é a abordagem recomendada, pois a avaliação SEARCH(...) pode ser cara.
• As consultas N1QL com SEARCH(..) podem ser executadas a partir do query workbench, curl, SDK ou da interface de linha de comando que o couchbase oferece.

5.1 Sintaxe de pesquisa

Aqui está o que é compatível com a função SEARCH(, , [options])...

5.2 Habilidades e limitações

• Todos os recursos que as solicitações de pesquisa do FTS oferecem serão compatíveis com as consultas do N1QL.
• Aqui são alguns destaques sobre o que colocar na seção "query" (consulta) dentro da função SEARCH(...).
• Os índices FTS que suportam mapeamentos de vários tipos não serão permitidos na primeira versão da interface N1QL+FTS para que os falsos positivos não entrem sorrateiramente no conjunto de resultados.

Implementação interna

Internamente, a interface N1QL+FTS suporta 4 APIs que o serviço N1QL invocará durante suas fases de preparação e execução para consultas com o predicado SEARCH(..).

Antes de descrever as APIs acima com um pouco mais de detalhes, aqui está um fluxograma das operações compatíveis com a interface .

6.1 Sargível

Essa API de índice FTS será usada para determinar se o índice é capaz de lidar com a solicitação de consulta sem retornar falsos negativos. Na primeira versão, o índice só será escolhido se todos os campos da consulta estiverem indexados nele ou se o índice tiver em sua definição um mapeamento dinâmico que atenda a todos os campos solicitados. Se vários índices forem avaliáveis para uma determinada consulta, será escolhido aquele que tiver o menor número de campos indexados que satisfaçam a cláusula de avaliabilidade (por motivos de desempenho).

6.2 Paginável

Essa API será usada para determinar se os resultados obtidos do índice FTS subjacente serão pagináveis ou não. Se o índice for paginável, o N1QL aplicará os filtros (offset, limite, informações de classificação) para o FTS antes de emitir o Search(...); caso contrário, os filtros serão aplicados no conjunto de resultados depois que o FTS for enviado a ele.

Observe que essa API não será chamada se não houver filtros (offset, limite, order by) na consulta N1QL.

6.3 Pesquisa

Essa API é invocada para o índice mais visível e é essencialmente responsável por obter a solicitação de pesquisa para o índice FTS e transmitir os resultados de volta por meio de um canal. Se a quantidade de dados a serem transmitidos exceder o tamanho do buffer disponível na extremidade do canal do N1QL, o FTS preencherá os dados em um arquivo e uma rotina separada será responsável pela transmissão desse conteúdo para o N1QL. Isso é feito para que os recursos do FTS não sejam retidos por uma conexão lenta do N1QL. Internamente, o protocolo gRPC é usado para transmitir dados do FTS para o N1QL.

6.4 Verificar:Avaliar

Essa API é usada pelo N1QL para garantir que os resultados/hits retornados por um índice FTS sejam de fato válidos para a consulta. O FTS retorna apenas os IDs de chave e alguns metadados relacionados ao FTS (se solicitado), como pontuação etc. O N1QL buscou documentos do KV e invoca o Verify para eles se o predicado SELECT solicitar alguns campos do documento.

Consultas com índice coberto vs. consultas sem índice coberto

Se o predicado da instrução SELECT solicitar apenas chaves ou metadados, a API Verify não será chamada. Esse tipo de consulta é chamado de consulta de índice coberto. Se a solicitação for para algum outro conteúdo de documento, o N1QL usará as chaves retornadas pelo FTS para buscar os dados do documento na KV e, em seguida, invocará o método Verify para cada um dos documentos buscados para verificar novamente se os documentos recuperados são de fato correspondências válidas. Esse tipo de consulta é chamado de consulta de índice não coberto. As consultas de índice não coberto tendem a ter latências mais altas do que as consultas de índice coberto, pois envolvem a busca e a verificação de KV para cada hit.

Se o usuário exigir que outros campos dos documentos façam parte do conjunto de resultados, uma abordagem mais rápida seria ajustar a definição do índice FTS para armazenar os campos desejados. Agora, na solicitação de pesquisa dentro da função SEARCH(...), inclua uma seção chamada "fields": ["*"] para buscar todos os campos armazenados como parte do conjunto de resultados. Dessa forma, o N1QL não precisará fazer uma busca de documento separada e poderá ignorar a verificação também => essencialmente convertendo uma consulta de índice não coberto em uma consulta de índice coberto ao custo de um índice FTS maior.

Considere a seguinte definição de índice FTS com os campos "country" e "content" indexados.

Aqui está um exemplo de uma consulta de índice não coberto mais lenta que busca o campo de documento "content" (conteúdo) para documentos que têm "united states" (estados unidos) em seu campo "country" (país)...

Vamos atualizar a definição do índice para armazenar também o campo "content" (conteúdo), que é de interesse...

Agora, aqui está a mesma consulta que se qualifica como uma consulta de índice coberto.

Mais exemplos de N1QL+FTS

8.1 Consultas mais complexas

Execução de uma pesquisa FTS de conjunção/disjunção composta em uma consulta N1QL ... buscar os 100 principais IDs de documentos ordenados por pontuação (tf-idf ... que é o algoritmo de pontuação padrão do FTS) da mais alta para a mais baixa, cuja categoria é marco e o país é Estados Unidos...

Aqui está uma consulta equivalente com configurações FTS incorporadas na função SEARCH(...) ...

Execução de outra consulta com configurações de FTS incorporadas na função SEARCH(...) ... buscar todos os IDs de documentos que contenham em seu campo de descrição o termo gótico sem considerar a pontuação. Aqui podemos otimizar a solicitação de pesquisa do FTS para não determinar a pontuação...

Os vários tipos de consulta FTS suportados são descritos em mais detalhes aqui.

8.2 Capacidade de consulta versus definições de índice

Antes de entrarmos em alguns exemplos de como as consultas são consideradas passíveis de definições de índice FTS, saiba mais sobre as definições de índice FTS aqui.

Considere a seguinte consulta, que procura o termo "gothic" (gótico) no campo "description" (descrição).

No sistema couchbase em questão, vamos supor que existam vários índices FTS definidos.

O primeiro índice FTS que encontramos tem a seguinte definição ...

Esse índice é chamado de índice dinâmico padrão, que abrange todos os campos disponíveis em todos os documentos e também inclui conteúdo dentro do campo padrão "_all". Esse campo padrão é o que é examinado quando uma consulta FTS não contém informações de "campo" para um critério de pesquisa. Esse índice é considerado SARGABLE para a consulta acima.

Um segundo índice FTS tem a seguinte definição ...

Esse índice tem apenas o campo "description" indexado, o que atenderia à solicitação da consulta e, portanto o índice é SARGABLE para a consulta.

Um terceiro índice FTS tem a seguinte definição ...

Esse índice tem alguns campos indexados, mas nenhum deles corresponde ao campo solicitado "description". Esse índice é considerado NOT-SARGABLE para a consulta.

O N1QL agora tem a opção de selecionar entre os dois primeiros índices que serão capazes de fornecer resultados precisos para a consulta. Como o número de campos indexados no segundo índice é preciso e menor (e, portanto, como a pesquisa nesse índice seria mais rápida), o N1QL escolhe o segundo índice para a execução da consulta.

Futuro

• Estabelecer melhor a possibilidade de venda, apoiando alguma flexibilidade das definições do índice FTS - como nos índices FTS que não suportam todos os campos solicitados.
• Suporte para índices FTS com mapeamentos de vários tipos.
• Ampliação da interface de consulta N1QL para editar índices FTS.