Índice FTS Flex vs. índices GSI no Couchbase Server 6.6

Neste artigo, abordaremos alguns exemplos práticos, começando com consultas N1QL usando Índices GSI e simular um conjunto de dados que, ao longo do tempo, cresce não apenas com o tamanho do documento, mas também com o crescimento da estrutura real do documento. O Couchbase Server facilita o esquema flexível, mas quando novos campos e dados são adicionados, precisamos adicionar mais índices GSI e potencialmente mantê-los.

Recomendo a leitura de nosso Índices Flex após este artigo, caso ainda não o tenha feito; no entanto, esta postagem do blog abordará alguns exemplos práticos para que você se familiarize com o uso dos índices Flex.

A partir do Couchbase 6.5 (visualização antecipada) e agora com mais suporte na versão Lançamento do Couchbase 6.6Na versão mais recente, temos a capacidade de aproveitar os índices flexíveis. É uma ótima ferramenta para ser usada nos casos em que as condições não são predeterminadas e os predicados de pesquisa envolvem um grande número de campos. Vamos nos concentrar nessas situações. Usaremos o bucket de amostra de viagem para garantir que você possa começar a trabalhar e acompanhar facilmente.

Preparando nosso servidor e dados

Para começar, eu tenho Instalei o Couchbase Server 6.6 usando o Dockermas fique à vontade para instalar localmente, em Nuvem do Couchbaseou em sua plataforma de nuvem favorita se você desejar.

Quando o servidor Couchbase estiver em funcionamento, instalar a caçamba de amostras de viagem. Agora você deve ver 31.631 documentos disponíveis.

Também estão instalados os índices primário e GSI padrão para ajudá-lo a consultar esse conjunto de dados imediatamente.

Para as consultas que executaremos nos dados do hotel, usaremos apenas três dos índices que vemos instalados na guia Índices.

• • def_city
  • def_primary
  • def_type

Isso nos deixaria com três índices e poderíamos supor que, se nossa única intenção fosse consultar os registros de hotéis, eles seriam suficientes para nossas consultas sobre os dados existentes do conjunto de dados de amostra de viagens. Considerando nossa "hotel" esses três índices serão os que usaremos em nossos exemplos.

Índices GSI básicos

Começaremos analisando uma consulta N1QL SEM Indexação flexível.

Quando executamos essa consulta N1QL usando os índices GSI pré-criados que vêm com o amostra de viagem acabamos usando uma interseção do conjunto de dados def_type e  def_city Índices GSI.

Na interface do usuário da Web do Couchbase Server, Execute a consulta no editor do Query Workbench e analise o plano para ver qual índice está sendo usado.

Esse índice foi escolhido por causa da otimização baseada em regras; se houver um índice que corresponda ao predicado, ele será usado. Desde que "Califórnia" aparece como o estado em todos os documentos com uma cidade de "Fremont" ou "Oakland"podemos usar uma interseção do def_type e o def_city para obter o melhor desempenho possível.

Adicionar mais dados e campos

Agora, vamos adicionar mais alguns dados. Adicionaremos 30.000 documentos com os seguintes novos campos:

• estrelas: Número
• enfrentamento: Cadeia de caracteres
• hotelType: Cadeia de caracteres
• principaisAmenidades: Matriz de strings

Se você quiser acompanhar, clone o viagens-sample-fake-hotels e antes de executar o arquivo server.js, verifique se o nome de usuário e a senha do Couchbase no código de conexão estão corretos.

Uma vez concluído, isso elevará nossa contagem geral de documentos para 61.631, sendo que 30.000 deles são documentos recém-adicionados com nossos novos campos que gostaríamos de começar a usar em nossos predicados de consulta.

Quando adicionamos uma consulta aos nossos novos dados usando um predicado com nossos novos campos, nossa consulta não terá um desempenho ideal. Precisaríamos adicionar um novo índice. Algo como:

Em um ambiente de produção, adicionar um índice às vezes pode ser entediante e exigir um DBA, pois nossos índices precisam ser mantidos ao longo do tempo.

Adicionar índice para o tipo de hotel

Se quiséssemos um índice melhor para consultas com predicados envolvendo hotelType, poderíamos acrescentar o seguinte:

Nesse ponto, execute uma consulta como a seguinte:

Usará esse índice em vez do índice primário ou def_type e por um bom motivo. Veremos isso à medida que adicionarmos novos predicados às nossas consultas para incluir os novos campos que adicionamos, como estrelas, enfrentamento, Tipo de hotel, e possivelmente até mesmo predicados baseados na verificação de nosso principaisAmenidades precisaremos adicionar cuidadosamente novos índices com base na estratégia de consulta. O Couchbase é muito bom em lidar com isso, há ótimos recursos como nosso blog (Crie o índice certo, obtenha o desempenho certo) e há outros recursos úteis para ajudar.

Mas a não criação do índice correto pode causar muitos problemas, sendo um deles, obviamente, o tempo decorrido para buscar os dados. 

A consulta a seguir utiliza os novos campos que adicionamos:

Na situação acima, se não tivéssemos criado o def_hotelType pudemos ver tempos de consulta de mais de 5 segundos em comparação com 500 ms.

A sobrecarga para a criação de um índice como esse é de cerca de dez segundos e os resultados serão dez vezes maiores, considerando o tempo e o desempenho gerais ao recuperar seus dados. Lembre-se de que há 30 mil documentos a serem examinados no caso de usarmos o índice errado.

Adicionar mais índices para manter o ritmo

Dependendo da quantidade de dados que temos e de muitas outras características de nossos dados, é possível adicionar outro índice para predicados que buscam consultar o campo "facing", que indica para que lado da propriedade está voltada a entrada de um hotel.

Melhor ainda, poderíamos usar o recurso ADVISE para adicionar um novo índice; essa última sugestão é recomendada em vez de adicionar um índice individual. Se usarmos o recurso ADVISE, receberemos a recomendação do seguinte índice a ser adicionado:

Poderíamos obter um melhor desempenho dos adv_facing_hotelType_type mas quando você considera outras permutações de uma consulta semelhante a essa, mas em ordem diferente de operações, obtemos resultados diferentes. É preciso estar atento a todos esses aspectos ao fazer consultas e saber quais índices usar.

E se pudéssemos consultar nossos dados do tipo hotel, mas com um índice que nos permitisse ser mais flexíveis com nossas consultas? Ele também poderia permitir outra experiência de desenvolvedor, considerando que poderia ser usado para coisas como consultas ad hoc e, potencialmente, ter desempenho suficiente para ser usado em vez de nossos índices GSI. E se houvesse a opção de um único índice?

Vamos flexibilizar esses dados

No Couchbase Server 6.6, temos um recurso na indexação Flex que pode atender às suas necessidades. O mais legal é que posso lhe mostrar muito facilmente como começar a usá-lo.

Precisamos informar ao mecanismo de consulta N1QL que estamos pretendendo usar um índice Flex. Além disso, a consulta deve ter determinadas características para usar a indexação Flex. Considerando que esses requisitos foram atendidos, a consulta N1QL é transformada em uma consulta FTS e executada no índice de texto completo.

Para não repetir as informações em nossa documentação, ainda é importante mencionar que há diferenças semânticas e restrições em consultas N1QL versus índices Flex. Por esse motivo, tentaremos evitar essas restrições e estaremos cientes das diferenças semânticas.

Configuração do nosso índice FTS Flex

IPara obter um índice Flex para executar nossa consulta em vez dos índices que já configuramos para nosso conjunto de dados de amostra de viagens, basta ir para a guia de pesquisa na interface do usuário da Web do Couchbase Server e clicar em "Adicionar índice" e preencha os campos a seguir.

1. Para o nome usei o campo "fts-index"Recomenda-se um nome mais descritivo
2. Selecione o compartimento no qual nossos documentos estão contidos
3. Para o Campo do tipo JSON, especificaremos: tipo
4. Clique em +Adicionar mapeamento de tipo e especificar nosso tipo de documento: hotel
5. Selecione "palavra-chave" no menu suspenso do analisador padrão
6. Desmarque a opção padrão mapeamento de tipos para que não digitalizemos todos os tipos de documentos em nosso balde

Usar dicas do FTS

Ainda precisamos indicar que gostaríamos de tentar usar o Flex Indexing em nossas consultas N1QL. Na situação acima, em que temos uma consulta N1QL muito básica que recupera documentos do tipo "hotel" Se quiséssemos alterar essa consulta para aproveitar as vantagens do Flex Indexing, forneceríamos o (USANDO FTS) dica:

Essa consulta agora usa o índice Flex que configuramos e delega a indexação Flex para lidar com isso devido à natureza genérica do nosso índice.

Nossas opções de consulta são muitas

Vamos tentar mais algumas consultas. Executei todas elas e cada uma parece ter benefícios semelhantes em relação aos índices GSI, considerando o tempo total para executar a consulta e recuperar nossos dados.

Aqui, adicionamos um predicado de cidade.

Em seguida, combinamos os campos cidade e estrelas em nosso predicado.

E se deixarmos de lado o type="hotel"? (varredura primária de 16s)

Queremos garantir que adicionemos WHERE type="hotel" ao nosso predicado, ao usar o Flex Index específico que configuramos, lembre-se de que, de certa forma, essa é a parte mais importante do predicado da consulta e, caso contrário, o Flex Index não será selecionado. Um índice que é mapeado por tipo não será selecionado pelo N1QL se a expressão de condição (por exemplo tipo = "hotel") está faltando na consulta.

Vamos usar o principaisAmenidades e verificar se ele tem uma string de "Restaurante" contido.

Encerramento

Examinamos os conceitos básicos dos índices GSI e da indexação Flex e mostramos como começar a usar a indexação no Couchbase. Nada disso deve substituir a leitura da documentação, mas pode ajudá-lo a começar mais facilmente. Com esse conhecimento, agora você deve entender como abordar a indexação Flex.

Obrigado por ler e por favor, Confira a documentação do Flex Indexing para obter mais informações!