O ECK exige um esforço significativamente maior do que as soluções Elastic Cloud baseadas no Marketplace, mas é mais automatizado do que implantar VMs por conta própria, porque o operador do Kubernetes cuidará da orquestração do sistema e do escalonamento dos nós.

Desta vez, vamos trabalhar com o Azure Kubernetes Service (AKS), usando o modo automático. Nos outros artigos, você aprenderá como usar as VMs do Azure e o Azure Marketplace.

O que é o AKS Automatic?

O Azure Kubernetes Service (AKS) gerencia automaticamente a configuração do cluster, aloca recursos dinamicamente e integra as melhores práticas de segurança, preservando a flexibilidade do Kubernetes, permitindo que os desenvolvedores passem da imagem do contêiner para o aplicativo implantado em minutos.

O AKS Automatic elimina a maior parte da sobrecarga de gerenciamento de clusters e encontra um bom equilíbrio entre simplicidade e flexibilidade. A escolha certa depende do seu caso de uso, mas a decisão fica mais fácil se você planeja:

• Implante um ambiente de teste: A implantação é rápida e simples, tornando-a ideal para experimentos rápidos ou clusters de curta duração.

• Trabalhe sem requisitos rígidos de VM, armazenamento ou rede: o AKS Automatic fornece configurações padrão predefinidas; portanto, se elas atenderem às suas necessidades, você evita configurações adicionais.

• Comece a usar o Kubernetes pela primeira vez: ao lidar com grande parte da configuração do cluster, o AKS Automatic reduz a curva de aprendizado e permite que as equipes se concentrem em seus aplicativos.

Para o Elasticsearch, usaremos o Elastic Cloud on Kubernetes (ECK), que é o operador oficial do Elastic Kubernetes e simplifica a orquestração das implantações do Elastic Stack no Kubernetes.

Como configurar o AKS automaticamente

1. Faça login no Portal do Microsoft Azure.

2. No canto superior direito, cliqueNo botão do Cloud Shell , você pode acessar o console e implantar o cluster AKS a partir daí. Alternativamente, você pode usar o Azure Cloud Shell.

Lembre-se de atualizar o ID do projeto com o seu durante o tutorial.

Abrir o AKS deve ser semelhante à captura de tela acima.

3. Instale a extensão aks-preview da CLI do Azure. Esta versão de pré-visualização permitirá selecionar --sku automatic na criação do cluster, o que habilita o recurso AKS Automático.

Se você vir esta mensagem, significa que a extensão AKS foi instalada corretamente.

4. Registre os sinalizadores de recursos usando o comando az feature register

Você verá os detalhes sobre a assinatura do recurso que acabamos de criar:

Verifique o status do registro até que ele mude de “Registrando” para “Registrado”. O processo de cadastro pode levar alguns minutos.

Execute az provider register para propagar as alterações.

5. Criar um grupo de recursos

Um grupo de recursos é um grupo lógico de recursos do Azure que serão gerenciados e implantados.

6. Crie um cluster do Autopilot. Vamos chamá-lo de myAKSAutomaticCluster e usar o grupo de recursos que acabamos de criar. Certifique-se de ter 16 vCPUs disponíveis em qualquer um dos seguintes tamanhos de VM: Standard_D4pds_v5, Standard_D4lds_v5, Standard_D4ads_v5, Standard_D4ds_v5, Standard_D4d_v5, Standard_D4d_v4, Standard_DS3_v2, Standard_DS12_v2 para que o AKS possa alocar recursos.

* Se você receber dois errosMissingSubscriptionRegistration), volte ao passo 4 com as assinaturas ausentes. Por exemplo, The subscription is not registered to use namespace 'microsoft.insights' requer a execução de az provider register --namespace Microsoft.Insights.

Siga as instruções de login interativo:

Uma mensagem solicitando a execução do comando “az login” será exibida. Você precisa executar esse comando e depois esperar.

7. Aguarde até que esteja pronto. Leva cerca de 10 minutos para criar.

8. Configure o acesso à linha de comando do kubectl.

Observe que a extensão que instalamos está habilitando o AKS Automático.

9. Confirme se os nós foram implantados.

Você verá uma mensagem de erro de acesso proibido; copie o ID do usuário da mensagem de erro.

10. Adicione seu usuário ao controle de acesso do AKS.

Obtenha o ID da AKS. Copie a saída do comando.

Crie uma atribuição de função usando o ID do AKS e o ID principal do seu usuário.

11. Tente confirmar novamente se os nós foram implantados.

12. Instale o operador Elastic Cloud on the Kubernetes (ECK).

13. Vamos criar uma instância Elasticsearch de nó único com os valores padrão.

Desativamos nmap porque a máquina AKS padrão tem um valor vm.max_map_count muito baixo. Desativá-lo não é recomendado para produção, mas aumentar o valor de vm.max_map_count. Você pode ler mais sobre como fazer isso aqui.

14. Vamos também implantar um cluster Kibana de nó único. Para o Kibana, adicionaremos um balanceador de carga, que nos fornecerá um IP externo que poderemos usar para acessar o Kibana a partir do nosso dispositivo.

Por padrão, o AKS Automatic configurará o balanceador de carga como público; você pode alterar esse comportamento definindo a anotação de metadados:

service.beta.kubernetes.io/azure-load-balancer-internal: "true"

15. Verifique se seus pods estão em execução.

16. Você também pode executar kubectl get elasticsearch e kubectl get kibana para estatísticas mais específicas, como versão do Elasticsearch, nós e integridade.

17. Acesse seus serviços.

Isso mostrará o URL externo do Kibana em EXTERNAL-IP. Pode levar alguns minutos para o balanceador de carga ser provisionado. Copie o valor de EXTERNAL-IP.

18. Obtenha a senha do Elasticsearch para o usuário 'elastic':

19. Acesse o Kibana através do seu navegador:

a. URL: https://:5601<EXTERNAL_IP>

b. Nome de usuário: elastic

c. Senha: c44A295CaEt44D6xIzN6Zs5m (da etapa anterior)

20. Ao acessar o Elastic Cloud pelo seu navegador, você verá a tela de boas-vindas.

Se você deseja alterar as especificações do cluster Elasticsearch, como alterar ou redimensionar nós, pode aplicar o manifesto YML novamente com as novas configurações:

Neste exemplo, vamos adicionar mais um nó e modificar a RAM e a CPU. Como você pode ver, agora kubectl get elasticsearch mostra 2 nós:

O mesmo se aplica ao Kibana:

Podemos ajustar o uso de CPU/RAM do contêiner e também o uso de memória do Node.js (max-old-space-size).

Lembre-se de que os pedidos de reembolso em grande volume já existentes não podem ser reduzidos. Após aplicar a atualização, o operador fará as alterações com o mínimo de interrupção possível.

Lembre-se de excluir o cluster quando terminar os testes para evitar custos desnecessários.

Conclusão

Utilizar o Azure AKS Automatic com o ECK oferece uma solução equilibrada para a implementação do Elasticsearch e do Kibana: reduz a complexidade operacional, garante o dimensionamento e as atualizações automatizadas e aproveita a flexibilidade do Kubernetes. Essa abordagem é ideal para equipes que desejam um processo de implantação confiável, repetível e de fácil manutenção, sem precisar gerenciar manualmente cada detalhe da infraestrutura, tornando-se uma escolha prática tanto para ambientes de teste quanto de produção.

Próximas etapas

Se você quiser saber mais sobre Kubernetes, pode consultar a documentação oficial aqui:

• Elastic Cloud no Kubernetes | Documentação da Elastic

• Introdução ao Azure Kubernetes Service (AKS) Automático (prévia)

• AKS Automatic - Blog de Engenharia da AKS

O que é fragmentação recursiva?

O particionamento recursivo percorrerá uma lista de seções fornecidas, separando padrões para dividir progressivamente um documento em segmentos menores até atingir o tamanho máximo desejado.

Como configuro o chunking recursivo?

A seguir, estão os valores configuráveis fornecidos pelo usuário para o particionamento recursivo:

• (obrigatório) max_chunk_size: O número máximo de palavras em um bloco.

• Qualquer uma das seguintes opções:

  • separatorsUma lista de padrões de strings de expressão regular que serão usados para dividir o documento em partes.

  • separator_group: Uma string que será mapeada para uma lista padrão de separadores definida pela Elastic para uso em tipos específicos de documentos. Atualmente, markdown e plaintext estão disponíveis.

Como funciona o particionamento recursivo?

O processo de fragmentação recursiva, dado um documento de entrada, um max_chunk_size (medido em palavras) e uma lista de strings separadoras, é o seguinte:

1. Se o documento de entrada já estiver dentro do tamanho máximo do bloco, retorne um único bloco que abranja toda a entrada.

2. Divida o texto em partes potenciais com base nas ocorrências do separador. Para cada bloco potencial:

   1. Se o fragmento em potencial estiver dentro do tamanho máximo permitido, adicione-o à lista de fragmentos a serem retornados ao usuário.

   2. Caso contrário, repita a partir do passo 2, usando apenas o texto do possível bloco e dividindo-o usando o próximo separador da lista. Se não houver mais separadores para tentar, recorra à segmentação baseada em frases.

Exemplos de configuração de fragmentação recursiva

Além do tamanho do bloco, a principal configuração para o particionamento recursivo é selecionar quais separadores devem ser usados para dividir seus documentos. Se você não sabe por onde começar, o Elasticsearch oferece alguns grupos de separadores padrão que podem ser usados para casos de uso comuns.

Utilizando grupos separadores

Para utilizar um grupo separador, basta fornecer o nome do grupo que você deseja usar ao configurar as opções de fragmentação. Por exemplo:

Isso lhe dará uma estratégia de fragmentação recursiva que utiliza a lista de separadores ["(?<!\\n)\\n\\n(?!\\n)", "(?<!\\n)\\n(?!\\n)")]. Isso funciona bem para aplicações genéricas de texto simples, dividindo o texto em dois caracteres de nova linha, seguidos por um caractere de nova linha.

Também oferecemos um grupo separador markdown que utilizará a lista de separadores:

Esta lista de separadores funcionará bem para casos de uso gerais de Markdown, dividindo o texto em cada um dos 6 níveis de título e nos caracteres de quebra de seção.

Ao criar um recurso (ponto de extremidade de inferência/campo de texto semântico), a lista de separadores correspondentes ao grupo de separadores no momento será armazenada em suas configurações. Se o grupo separador for atualizado posteriormente, isso não alterará o comportamento dos seus recursos já criados.

Utilizando uma lista separadora personalizada

Se um dos grupos de separadores predefinidos não for adequado ao seu caso de uso, você pode definir uma lista personalizada de separadores que atenda às suas necessidades. Observe que expressões regulares podem ser fornecidas dentro da lista de separadores. Segue abaixo um exemplo de configurações de fragmentação configuradas com separadores personalizados:

A estratégia de fragmentação acima dividirá em 2 caracteres de nova linha, seguidos por 1 caractere de nova linha e, por último, em uma string “<my-custom-separator>”.

Um exemplo de fragmentação recursiva em ação.

Vejamos um exemplo de fragmentação recursiva em ação. Neste exemplo, usaremos as seguintes configurações de fragmentação com uma lista personalizada de separadores que dividem um documento Markdown usando os dois níveis de cabeçalho superiores:

Vamos analisar um documento Markdown simples, sem divisões em partes (unchunked):

Agora vamos usar as configurações de fragmentação definidas acima para dividir o documento em partes:

Nota: A quebra de linha no final de cada bloco (exceto o Bloco 3) não está destacada, mas está incluída dentro dos limites reais do bloco.

Comece a usar o chunking recursivo hoje mesmo!

Para obter mais informações sobre como utilizar este recurso, consulte a documentação sobre como configurar as definições de fragmentação.

Além disso, esses casos de uso geralmente são sensíveis ao tempo, e passar pelas etapas típicas de desenvolvimento (criar uma ramificação de código e depois esperar por um novo lançamento) é um processo demorado.

E se pudéssemos realizar todo esse processo com apenas uma chamada de API, ou melhor ainda, com apenas alguns cliques no Kibana?

Interface do usuário de regras de consulta

O Elasticsearch 8.10 introduziu as Regras de Consulta e o Recuperador de Regras. São ferramentas projetadas para inserir resultados fixados nas consultas sem afetar a classificação dos resultados orgânicos com base em regras. Eles apenas adicionam lógica de negócios aos resultados de forma declarativa e simples.

Alguns casos de uso comuns para regras de consulta são:

• Destacar anúncios ou promoções: Exibir itens em promoção ou patrocinados no topo.

• Exclusão por contexto ou geolocalização: Ocultar determinados itens quando as regulamentações locais não permitem que você os mostre.

• Priorizar resultados-chave: Garantir que as pesquisas populares ou fixas estejam sempre no topo, independentemente do ranking orgânico.

Para acessar a interface e interagir com essas ferramentas, você precisa clicar no menu lateral do Kibana e ir para Regras de Consulta, em Relevância:

Assim que o menu de regras de consulta aparecer, clique em Criar seu primeiro conjunto de regras:

Em seguida, você precisa dar um nome ao seu conjunto de regras.

O formulário para definir cada regra possui três componentes principais:

• Critérios: As condições que devem ser cumpridas para que a regra se aplique. Por exemplo, “quando o campo query_string contém o valor Christmas” ou “quando o campo country é CO”.

• Ação: Isto é o que você deseja que aconteça quando as condições forem atendidas. Ele pode ser fixado (fixando um documento nos primeiros resultados) ou excluído (ocultando um documento).

• Metadados: São os campos que acompanham a consulta quando ela é executada. Podem incluir informações do usuário (como localização ou idioma), bem como dados de pesquisa (query_string). Esses são os valores usados pelos critérios para decidir se uma regra deve ou não ser aplicada.

Exemplo: itens populares

Vamos imaginar que temos um site de comércio eletrônico com diversos itens. Ao analisarmos as métricas, notamos que um dos itens mais vendidos na categoria de consoles é o "Controle sem fio DualShock 4", especialmente quando os usuários pesquisam pelas palavras-chave "PS4" ou "PlayStation 4". Assim, decidimos colocar este produto no topo dos resultados, sempre que um usuário pesquisar por essas palavras-chave.

Primeiro, vamos indexar os documentos de cada item usando uma solicitação de API em lote:

Se não intervirmos na consulta, o item geralmente aparece em quarto lugar. Eis a pergunta:

E aqui estão os resultados.

Vamos criar uma regra de consulta para alterar isso. Primeiro, vamos adicioná-lo ao conjunto de regras assim:

Ou solicitação de API equivalente:

Para usar o conjunto de regras em nossa consulta, devemos usar um tipo de regra de consulta. Esse tipo de consulta é composto por duas partes principais:

• match_criteria: São os metadados usados para comparar com a consulta do usuário. Neste exemplo, o conjunto de regras é ativado quando o campo query_string tem o valor “PlayStation 4”.

• consulta: a consulta propriamente dita que será usada para pesquisar e obter os resultados orgânicos.

Dessa forma, primeiro você executa a consulta orgânica e, em seguida, o Elasticsearch aplica as regras do seu conjunto de regras:

Exemplo: metadados baseados no usuário

Outra aplicação interessante das Regras de Consulta é usar metadados para exibir documentos específicos com base em informações contextuais do usuário ou da página da web.

Por exemplo, vamos supor que queremos destacar itens ou ofertas personalizadas com base no nível de fidelidade do usuário, representado por um valor numérico.

Podemos fazer isso inserindo esses metadados diretamente na consulta, de forma que as regras sejam ativadas quando o valor atender a determinados critérios.

Primeiro, vamos indexar um documento que somente usuários com um alto nível de fidelidade podem ver:

Agora, vamos criar uma nova regra dentro do mesmo conjunto de regras para que, quando o nível de lealdade for igual ou superior a 80, o item apareça no topo dos resultados.

Salve a regra e o conjunto de regras.

Aqui está a solicitação REST equivalente:

Agora, ao executar uma consulta, precisamos incluir o novo parâmetro loyalty_level nos metadados. Se a condição da regra for atendida, o novo documento aparecerá no topo dos resultados.

Por exemplo, ao enviar uma consulta onde o nível de lealdade é 80:

Veremos o documento de fidelidade acima dos resultados:

No caso abaixo, como o nível de fidelidade é 70, a regra não é atendida e o item não deve aparecer no topo:

Aqui estão os resultados:

Exemplo: exclusão imediata

Vamos supor que nosso Controle Sem Fio DualShock 4 (ID 2) esteja temporariamente indisponível e não possa ser vendido. Assim, em vez de excluir o documento manualmente ou esperar que algum processamento de dados seja iniciado, a equipe comercial decide removê-lo dos resultados da pesquisa enquanto isso.

Usaremos um processo semelhante ao que acabamos de aplicar aos itens populares, mas desta vez, em vez de selecionar "Fixados", escolheremos "Excluir". Essa regra funciona como uma espécie de lista negra. Altere os critérios para "Sempre" para que a exclusão funcione sempre que a consulta for executada.

A regra deve ser assim:

Salve a regra e o conjunto de regras para aplicar as alterações. Aqui está a solicitação REST equivalente:

Agora, ao executar a consulta novamente, você verá que o item não está mais nos resultados, mesmo que a regra anterior fosse fixá-lo. Isso ocorre porque as exclusões têm prioridade sobre a fixação dos resultados.

Conclusão

As regras de consulta tornam muito fácil ajustar a relevância sem qualquer alteração de código. A nova interface do Kibana permite que vocêPara fazer essas alterações em questão de segundos, você e sua equipe terão mais controle sobre os resultados da pesquisa.

Além do comércio eletrônico, as Regras de Consulta podem ser aplicadas em muitos outros cenários: destacar guias de solução de problemas em portais de suporte, exibir documentos internos importantes em bases de conhecimento, promover notícias de última hora em sites de notícias ou filtrar anúncios de emprego ou conteúdo expirados. Eles podem até mesmo impor regras de conformidade, como ocultar material restrito por função de usuário ou região.

Vamos usar o Elastic Cloud Service na AWS, que é o serviço oficial gerenciado do Elasticsearch Service que simplifica a implantação e orquestração de todos os componentes do Elastic Stack por meio da infraestrutura nativa da AWS.

Se você quer aprender a instalar e configurar o Elasticsearch na AWS EC2, leia este blog.

O que é o AWS Marketplace?

Elastic on AWS Marketplace oferece uma experiência de busca e análise totalmente gerenciada, em que a AWS cuida da provisão de infraestrutura, segurança e redimensionamento, enquanto os desenvolvedores se concentram na criação de aplicações de busca. Isso permite que as equipes implantem clusters do Elasticsearch de nível empresarial em minutos com integrações integradas da AWS.

Quando usar o Elastic no AWS Marketplace?

O Elastic on AWS Marketplace é mais indicado para organizações com infraestrutura AWS existente que buscam implantar o Elasticsearch com serviços gerenciados, security integrado e integrações AWS integradas sem sobrecarga operacional.

Como configurar o Elastic Cloud no AWS Marketplace

Passo 1: Acesse o AWS Marketplace

1. Faça login no AWS

• Na barra de busca, procure por AWS Marketplace

2. No painel de navegação à esquerda, clique em Descobrir produtos e depois busque por Elasticsearch

3. Clique em Elastic Cloud (Elasticsearch Service)

Passo 2: Assine o serviço

1. Selecione opções de compra ou clique em Experimente gratuitamente

2. Revise os detalhes de preços, termos e condições e detalhes de compra

3. Clique no botão Assinar

4. Agora precisamos configurar a conta Elastic. Siga os passos da AWS

a. Clique no botão Ativar integração

b. Clique no botão Entrar ou crie uma conta de fornecedor

c. Clique no botão Executar modelo

d. Clique no botão Executar software

Passo 3. Configure sua nova conta na Elastic

1. Crie sua conta Elastic

2. Valide seu endereço de e-mail

3. Insira seu nome e informações da empresa

4. Complete uma breve pesquisa da Elastic

5. Selecione a região onde deseja hospedar o Elastic Cloud. Por padrão, sua região AWS real será selecionada

6. Aguarde o Elastic implantar.

7. Sua implantação está conectada à sua assinatura do AWS Marketplace.

Cancele sua assinatura

Para cancelar a sua assinatura

1. Acesse o console da AWS

Busque por AWS Marketplace na barra de pesquisa. Clique em AWS Marketplace

2. Clique em Assinatura do Elastic Cloud

3. Clique no botão Ações e, em seguida, clique em Cancelar assinatura.

4. Confirme o cancelamento e clique em Sim e no botão cancelar assinatura

5. Uma mensagem de confirmação aparecerá no topo da página.

Próximas etapas

Comece sua jornada no Elastic Cloud com um teste gratuito de 7 dias que inclui uma única implantação e três projetos Elastic Cloud (Elasticsearch Service). Basta fazer login na sua conta AWS e clicar em "Ver Opções de Compra" para começar a usar a Plataforma de IA de Busca da Elastic imediatamente no Elastic Cloud (Elasticsearch Service). O teste oferece acesso total a soluções de busca, segurança e observabilidade, sem qualquer sobrecarga de gerenciamento de infraestrutura.

Sistemas distribuídos como o Elasticsearch podem ser muito complexos, com muitos fatores que podem afetar seu desempenho e estabilidade. Os shards estão entre os conceitos mais fundamentais do Elasticsearch, e entender como eles funcionam permitirá que você gerencie um cluster Elasticsearch de forma eficaz.

Este artigo explica o que são shards primários e réplicas, seu impacto em um cluster Elasticsearch e quais ferramentas existem para ajustá-los a diferentes demandas.

Entendendo os fragmentos

Os dados em um índice Elasticsearch podem crescer a proporções gigantescas. Para manter a organização, cada dado é armazenado em um índice, e os índices são divididos em vários fragmentos. Cada fragmento do Elasticsearch é um índice Apache Lucene, sendo que cada índice Lucene individual contém um subconjunto dos documentos presentes no índice do Elasticsearch. Dividir os índices dessa forma mantém o uso de recursos sob controle. Um índice Apache Lucene tem um limite de 2.147.483.519 (2³¹ - 129) documentos.

Por vezes, os índices precisam ser movidos entre nós para fins de rebalanceamento. Como esse processo pode ser demorado e exigir muitos recursos, os índices não devem crescer demais, o que ajuda a manter o tempo de recuperação em níveis gerenciáveis. Além disso, como os índices são compostos por segmentos do Lucene que precisam ser constantemente mesclados, é importante que os segmentos não fiquem muito grandes. Por esses motivos, o Elasticsearch divide os dados do índice em partes menores e mais gerenciáveis, chamadas de shards primários, que podem ser distribuídas mais facilmente por várias máquinas. Os fragmentos de réplica são simplesmente uma cópia exata de um fragmento primário correspondente, e abordaremos sua função mais adiante neste artigo.

Ter o número correto de shards é importante para o desempenho. Portanto, é sensato planejar com antecedência. Quando as consultas são executadas em paralelo em diferentes shards, elas são executadas mais rapidamente do que um índice composto por um único shard, mas somente se cada shard estiver localizado em um nó diferente e houver nós suficientes no cluster. Ao mesmo tempo, porém, os shards consomem memória e espaço em disco, tanto em termos de dados indexados quanto de metadados do cluster. Ter muitos shards (também conhecido como sobresharding) pode tornar as consultas, as solicitações de indexação e as operações de gerenciamento mais lentas, sendo, portanto, fundamental manter o equilíbrio certo.

O número de shards primários é definido no momento da criação do índice para aquela instância de índice específica. Se precisar de um número diferente de shards primários posteriormente, você pode usar as APIs de redimensionamento : split (mais shards primários), shrink (menos shards primários) ou clone (o mesmo número de shards primários com novas configurações para réplicas). Essas operações copiam segmentos do Lucene e evitam uma reindexação completa de todos os documentos. Ao criar um índice, você pode definir o número de shards primários e de réplicas nas configurações do índice:

(Caso não especifique o número de shards ou réplicas, o valor padrão para ambos é 1, a partir do Elasticsearch 7.0). O número ideal de fragmentos deve ser determinado com base na quantidade de dados em um índice. Em geral, um shard ideal deve conter de 10 a 50 GB de dados, com menos de 200 milhões de documentos por shard. Por exemplo, se você espera acumular cerca de 300 GB de logs de aplicativos por dia, ter cerca de 10 shards nesse índice seria razoável, desde que você tenha nós suficientes para hospedá-los.

Durante sua existência, os fragmentos podem passar por diversos estados, incluindo:

• Inicialização: Estado inicial antes que o fragmento possa ser usado.

• Iniciado: Estado em que o fragmento está ativo e pode receber solicitações.

• Relocação: Estado que ocorre quando os fragmentos estão em processo de serem movidos para um nó diferente. Isso pode ser necessário em certas condições, por exemplo, quando o nó em que estão instalados está ficando sem espaço em disco.

• Não atribuído: O estado de um fragmento que não pôde ser atribuído. Quando isso acontece, é apresentada uma justificativa, por exemplo, se o nó que hospeda o shard não estiver mais no cluster (NODE_LEFT) ou devido à restauração em um índice fechado (EXISTING_INDEX_RESTORED).

Para visualizar todos os fragmentos (shards), seus estados e outros metadados, você pode usar a seguinte solicitação:

Para visualizar os fragmentos de um índice específico, você pode adicionar o nome do índice à URL, por exemplo, sensor:

Este comando produz uma saída, como no exemplo a seguir. Por padrão, as colunas exibidas incluem o nome do índice, o nome (ou seja, número) do fragmento, se é um fragmento primário ou uma réplica, seu estado, o número de documentos, o tamanho em disco, bem como o endereço IP e o ID do nó onde o fragmento está localizado.

Entendendo as réplicas

Embora cada fragmento contenha uma única cópia dos dados, um índice pode conter várias cópias do fragmento. Existem, portanto, dois tipos de fragmentos: o fragmento primário e uma cópia, ou réplica. Cada réplica de um shard primário está sempre localizada em um nó diferente, o que garante alta disponibilidade dos seus dados em caso de falha de um nó. Além da redundância e de seu papel na prevenção de perda de dados e tempo de inatividade, as réplicas também podem ajudar a melhorar o desempenho da pesquisa, permitindo que as consultas sejam processadas em paralelo com o shard primário e, portanto, mais rapidamente.

Existem algumas diferenças importantes no comportamento dos fragmentos primários e das réplicas. Embora ambos sejam capazes de processar consultas, solicitações de indexação (ou seja, A adição de dados ao índice deve primeiro passar pelos shards primários antes de poder ser replicada para os shards de réplica. Conforme mencionado acima, se um shard primário ficar indisponível — por exemplo, devido à desconexão de um nó ou falha de hardware — uma réplica é promovida para assumir sua função.

Embora as réplicas possam ajudar em caso de falha de um nó, é importante não ter muitas delas, pois consomem memória, espaço em disco e poder computacional durante a indexação. Outra diferença entre os shards primários e as réplicas é que, enquanto o número de shards primários não pode ser alterado após a criação do índice, o número de réplicas pode ser alterado dinamicamente a qualquer momento, atualizando as configurações do índice.

Outro fator a ser considerado com réplicas é o número de nós disponíveis. As réplicas são sempre colocadas em nós diferentes do shard primário, uma vez que duas cópias dos mesmos dados no mesmo nó não ofereceriam proteção caso o nó falhasse. Consequentemente, para que um sistema suporte n réplicas, é necessário que haja pelo menos n + 1 nós no cluster. Por exemplo, se houver dois nós em um cluster e um índice estiver configurado com seis réplicas, apenas uma réplica será alocada. Por outro lado, um sistema com sete nós é perfeitamente capaz de lidar com um shard primário e seis réplicas.

Otimizando fragmentos e réplicas

Mesmo após a criação de um índice com o equilíbrio correto entre shards primários e réplicas, é necessário monitorá-lo, pois a dinâmica em torno de um índice muda ao longo do tempo. Por exemplo, ao lidar com dados de séries temporais, os índices com dados recentes são geralmente mais ativos do que os mais antigos. Sem ajustar esses índices, todos eles consumiriam a mesma quantidade de recursos, apesar de suas necessidades serem muito diferentes.

A API de índice de rollover pode ser usada para separar índices mais recentes de índices mais antigos. É possível configurá-lo para criar automaticamente um novo índice quando um determinado limite — como o tamanho do índice no disco, o número de documentos ou sua idade — for atingido. Essa API também é útil para manter o tamanho dos fragmentos sob controle. Como o número de fragmentos não pode ser facilmente alterado após a criação do índice, os fragmentos continuarão acumulando dados se nenhuma condição de rollover for atendida. Para índices mais antigos que exigem acesso pouco frequente, reduzir o tamanho e forçar a fusão de um índice são duas maneiras diferentes de diminuir o espaço ocupado na memória e no disco. O primeiro reduz o número de fragmentos em um índice, enquanto o segundo reduz o número de segmentos do Lucene e libera espaço usado por documentos que foram excluídos.

Fragmentos primários e réplicas como base do Elasticsearch

O Elasticsearch construiu uma sólida reputação como plataforma distribuída de armazenamento, busca e análise para grandes volumes de dados. Ao operar em tal escala, porém, desafios inevitavelmente surgirão. Por isso, entender como funcionam os shards primários e de réplica é tão importante e fundamental para o Elasticsearch, pois isso pode ajudar a otimizar a confiabilidade e o desempenho da plataforma.

Saber como funcionam e como otimizá-los é fundamental para obter um cluster Elasticsearch mais robusto e com melhor desempenho. Se você está enfrentando lentidão nas respostas às consultas ou interrupções frequentes, esse conhecimento pode ser a chave para superar esses obstáculos.

Siga a documentação oficial do Elasticsearch para saber mais sobre clusters, nós e shards, como dimensionar seus shards, alocação de shards e recuperação.

Este tópico também está disponível como um curso introdutório no canal da comunidade Elastic no YouTube.

Por último, mas não menos importante: se você não quiser se preocupar com nós, shards ou réplicas, pode experimentar o Elastic Cloud Serverless. Esta oferta da Elastic Cloud é totalmente gerenciada pela Elastic e automatizada para escalar de acordo com sua carga de trabalho. Um período de teste gratuito pode ajudá-lo a se familiarizar com outros benefícios da abordagem sem servidor.

• bg_count (contagem de fundo): Número de documentos encontrados no conjunto de dados original

• doc_count: Número de documentos encontrados no conjunto de dados resultante.

Por exemplo, em um conjunto de dados de vendas de telefones celulares, podemos procurar termos significativos nas vendas do iPhone 16, como este:

Então, a resposta nos dá:

Houston não está entre as 10 principais cidades em todo o conjunto de dados, nem é a principal cidade para o iPhone 16. No entanto, a análise de agregação de termos relevantes mostrou que o iPhone 16 está sendo comprado de forma desproporcional nesta cidade em comparação com o restante dos dados. Vamos analisar os números mais detalhadamente:

• No nível mais alto:

  • doc_count: 122 — A consulta encontrou um total de 122 documentos.

  • bg_count: 424 — O conjunto de fundo (todos os documentos de vendas) contém 424 documentos.

• Na cesta de Houston:

  • doc_count: 12 — Houston aparece em 12 dos 122 resultados da consulta

  • contagem_de_fundo: 14 — Houston aparece em 14 dos 424 documentos totais no conjunto de dados de fundo.

Isso nos indica que, de um total de 424 compras, apenas 14 ocorreram em Houston; ou seja, 3,3% do total de compras. No entanto, se analisarmos apenas as vendas do iPhone 16, veremos que 12 das 122 unidades foram vendidas em Houston, o que representa 9,8%, três vezes mais do que em todo o conjunto de dados; isso é significativo!

Veja como isso se apresenta em uma visualização: Total de vendas por cidade/região.

Podemos ver que houve 14 vendas em Houston, o que a torna a 14ª cidade com maior número de vendas no conjunto de dados.

Agora, se aplicarmos um filtro para analisar apenas as vendas do iPhone 16, temos 12 vendas em Houston, tornando-a a segunda cidade com o maior número de vendas desse modelo específico:

Compreendendo os termos significativos de agregação

De acordo com a documentação da Elastic, os termos significativos de agregação são:

"(Encontra) termos que sofreram uma mudança significativa na popularidade, medida entre um conjunto de primeiro plano e um conjunto de segundo plano."

Isso significa que utiliza métricas estatísticas para comparar a frequência de um termo em um subconjunto de dados (o conjunto de primeiro plano) com a frequência do mesmo termo no conjunto de dados principal (o conjunto de fundo). Dessa forma, a pontuação reflete a significância estatística em vez da frequência com que um termo aparece nos dados.

As principais diferenças entre uma agregação de termos significativos e uma agregação de termos normais são:

• A comparação de termos significativos analisa um subconjunto dos dados, enquanto a agregação de termos funciona apenas com o conjunto de dados resultante da consulta.

• Os resultados da agregação de termos mostram os termos mais comuns no conjunto de dados, enquanto os resultados da análise de termos significativos ignoram os termos comuns para encontrar o que torna o conjunto de dados único.

• Termos significativos podem ter um impacto maior no desempenho, visto que precisam obter dados do disco em vez da memória, como faz a agregação de termos.

Aplicação prática (análise do comportamento do consumidor)

Preparando os dados para a análise.

Para esta análise, geramos um conjunto de dados sintéticos de vendas de telefones celulares, incluindo preço, especificações do aparelho, dados demográficos do comprador e avaliações. Também geramos embeddings a partir do feedback do usuário para podermos executar uma consulta semântica posteriormente. Utilizamos o modelo multilíngue e5 small, disponível imediatamente no Elasticsearch.

Para usar este conjunto de dados no Elasticsearch:

1. Faça o upload do arquivo CSV (disponível para download aqui) usando o recurso "Carregar arquivos de dados" do Kibana.

2. Configure um campo semântico, como mostrado neste blog, chamado "embedding", que utiliza o multilingual-e5-small model

3. Finalize a importação com os valores padrão do tipo de campo (palavra-chave para todos os campos, exceto purchase_date e user_feedback). Certifique-se de adicionar o nome do índice phone_sales_analysis para poder executar as consultas apresentadas aqui como estão.

O principal objetivo desta análise é descobrir "O que diferencia os compradores do iPhone 16 de outros segmentos da população? " e obter uma segmentação desses compradores para fins de marketing. 

Este é um documento de exemplo do conjunto de dados:

Compreendendo os padrões demográficos

Aqui, vamos realizar uma análise na população em geral e compará-la com descobertas interessantes das agregações de termos significativos para usuários do iPhone 16.

Padrões normais

Para entender os padrões normais de compra, podemos agregar dados de todos os documentos em diferentes áreas. Para simplificar, vamos nos concentrar em explorar as ocupações das pessoas que compraram um telefone. Podemos fazer isso com uma solicitação ao Elasticsearch.

Isso nos indica que as principais ocupações no conjunto de dados (por número de registros) são:

Padrões de usuários do iPhone 16

Para entender o que diferencia as pessoas que compraram um iPhone 16, vamos executar uma agregação de termos no mesmo campo com um filtro para encontrar essas pessoas na consulta, assim:

Assim, para os usuários do iPhone 16, as principais funções são:

Podemos observar que os usuários do iPhone 16 apresentam padrões de ocupação diferentes em comparação com os usuários de outros modelos de telefone. Vamos usar o Kibana para visualizar os resultados com facilidade:

Neste gráfico, podemos ver que a tendência do iPhone 16 é diferente da tendência da população em geral.

Podemos pular toda essa análise e ver o que diferencia os usuários do iPhone 16 da população em geral, executando uma agregação de termos significativos:

Resumindo, obtemos esta resposta:

Valores das ocupações para o iPhone 16

contagem de documentos

contagem de fundo

distribuição_de_ocupações (nível superior)

122

424

Categoria Médica e de Saúde

45

57

A resposta sugere claramente que os usuários do iPhone 16 têm uma característica incomum (leia-se significativa!). Número de pessoas na área médica e de saúde em comparação com a população em geral. Vamos analisar o que os números na resposta significam:

• No nível mais alto:

  • doc_count: 122 — A consulta encontrou um total de 122 documentos.

  • bg_count: 424 — O conjunto de fundo (todos os documentos de vendas) contém 424 documentos.

• Na categoria Medicina e Saúde:

  • doc_count: 45 — "Medicina e Saúde" aparece em 45 dos 122 resultados da consulta

  • bg_count: 57 — "Medical & Healthcare" aparece em 57 dos 424 documentos totais no conjunto de dados de fundo.

Dos 424 compradores, 57 trabalham na área médica e de saúde — ou seja, 13,44%. Mas quando analisamos os compradores do iPhone 16, 45 de 122 trabalham na área médica e de saúde — ou seja, 36,88%. Isso significa que temos o dobro de probabilidade de encontrar alguém que trabalhe na área médica e de saúde entre os usuários do iPhone 16!

Podemos aplicar essa mesma análise a outros campos (idade, localização, faixa de renda, etc.) para encontrar mais informações sobre o que torna os usuários do iPhone 16 únicos. 

Segmentação de consumidores

Podemos usar o conceito de agregação para extrair informações sobre as relações entre produtos, categorias e segmentos de clientes. Para isso, construímos uma agregação principal para a categoria que temos interesse em explorar. Também utilizamos uma subagregação de termos significativos e uma subagregação de termos normais para encontrar informações interessantes sobre essa categoria e compará-las com o que a maioria das pessoas nessa profissão utiliza.

Por exemplo, vejamos o que as pessoas em algumas áreas de trabalho preferem:

1. Para tornar a análise mais clara, vamos limitar nossa busca a 3 áreas de atuação: ["Administrativo e Suporte", "Tecnologia e Dados", "Médico e Saúde"]

2. No que diz respeito às agregações, começamos com uma agregação de termos por ocupação.

3. Adicione uma subagregação: termos por modelo de telefone — para descobrir quais modelos os usuários que trabalham em cada área estão comprando.

4. Adicione uma segunda subagregação: termos significativos por modelos telefônicos — para descobrir quais modelos são específicos em cada área de atuação.

Vamos analisar os resultados da agregação:

Ocupação: Administrativo e de Apoio

Agregação de termos

Agregação de termos significativos

A partir desta tabela, podemos inferir que não existem diferenças significativas entre a tendência para esta ocupação e a tendência para toda a população.

Área de atuação: Tecnologia e Dados

Agregação de termos

Agregação de termos significativos

Total de documentos: 424

Documentos nesta ocupação: 71

modelo de telefone

contagem de documentos (este modelo nesta ocupação)

contagem de fundo (este modelo em todos os documentos)

% em todos os documentos

% nesta ocupação

Google Pixel 8

12

22

5,19%

16,90%

OnePlus 11

9

14

3,30%

12,68%

OnePlus 12 Pro

3

3

0,71%

4,23%

Google Pixel 8 Pro

9

21

4,95%

12,68%

Nada Telefone 2

5

8

1,89%

7,04%

Samsung Galaxy Z Fold5

4

6

1,42%

5,63%

OnePlus 12

8

20

4,72%

11,27%

Área de atuação: Medicina e Saúde

Agregação de termos

Agregação de termos significativos

Total de documentos: 424

Documentos nesta ocupação: 57

modelo de telefone

contagem de documentos (este modelo nesta ocupação)

contagem de fundo (este modelo em todos os documentos)

% em todos os documentos

% nesta ocupação

iPhone 16

45

122

28,77%

78,95%

iPhone 15 Pro Max

3

13

3,07%

5,26%

iPhone 15

7

40

9,43%

12,28%

Vejamos o que esses dados nos contam:

• Profissionais da área médica e de saúde preferem o iPhone 16 e, de modo geral, são muito inclinados a usar telefones da Apple.

• Profissionais de tecnologia e dados preferem celulares Android de última geração, mas não necessariamente usam a marca Samsung. Existe também uma tendência considerável para iPhones nesta categoria.

• Profissionais administrativos e de suporte preferem celulares Samsung e Google, mas não há uma tendência forte e única entre eles.

Agregação de termos relevantes e busca híbrida

A busca híbrida combina a busca por texto com resultados semânticos para proporcionar uma experiência de busca aprimorada. Nesse contexto, uma agregação de termos significativa pode fornecer insights sobre os resultados de uma busca contextualizada, respondendo à pergunta: O que torna este conjunto de dados especial em comparação com todos os outros documentos?Para demonstrar essa funcionalidade, vejamos quais modelos são mais frequentes quando os usuários mencionam um bom desempenho:

• Vamos construir uma consulta semântica onde encontramos o feedback de usuário mais relevante para a entrada "bom desempenho" no campo de incorporação.

• Também utilizaremos uma pesquisa de texto com os mesmos termos no campo de texto user_feedback.

• Também adicionaremos uma consulta de termos relevantes para encontrar modelos de telefone que sejam mais frequentes nesses resultados do que no conjunto de dados completo.

Vejamos um exemplo dos documentos correspondentes:

Esta é a resposta que recebemos:

Isso nos mostra que, embora o iPhone 15 seja encontrado 40 vezes em um total de 424 documentos (9,4% dos documentos), ele aparece 5 vezes nos 20 documentos que corresponderam à busca semântica "bom desempenho" (25% dos documentos). Assim, podemos concluir que: a probabilidade de um iPhone 15 ser mencionado como tendo um bom desempenho é 2,7 vezes maior do que por acaso.

Conclusão

A agregação de termos relevantes pode revelar detalhes únicos de um conjunto de dados, comparando-o com o universo de documentos. Isso pode revelar relações inesperadas em nossos dados, indo além da contagem de ocorrências. Podemos aplicar termos significativos em diversos casos de uso que possibilitam funcionalidades muito interessantes, por exemplo:

• Ao trabalhar na detecção de fraudes, procure padrões — identifique transações comuns em cartões de crédito roubados.

• Análises da qualidade da marca a partir de avaliações de usuários — identifique uma marca com um número desproporcional de avaliações negativas.

• Identificar documentos classificados incorretamente — identificar documentos que pertencem a uma categoria (filtro de termos) e que usam palavras incomuns para essa categoria em sua descrição (agregação de termos relevantes).

Para o Elasticsearch, usaremos Elastic Cloud on Kubernetes (ECK), que é o operador oficial do Elasticsearch para Kubernetes e simplifica a orquestração de implantações do Kubernetes de todos os componentes do Elastic Stack.

Para saber mais sobre como implantar clusters do Elasticsearch em diferentes infraestruturas do GCP, você pode ler nossos artigos de introdução ao Google Cloud Compute e Google Cloud Marketplace.

Esforço de implantação do Elasticsearch

O que é o GKE Autopilot?

O Google Kubernetes Engine (GKE) Autopilot oferece uma experiência Kubernetes totalmente gerenciada, na qual o Google cuida da configuração do cluster, do gerenciamento de nós, da segurança e do redimensionamento, enquanto os desenvolvedores se concentram na implantação de aplicativos, permitindo que as equipes passem do código à produção em minutos com as práticas recomendadas integradas.

Quando usar o ECK no Google Cloud?

O Elastic Cloud on Kubernetes (ECK) é mais indicado para organizações com infraestrutura Kubernetes existente que desejam implantar o Elasticsearch com recursos avançados, como funções dedicadas para nós, alta disponibilidade e automação.

Como configurar o ECK na Google Cloud?

1. Faça login no Google Cloud Console.

2. No canto superior direito , cliqueno botão Cloud Shell para acessar o console e implantar o cluster GKE a partir daí. Alternativamente, você pode usar o gcloud CLI.

Lembre-se de atualizar o id do projeto com o seu durante o tutorial.

3. Ative a Google Kubernetes Engine API.

Clique em Avançar.

Agora, a API do Kubernetes Engine deve aparecer como habilitada ao pesquisar pela API do Kubernetes Engine.

4. No Cloud Shell, crie um cluster Autopilot. Vamos chamá-lo de autopilot-cluster-1 e também substituir autopilot-test pelo id do seu projeto.

5. Espere até que esteja pronto. Leva cerca de 10 minutos para ser criado.

Uma mensagem de confirmação será exibida após a configuração correta do cluster.

6. Configure o acesso na linha de comando do kubectl.

Você deverá ver:

Entrada kubeconfig gerada para autopilot-cluster-1.

7. Instale o operador Elastic Cloud on Kubernetes (ECK).

8. Vamos criar um nó único do Elasticsearch com os valores padrão.

Se quiser conferir algumas receitas de diferentes instalações, você pode visitar este link.

Lembre-se de que, se você não especificar um storageClass, o ECK usará o definido por padrão, que para o GKE é standard-rwo, que usa o driver CSI de disco persistente do Compute Engine, e criará um volume de 1 GB com ele.

Desativamos nmap porque a máquina padrão do GKE tem um valor de vm.max_map_count muito baixo. Desabilitá-lo não é recomendado para produção, mas aumenta o valor da vm.max_map_count. Você pode ler mais sobre como fazer isso aqui.

9. Vamos também implantar um cluster Kibana de nó único. Para o Kibana, vamos adicionar um LoadBalancer que nos dará um IP externo que podemos usar para acessar o Kibana a partir do nosso dispositivo.

Observe a anotação:

cloud.google.com/l4-rbs: "enabled"

É muito importante porque diz ao Autopilot que forneça um LoadBalancer voltado para o público. Se não estiver ativado, o LoadBalancer será interno.

10. Verifique se seus pods estão funcionando.

11. Você também pode run kubectl get elasticsearch e kubectl get kibana para obter estatísticas mais específicas, como versão, nós e integridade do Elasticsearch.

12. Acesse seus serviços.

Isso mostrará o URL externo do Kibana em EXTERNAL-IP. Pode levar alguns minutos para a provisão do LoadBalancer. Copie o valor de EXTERNAL-IP.

13 Obtenha a senha do Elasticsearch para o usuário 'elastic':

14. Acesse o Kibana por meio do seu navegador:

• URL: https://<EXTERNAL_IP>:5601

• Username:elastic

• Senha: 28Pao50lr2GpyguX470L2uj5 (do passo anterior)

15. Acessando a partir do seu navegador, você verá a tela de boas-vindas.

Se você quiser alterar as especificações do cluster do Elasticsearch, como mudar ou redimensionar nós, pode aplicar o manifesto yml novamente com as novas configurações:

Neste exemplo, adicionaremos mais um nó e modificaremos a RAM e a CPU. Como você pode ver, agora kubectl get elasticsearch mostra 2 nós:

O mesmo vale para Kibana:

Podemos ajustar o CPU/RAM do container e também o uso de memória do Node.js (max-old-space-size).

Lembre-se de que as reivindicações de volume existentes não podem ser reduzidas. Após aplicar a atualização, o operador fará as alterações com o menor tempo de interrupção.

Lembre-se de excluir o cluster quando terminar os testes para evitar custos desnecessários.

Próximas etapas

Se você quiser saber mais sobre o Kubernetes e o Google Kubernetes Engine, consulte estes artigos:

• Elastic Cloud on Kubernetes | Elastic Docs

• Apresentando o GKE Autopilot | Blog do Google Cloud

• Visão geral do Autopilot | Google Kubernetes Engine (GKE)

Analisaremos:

• Melhores práticas de produção

  • Tratamento de erros

  • Teste

• Ambientes sem servidor

  • Executando o cliente no Elastic Serverless

  • Executando o cliente em um ambiente de função como serviço.

Você pode conferir o código-fonte com os exemplos aqui.

Melhores práticas de produção

Tratamento de erros no Elasticsearch

Uma funcionalidade útil do cliente Elasticsearch em Node.js é que ele expõe objetos para os possíveis erros no Elasticsearch, permitindo que você os valide e trate de diferentes maneiras.

Para ver todos, execute o seguinte comando: 

Vamos voltar ao exemplo de pesquisa e tratar de alguns dos possíveis erros:

ResponseError em particular, ocorrerá quando a resposta for 4xx ou 5xx, o que significa que a solicitação está incorreta ou o servidor não está disponível.

Podemos testar esse tipo de erro gerando consultas incorretas, como tentar fazer uma consulta de termo em um campo do tipo texto:

Erro padrão:

Erro personalizado:

Também podemos capturar e lidar com cada tipo de erro de uma determinada maneira. Por exemplo, podemos adicionar lógica de repetição em um TimeoutError.

Teste

Os testes são essenciais para garantir a estabilidade do aplicativo. Para testar o código de forma isolada do Elasticsearch, podemos usar a biblioteca elasticsearch-js-mock ao criar nosso cluster.

Esta biblioteca permite instanciar um cliente muito semelhante ao real, mas que responderá à nossa configuração substituindo apenas a camada HTTP do cliente por uma camada simulada, mantendo o restante igual ao original.

Vamos instalar a biblioteca mocks e o AVA para testes automatizados.

npm install @elastic/elasticsearch-mock

npm install --save-dev ava

Vamos configurar o arquivo package.json para executar os testes. Certifique-se de que esteja assim:

Vamos agora criar um arquivo test.js e instalar nosso cliente de simulação:

Agora, adicione uma simulação para pesquisa semântica:

Agora podemos criar um teste para o nosso código, garantindo que a parte do Elasticsearch sempre retorne os mesmos resultados:

Vamos executar os testes.

npm run test

Pronto! A partir de agora, podemos testar nosso aplicativo focando 100% no código e não em fatores externos.

Ambientes sem servidor

Como executar o cliente no Elastic Serverless

Já abordamos a execução do Elasticsearch na nuvem ou em infraestrutura local; no entanto, o cliente Node.js também oferece suporte a conexões com o Elastic Cloud Serverless.

O Elastic Cloud Serverless permite que você crie um projeto onde não precisa se preocupar com a infraestrutura, já que a Elastic cuida disso internamente, e você só precisa se preocupar com os dados que deseja indexar e por quanto tempo deseja ter acesso a eles.

Do ponto de vista da utilização, o Serverless separa o processamento do armazenamento, proporcionando recursos de escalonamento automático tanto para pesquisa quanto para indexação. Isso permite que você cultive apenas os recursos de que realmente precisa.

O cliente realiza as seguintes adaptações para se conectar ao Serverless:

• Desativa a detecção de pacotes e ignora quaisquer opções relacionadas a ela.

• Ignora todos os nós passados na configuração, exceto o primeiro, e ignora quaisquer opções de filtragem e seleção de nós.

• Habilita a compressão e o método `TLSv1_2_method` (igual à configuração para o Elastic Cloud).

• Adiciona um cabeçalho HTTP `elastic-api-version` a todas as requisições.

• Utiliza `CloudConnectionPool` por padrão em vez de `WeightedConnectionPool`.

• Desativa os cabeçalhos `content-type` e `accept` fornecidos pelo fornecedor, em favor dos tipos MIME padrão.

Para conectar seu projeto sem servidor, você precisa usar o parâmetro serverMode: serverless.

Como executar o cliente em um ambiente de função como serviço

No exemplo, usamos um servidor Node.js, mas você também pode se conectar usando um ambiente de função como serviço com funções como AWS Lambda, GCP Run, etc.

Outro exemplo é conectar-se a serviços como o Vercel, que também é serverless. Você pode conferir este exemplo completo de como fazer isso, mas a parte mais relevante do endpoint de pesquisa se parece com isto:

Este endpoint reside na pasta /api e é executado a partir do lado do servidor, de forma que o cliente só tenha controle sobre o parâmetro “texto” que corresponde ao termo de pesquisa.

A implicação de usar a função como serviço é que, ao contrário de um servidor que funciona 24 horas por dia, 7 dias por semana, as funções apenas ativam a máquina que executa a função e, assim que ela termina, a máquina entra em modo de repouso para consumir menos recursos.

Essa configuração pode ser conveniente se o aplicativo não receber muitas solicitações; caso contrário, os custos podem ser elevados. Você também precisa levar em consideração o ciclo de vida das funções e os tempos de execução (que, em alguns casos, podem ser de apenas alguns segundos).

Conclusão

Neste artigo, aprendemos como lidar com erros, o que é crucial em ambientes de produção. Também abordamos os testes da nossa aplicação enquanto simulávamos o serviço Elasticsearch, o que proporciona testes confiáveis independentemente do estado do cluster e nos permite focar no nosso código.

Por fim, demonstramos como criar uma infraestrutura totalmente sem servidor, provisionando tanto o Elastic Cloud Serverless quanto um aplicativo Vercel.

Informações básicas sobre marcas d'água

Existem vários limites de "marca d'água" no seu cluster Elasticsearch que ajudam a monitorar o espaço em disco disponível. À medida que o disco de um nó se enche, o primeiro limite a ser ultrapassado será o "limite mínimo de espaço em disco". O segundo limite será então o “limite de marca d'água de disco alto”. Finalmente, será atingida a “fase de inundação do disco”. Assim que esse limite for ultrapassado, o cluster bloqueará a gravação em TODOS os índices que possuam um shard (primário ou réplica) no nó que atingiu o limite. As leituras (buscas) ainda serão possíveis.

Como prevenir e lidar com casos em que o disco está muito cheio (sobreutilização)

Existem vários métodos para lidar com casos em que o disco do Elasticsearch está muito cheio:

1. Excluir dados antigos: Normalmente, os dados não devem ser mantidos indefinidamente. Uma forma de prevenir e resolver o problema de disco cheio é garantir que, quando os dados atingirem uma certa idade, sejam arquivados e excluídos de forma confiável. Uma maneira de fazer isso é usar o ILM.

2. Adicionar capacidade de armazenamento: Se não for possível excluir os dados, talvez seja necessário adicionar mais nós de dados ou aumentar o tamanho dos discos para reter todos os dados sem afetar negativamente o desempenho. Se precisar adicionar capacidade de armazenamento ao cluster, considere se precisa adicionar apenas capacidade de armazenamento ou se deve adicionar também recursos de RAM e CPU em proporção adequada (consulte a seção sobre proporção de tamanho do disco, RAM e CPU abaixo).

Como adicionar capacidade de armazenamento ao seu cluster Elasticsearch

1. Aumente o número de nós de dados: Lembre-se de que os novos nós devem ter o mesmo tamanho que os nós existentes e a mesma versão do Elasticsearch.

2. Aumentar o tamanho dos nós existentes: Em ambientes baseados em nuvem, geralmente é fácil aumentar o tamanho do disco e a RAM/CPU nos nós existentes.

3. Aumentar apenas o tamanho do disco: Em ambientes baseados em nuvem, geralmente é relativamente fácil aumentar o tamanho do disco.

4. Instantâneo e Restauração: Se você deseja permitir que dados antigos sejam recuperados sob demanda em um processo automatizado a partir de backups, você pode criar snapshots de índices antigos, excluí-los e restaurar os dados temporariamente sob demanda a partir desses snapshots. 

5. Reduzir o número de réplicas por fragmento: Outra opção para reduzir os dados é diminuir o número de réplicas de cada fragmento. Para alta disponibilidade, o ideal é ter uma réplica por fragmento, mas quando os dados ficam mais antigos, pode ser possível trabalhar sem réplicas. Isso geralmente funciona se os dados forem persistentes ou se você tiver um backup para restaurar, se necessário.

6. Criar alertas: Para evitar que os discos fiquem cheios no futuro e agir de forma proativa, você deve criar alertas com base no uso do disco que o notificarão quando o disco começar a ficar cheio. 

Como prevenir e lidar com casos em que a capacidade do disco está subutilizada

Se a capacidade do seu disco estiver subutilizada, existem várias opções para reduzir o volume de armazenamento no seu cluster.

Como reduzir o volume de armazenamento em um cluster Elasticsearch

Existem vários métodos para reduzir o volume de armazenamento de um cluster.

1. Reduzir o número de nós de dados

Se você deseja reduzir o armazenamento de dados e também reduzir os recursos de RAM e CPU na mesma proporção, então esta é a estratégia mais fácil. A desativação de nós desnecessários provavelmente proporcionará a maior economia de custos.

Antes de desativar o nó, você deve:

• Certifique-se de que o nó a ser desativado não seja necessário como nó MESTRE. Você deve sempre ter pelo menos três nós com a função de nó MESTRE.

• Migre os fragmentos de dados para fora do nó a ser desativado.

2. Substitua os nós existentes por nós menores.

Se não for possível reduzir ainda mais o número de nós (normalmente, 3 seria uma configuração mínima), então você pode querer diminuir o tamanho dos nós existentes. Lembre-se de que é recomendável garantir que todos os nós de dados tenham a mesma quantidade de memória RAM e tamanho de disco, já que o balanceamento dos shards é feito com base no número de shards por nó.

O processo seria o seguinte:

• Adicione novos nós menores ao cluster.

• Migre os fragmentos para longe dos nós que serão desativados.

• Desligue os nós antigos.

3. Reduzir o tamanho do disco nos nós

Se você deseja reduzir APENAS o tamanho do disco nos nós, sem alterar a RAM ou a CPU geral do cluster, então você pode reduzir o tamanho do disco para cada nó individualmente. Reduzir o tamanho do disco em um nó do Elasticsearch não é um processo trivial.

A maneira mais fácil de fazer isso geralmente seria:

• Migrar fragmentos do nó

• Pare o nó

• Monte um novo volume de dados no nó com o tamanho apropriado.

• Copie todos os dados do volume de disco antigo para o novo volume.

• Desprenda o volume antigo A.

• Inicie o nó e migre os fragmentos de volta para o nó.

Isso exige que você tenha capacidade suficiente nos outros nós para armazenar temporariamente os fragmentos extras do nó durante esse processo. Em muitos casos, o custo de gerenciamento desse processo pode exceder a economia potencial no uso de disco. Por esse motivo, pode ser mais simples substituir o nó por completo por um novo nó com o tamanho de disco desejado (consulte “Substituir nós existentes por nós menores” acima).

Ao pagar por recursos desnecessários, os custos podem ser reduzidos otimizando a utilização desses recursos.

A relação entre o tamanho do disco, a RAM e a CPU.

A proporção ideal entre capacidade de disco e RAM no seu cluster dependerá do seu caso de uso específico. Por esse motivo, ao considerar alterações na sua capacidade de armazenamento, você também deve avaliar se as proporções atuais de disco/RAM/CPU estão adequadamente equilibradas e se, consequentemente, você precisa adicionar/reduzir RAM/CPU na mesma proporção.

Os requisitos de RAM e CPU dependem do volume de atividade de indexação , do número e tipo de consultas, bem como da quantidade de dados que está sendo pesquisada e agregada. Isso geralmente é proporcional à quantidade de dados armazenados no cluster e, portanto, também deve estar relacionado ao tamanho do disco.

A proporção entre a capacidade do disco e a RAM pode variar dependendo do uso. Veja alguns exemplos aqui:

Atividade do índice

Retenção

Atividade de pesquisa

Capacidade do disco

BATER

Aplicativo de busca empresarial

Ingestão moderada de toras

Longo

Luz

2TB

32 GB

Monitoramento de aplicativos

Ingestão intensiva de toras

Curto

Luz

1TB

32 GB

Comércio eletrônico

Indexação de dados leves

Indeterminado

Pesado

500 GB

32 GB

Lembre-se de que modificar a configuração das máquinas de nó deve ser feito com cuidado, pois pode causar indisponibilidade do nó e você precisa garantir que os shards não comecem a migrar para seus outros nós já sobrecarregados.

Nesta primeira parte, vamos analisar:

• Ambiente

  • Frontend, backend ou serverless?

  • Conectando o cliente

• Documentos de indexação

  • Cliente Elasticsearch

  • Mapeamentos semânticos

  • Auxiliar em massa

• Dados de pesquisa

  • Consulta Lexical

  • Consulta semântica

  • Consulta híbrida

Você pode conferir o código-fonte com os exemplos aqui.

O que é o cliente Elasticsearch para Node.js?

O cliente Elasticsearch para Node.js é uma biblioteca JavaScript que converte as chamadas HTTP REST da API do Elasticsearch em código JavaScript. Isso facilita o manuseio e permite o uso de ferramentas auxiliares que simplificam tarefas como a indexação de documentos em lotes.

Ambiente

Frontend, backend ou serverless?

Para criar nosso aplicativo de busca usando o cliente JavaScript, precisamos de pelo menos dois componentes: um cluster Elasticsearch e um ambiente de execução JavaScript para executar o cliente.

O cliente JavaScript é compatível com todas as soluções Elasticsearch (Cloud, on-premise e Serverless), e não há grandes diferenças entre elas, já que o cliente lida com todas as variações internamente, então você não precisa se preocupar com qual usar.

O ambiente de execução JavaScript, no entanto, deve ser executado a partir do servidor e não diretamente do navegador.

Isso ocorre porque, ao acessar o Elasticsearch pelo navegador, o usuário pode obter informações confidenciais, como a chave da API do cluster, o host ou a própria consulta. A Elasticsearch recomenda nunca expor o cluster diretamente à internet e usar uma camada intermediária que abstraia todas essas informações, de forma que o usuário possa ver apenas os parâmetros. Você pode ler mais sobre este tópico aqui.

Sugerimos usar um esquema como este:

Nesse caso, o cliente envia apenas os termos de pesquisa e uma chave de autenticação para o seu servidor, enquanto o seu servidor mantém o controle total da consulta e da comunicação com o Elasticsearch.

Conectando o cliente

Comece criando uma chave de API seguindo estes passos.

Seguindo o exemplo anterior, criaremos um servidor Express simples e nos conectaremos a ele usando um cliente de um servidor Node.js.

Vamos inicializar o projeto com o NPM e instalar o cliente Elasticsearch e o Express. Esta última é uma biblioteca para iniciar servidores em Node.js. Usando o Express, podemos interagir com nosso backend via HTTP.

Vamos inicializar o projeto:

npm init -y

Instalar dependências:

npm install @elastic/elasticsearch express split2 dotenv

Deixe-me explicar melhor:

• @elastic/elasticsearch: É o cliente oficial do Node.js.

• Express: Isso nos permitirá criar um servidor Node.js leve para expor o Elasticsearch.

• split2: Divide linhas de texto em um fluxo. Útil para processar nossos arquivos ndjson linha por linha.

• dotenv: Permite gerenciar variáveis de ambiente usando um arquivo .env. arquivo

Crie um arquivo .env Abra o arquivo na raiz do projeto e adicione as seguintes linhas:

Dessa forma, podemos importar essas variáveis usando o pacote dotenv .

Crie um arquivo server.js :

Este código configura um servidor Express.js básico que escuta na porta 3000 e se conecta a um cluster Elasticsearch usando uma chave de API para autenticação. Inclui um endpoint /ping que, quando acessado por meio de uma solicitação GET, consulta o cluster Elasticsearch para obter informações básicas usando o método .info() do cliente Elasticsearch. 

Se a consulta for bem-sucedida, ela retorna as informações do cluster em formato JSON; caso contrário, retorna uma mensagem de erro. O servidor também utiliza o middleware body-parser para lidar com os corpos das requisições JSON.

Execute o arquivo para iniciar o servidor:

node server.js

A resposta deve ser semelhante a esta:

E agora, vamos consultar o endpoint /ping para verificar o status do nosso cluster Elasticsearch.

Documentos de indexação

Uma vez conectados, podemos indexar documentos usando mapeamentos como semantic_text para pesquisa semântica e text para consultas de texto completo. Com esses dois tipos de campo, também podemos fazer buscas híbridas.

Criaremos um novo arquivo load.js para gerar os mapeamentos e carregar os documentos.

Cliente Elasticsearch

Primeiro precisamos instanciar e autenticar o cliente:

Mapeamentos semânticos

Criaremos um índice com dados sobre um hospital veterinário. Armazenaremos as informações do dono, do animal de estimação e os detalhes da visita.

Os dados nos quais desejamos realizar uma busca de texto completo, como nomes e descrições, serão armazenados como texto. Os dados das categorias, como a espécie ou raça do animal, serão armazenados como palavras-chave.

Além disso, copiaremos os valores de todos os campos para um campo semantic_text para podermos executar também uma pesquisa semântica nessas informações.

Auxiliar em massa

Outra vantagem do cliente é que podemos usar a função auxiliar de indexação em lotes. A função auxiliar de processamento em lote nos permite lidar facilmente com aspectos como concorrência, novas tentativas e o que fazer com cada documento que passa pela função, seja com sucesso ou com falha.

Uma característica interessante dessa ferramenta auxiliar é a possibilidade de trabalhar com fluxos de dados. Essa função permite enviar um arquivo linha por linha, em vez de armazenar o arquivo inteiro na memória e enviá-lo para o Elasticsearch de uma só vez.

Para enviar os dados para o Elasticsearch, crie um arquivo chamado data.ndjson na raiz do projeto e adicione as informações abaixo (alternativamente, você pode baixar o arquivo com o conjunto de dados aqui):

Usamos o split2 para transmitir as linhas do arquivo enquanto o auxiliar de processamento em lote as envia para o Elasticsearch.

O código acima lê um arquivo .ndjson. indexa cada objeto JSON em um índice Elasticsearch especificado usando o método helpers.bulk . Ele transmite o arquivo usando createReadStream e split2, configura metadados de indexação para cada documento e registra quaisquer documentos que não puderem ser processados. Após a conclusão, registra o número de itens indexados com sucesso.

Alternativamente à função indexData , você pode fazer o upload do arquivo diretamente pela interface do usuário usando o Kibana e usar a interface de upload de arquivos de dados.

Executamos o arquivo para enviar os documentos para o nosso cluster Elasticsearch.

node load.js

Buscando dados no Elasticsearch

Voltando ao nosso arquivo server.js , criaremos diferentes endpoints para realizar buscas lexicais, semânticas ou híbridas.

Em resumo, esses tipos de pesquisa não são mutuamente exclusivos, mas dependerão do tipo de pergunta que você precisa responder.

Tipo de consulta

Caso de uso

Exemplo de pergunta

Consulta lexical

As palavras ou radicais presentes na pergunta provavelmente aparecerão nos documentos indexados. Similaridade entre tokens na pergunta e nos documentos.

Estou procurando uma camiseta esportiva azul.

Consulta semântica

É improvável que as palavras da pergunta apareçam nos documentos. Similaridade conceitual entre a pergunta e os documentos.

Estou procurando roupas para clima frio.

Busca híbrida

A questão contém componentes lexicais e/ou semânticos. Similaridade semântica e de tokens entre a pergunta e os documentos.

Estou procurando um vestido tamanho P para um casamento na praia.

As partes lexicais da pergunta provavelmente fazem parte de títulos e descrições, ou nomes de categorias, enquanto as partes semânticas são conceitos relacionados a esses campos. "Azul" provavelmente será o nome de uma categoria ou parte de uma descrição, e "casamento na praia" provavelmente não será, mas pode estar semanticamente relacionado a roupas de linho.

Consulta lexical (/search/lexic?q=)<query_term>

A busca lexical, também chamada de busca de texto completo, significa pesquisar com base na similaridade de tokens; ou seja, após uma análise, os documentos que incluem os tokens da busca serão retornados.

Você pode conferir nosso tutorial prático de busca lexical aqui.

Testamos com: corte de unhas

Responder:

Consulta semântica<query_term> (/search/semantic?q=)

A busca semântica, diferentemente da busca lexical, encontra resultados que são semelhantes ao significado dos termos de busca por meio de busca vetorial.

Você pode conferir nosso tutorial prático de busca semântica aqui.

Fizemos o teste com a seguinte pergunta: Quem fez pedicure?

Responder:

Consulta híbrida (/search/hybrid?q=)<query_term>

A busca híbrida permite combinar a busca semântica e a busca lexical, obtendo assim o melhor dos dois mundos: a precisão da busca por token, juntamente com a proximidade de significado da busca semântica.

Fizemos o teste com a pergunta: “Quem fez pedicure ou tratamento dentário?”

Resposta.

Conclusão

Nesta primeira parte da nossa série, explicamos como configurar nosso ambiente e criar um servidor com diferentes endpoints de pesquisa para consultar os documentos do Elasticsearch, seguindo as melhores práticas de cliente/servidor. Confira a segunda parte da nossa série, na qual você aprenderá as melhores práticas de produção e como executar o cliente Elasticsearch Node.js em ambientes Serverless.

O papel das réplicas no Elasticsearch

No Elasticsearch, um índice é uma coleção de documentos que são particionados em vários shards primários. Cada fragmento primário é um índice Apache Lucene independente, e os documentos dentro de um índice são distribuídos entre todos os fragmentos primários. Para garantir alta disponibilidade e redundância de dados, o Elasticsearch permite que cada shard tenha uma ou mais cópias, conhecidas como réplicas. A configuração number_of_replicas controla o número de shards de réplica (cópias) que o Elasticsearch cria para cada shard primário em um índice. Por padrão, o Elasticsearch cria uma réplica para cada shard primário, mas isso pode ser alterado de acordo com os requisitos do seu sistema.

Configurando o número de réplicas

A configuração number_of_replicas pode ser definida no momento da criação do índice ou atualizada posteriormente. Veja como você pode configurar isso durante a criação do índice:

Neste exemplo, o Elasticsearch criará duas réplicas para cada shard primário no índice my_index .

Para atualizar a configuração number_of_replicas de um índice existente, você pode usar a API _settings :

Este comando atualizará o índice my_index para ter três réplicas para cada fragmento primário.

Implicações da configuração number_of_replicas

A configuração number_of_replicas tem um impacto significativo no desempenho e na resiliência do seu cluster Elasticsearch. Aqui estão alguns pontos importantes a serem considerados:

1. Redundância e disponibilidade de dados: Aumentar o number_of_replicas melhora a disponibilidade dos seus dados, criando mais cópias de cada fragmento. Se um nó falhar, o Elasticsearch ainda poderá fornecer dados a partir dos fragmentos de réplica nos nós restantes.

2. Desempenho de busca: Fragmentos de réplica podem atender solicitações de leitura, portanto, ter mais réplicas pode melhorar o desempenho de busca, distribuindo a carga por mais fragmentos.

3. Desempenho de gravação: No entanto, cada operação de gravação deve ser realizada em todas as cópias de um fragmento. Portanto, um number_of_replicas mais alto pode diminuir o desempenho da indexação , pois aumenta o número de operações que devem ser realizadas para cada gravação.

4. Requisitos de armazenamento: Mais réplicas significam mais espaço de armazenamento. Você deve garantir que seu cluster tenha capacidade suficiente para armazenar as réplicas adicionais.

5. Resiliência à falha do nó: O number_of_replicas deve ser definido considerando o número de nós em seu cluster. Se o number_of_replicas for igual ou maior que o número de nós, seu cluster pode tolerar a falha de vários nós sem perda de dados.

Melhores práticas para definir o número de réplicas

A configuração ideal number_of_replicas depende dos requisitos específicos do seu sistema. No entanto, aqui estão algumas boas práticas gerais:

• Para um cluster de nó único, number_of_replicas deve ser definido como 0, pois não há outros nós para armazenar réplicas.

• Para um cluster com vários nós, number_of_replicas deve ser definido como pelo menos 1 para garantir redundância de dados e alta disponibilidade.

• Se o desempenho da pesquisa for uma prioridade, considere aumentar o number_of_replicas. No entanto, tenha em mente a relação de compromisso entre o desempenho de gravação e os requisitos de armazenamento.

• Certifique-se sempre de que seu cluster tenha capacidade suficiente para armazenar as réplicas adicionais.

Método 1: Usando a API de atualização

A API de atualização fornece um script que modifica a origem de um documento para atualizar o documento. Você pode usar essa API para apagar o campo de um documento, bastando deixar o campo como "null". Veja como fazer isso:

1. Identifique o índice, o tipo de documento (se estiver usando o Elasticsearch 6.x ou anterior) e o ID do documento que você deseja atualizar.

2. Utilize a API de atualização com um script que defina o campo como nulo ou, melhor ainda, que o remova do documento de origem. O exemplo a seguir demonstra como excluir o campo “field_to_delete” de um documento com ID “1” no índice “my_index”:

3. Execute a solicitação. Se a operação for bem-sucedida, o Elasticsearch retornará uma resposta indicando que o documento foi atualizado.

Nota: Este método apenas remove o campo do documento especificado. O campo ainda existirá no mapeamento e em outros documentos do índice.

Método 2: Reindexação com uma fonte modificada

Para apagar um campo de todos os documentos em um índice, você pode usar a API de reindexação para criar um novo índice com a fonte modificada. Veja como:

1. Crie um novo índice com as mesmas configurações e mapeamentos do índice original. Você pode usar a API Get Index para recuperar as configurações e os mapeamentos do índice original.

2. Utilize a API Reindex para copiar documentos do índice original para o novo índice, removendo o campo da origem. O exemplo a seguir demonstra como excluir o campo “field_to_delete” de todos os documentos no índice “my_index”:

3. Verifique se o novo índice contém os documentos corretos com o campo removido.

4. Se tudo estiver correto, você pode excluir o índice original e, se necessário, adicionar um alias ao novo índice com o mesmo nome do índice original.

Método 3: atualizando o mapeamento e reindexando

Se você deseja excluir um campo do mapeamento e todos os documentos em um índice, pode atualizar o mapeamento e, em seguida, reindexar os documentos. Eis como fazer isso:

1. Crie um novo índice com as mesmas configurações do índice original.

2. Recupere os mapeamentos do índice original usando a API Get Mapping.

3. Modifique os mapeamentos removendo o campo que deseja excluir.

4. Aplique os mapeamentos modificados ao novo índice usando a API Put Mapping.

5. Utilize a API Reindex para copiar documentos do índice original para o novo índice, conforme descrito no Método 2.

6. Verifique se o novo índice contém os documentos corretos com o campo removido e se o campo não está presente no mapeamento.

7. Se tudo estiver correto, você pode apagar o índice original e, se necessário, adicionar um alias ao novo índice com o nome do índice original.

Conclusão

Neste artigo, discutimos três métodos para excluir um campo de um documento no Elasticsearch: usando a API de atualização, reindexando com uma fonte modificada e atualizando o mapeamento e reindexando. Cada método tem seus próprios casos de uso e vantagens e desvantagens, portanto, escolha aquele que melhor se adapta às suas necessidades. Lembre-se sempre de testar as alterações e verificar os resultados antes de aplicá-las em ambientes de produção.

Historicamente, muitas pessoas usavam o tipo de campo nestedcomo um mecanismo para unir diferentes índices. No entanto, era limitado devido a consultas caras e suporte incompleto no Kibana, especificamente visualizações do Lens.

Este artigo se aprofundará no processo de junção de dois índices no Elasticsearch, com foco nas seguintes abordagens:

1. Usando a consulta terms

2. Usando o processador enrich em pipelines de ingestão

3. Plug-in de filtro Logstash elasticsearch

4. ES|QL ENRICH

5. ES|QL LOOKUP JOIN

Usando os termos consulta

A consulta de termos é uma das maneiras mais eficazes de unir dois índices no Elasticsearch. Esta consulta é usada para recuperar documentos que contêm um ou mais termos exatos em um campo específico. Aqui discutimos como usá-lo para unir dois índices.

Primeiro, você precisa recuperar os dados necessários do primeiro índice. Isso pode ser feito usando uma simples solicitação GET e extraindo os valores do atributo _source .

Depois de obter os dados do primeiro índice, você pode usá-los para consultar o segundo índice. Isso é feito usando a consulta terms , onde você especifica o campo e os valores que deseja corresponder.

Aqui está um exemplo:

Neste exemplo, field_in_second_index é o campo no segundo índice que você deseja corresponder aos valores do primeiro índice. value1_from_first_index e value2_from_first_index são os valores do primeiro índice que você deseja corresponder no segundo índice.

A consulta de termos também fornece suporte para executar as duas etapas acima de uma só vez usando uma técnica chamada pesquisa de termos. O Elasticsearch se encarregará de recuperar de forma transparente os valores correspondentes de outro índice. Por exemplo, se você tiver um índice de equipes contendo uma lista de jogadores:

É possível consultar um índice de pessoas para todas as pessoas que jogam no time1, conforme mostrado abaixo:

No exemplo acima, o Elasticsearch recuperará de forma transparente os nomes dos jogadores do documento com id team1 no índice de equipes (ou seja, “john”, “bill” e “michael”) e encontrar todos os documentos no índice de pessoas que contenham qualquer um desses valores no campo de nome.

Para os curiosos, a consulta SQL equivalente seria:

Usando o processador de enriquecimento

O processador enriché outra ferramenta poderosa que pode ser usada para unir dois índices no Elasticsearch. Este processador enriquece os dados de documentos recebidos adicionando dados de um índice de enriquecimento predefinido.

Veja como você pode usar o processador de enriquecimento para unir dois índices:

1. Primeiro, você precisa criar uma política de enriquecimento. Esta política define qual índice usar para enriquecimento, qual campo corresponder e qual(is) campo(s) usar para enriquecimento de documentos recebidos.

Aqui está um exemplo:

2. Depois que a política for criada, você precisa executá-la para criar o índice de enriquecimento a partir da sua política recém-criada:

Isso criará um novo índice enriquecido oculto que será usado durante o enriquecimento. Dependendo do tamanho do índice de origem, esta operação pode levar algum tempo. Certifique-se de que a política de enriquecimento esteja totalmente criada antes de prosseguir para a próxima etapa.

3. Após a criação da política de enriquecimento, você pode usar o processador de enriquecimento em um pipeline de ingestão para enriquecer os dados de documentos recebidos:

Neste exemplo, field_in_second_index é o campo no segundo índice que precisa corresponder ao match_field do primeiro índice. enriched_field é o novo campo no segundo índice que conterá os dados enriquecidos do enrich_fields no primeiro índice.

Uma desvantagem dessa abordagem é que, se os dados mudarem em first_index, a política de enriquecimento precisará ser reexecutada. O índice enriquecido não é atualizado ou sincronizado automaticamente a partir do índice de origem do qual foi criado. Entretanto, se first_index for relativamente estável, então essa abordagem funciona bem.

Plug-in de filtro ElasticSearch do Logstash

Se estiver usando o Logstash, outra opção semelhante ao processador enrich descrito acima é usar o plug-in de filtro elasticsearch para adicionar campos relevantes ao evento com base em uma consulta especificada. A configuração do nosso pipeline Logstash residiria em um arquivo .conf , como my-pipeline.conf.

Vamos imaginar que nosso pipeline está extraindo logs do Elasticsearch usando o plugin de entrada elasticsearch , com uma consulta para restringir a seleção:

Se quisermos enriquecer essas mensagens com informações de um determinado índice, podemos usar o plugin de filtro elasticsearchna seção filter para enriquecer nossos logs:

O código acima encontrará os documentos do índice index_name onde type é o início e o campo de operação corresponde ao opid especificado e, em seguida, copiará o valor do campo @timestamp em um novo campo chamado started.

Os documentos enriquecidos seriam então enviados para a fonte de saída apropriada, neste caso para o Elasticsearch usando o plugin de saída elasticsearch :

Se você já estiver usando o Logstash, esta opção pode ser útil para consolidar sua lógica de enriquecimento em um único lugar e processá-la conforme novos eventos chegam. No entanto, se você não fizer isso, isso adicionará complexidade à sua solução e será outro componente que você precisa executar e manter.

ES|QL ENRIQUECER

A introdução do ES|QL, que foi disponibilizado gratuitamente na versão 8.14, é uma linguagem de consulta canalizada suportada pelo Elasticsearch que permite a filtragem, transformação e análise de dados. Usar o comando de processamento ENRICH nos permite adicionar dados de índices existentes usando uma política de enriquecimento.

Tomando a mesma política my_enrich_policy do exemplo original do processador de enriquecimento, o exemplo ES|QL ficaria assim:

Também é possível substituir os campos de correspondência e enriquecimento, que em nosso exemplo são field_in_first_index e field_to_enrich respectivamente:

Embora a limitação óbvia seja que você precisa especificar uma política de enriquecimento primeiro, o ES|QL oferece a flexibilidade de ajustar os campos conforme necessário.

ES|QL LOOKUP JOIN

O Elasticsearch 8.18 apresenta uma nova maneira de unir índices no Elasticsearch, o comando LOOKUP JOIN . Este comando opera como um LEFT OUTER JOIN no estilo SQL usando o novo modo de índice de pesquisa no lado direito da junção.

Revisitando nosso exemplo anterior, a nova consulta é a seguinte, onde match_field precisa estar presente em first_index e second_index:

A vantagem do LOOKUP JOIN sobre as outras abordagens é que ele não requer nenhuma política enrich e, portanto, o processamento adicional associado à configuração da política. É útil ao trabalhar com dados de enriquecimento que mudam frequentemente, diferentemente das outras abordagens discutidas neste artigo.

Conclusão

Concluindo, embora o Elasticsearch não suporte operações de junção tradicionais, ele fornece vários recursos que podem ser usados para obter resultados semelhantes. Especificamente, abordamos como realizar operações de junção usando:

1. A consulta terms

2. O processador enrich em pipelines de ingestão

3. Plug-in de filtro Logstash elasticsearch

4. ES|QL ENRICH

5. ES|QL LOOKUP JOIN

É importante observar que esses métodos têm suas limitações e devem ser usados criteriosamente com base nos requisitos específicos e na natureza dos dados.

Mecanismos de pontuação no Elasticsearch

O Elasticsearch utiliza, por padrão, um modelo de pontuação chamado Practical Scoring Function (BM25). Este modelo é baseado na teoria probabilística de recuperação de informação e leva em consideração fatores como frequência de termos, frequência inversa de documentos e normalização do comprimento do campo. Vamos discutir brevemente esses fatores:

1. Frequência do termo (TF): Representa o número de vezes que um termo aparece em um documento. Uma maior frequência de um termo indica uma relação mais forte entre o termo e o documento.

2. Frequência Inversa de Documentos (IDF): Este fator mede a importância de um termo em toda a coleção de documentos. Um termo que aparece em muitos documentos é considerado menos importante, enquanto um termo que aparece em menos documentos é considerado mais importante.

3. Normalização do comprimento do campo: Este fator leva em consideração o comprimento do campo no qual o termo aparece. Campos mais curtos recebem maior peso, pois o termo é considerado mais significativo em um campo mais curto.

Usando a API Explain

A API Explain do Elasticsearch é uma ferramenta valiosa para entender o processo de pontuação. Fornece uma explicação detalhada de como a pontuação de um documento específico foi calculada. Para usar a API Explain, você precisa enviar uma solicitação GET para o seguinte endpoint:

No corpo da solicitação, você precisa fornecer a consulta para a qual deseja entender a pontuação. Eis um exemplo:

A resposta da API Explain incluirá uma descrição detalhada do processo de pontuação, incluindo os fatores individuais (TF, IDF e normalização do comprimento do campo) e suas contribuições para a pontuação final. Eis um exemplo de resposta:

Neste exemplo, a resposta mostra que a pontuação de 1,2 é um produto do valor IDF (2,2) e do valor tfNorm (0,5). A explicação detalhada ajuda a compreender os fatores que contribuem para a pontuação e pode ser útil para refinar a relevância da pesquisa.

Conclusão

A pontuação do Elasticsearch é um aspecto crucial para fornecer resultados de pesquisa relevantes. Ao entender os mecanismos de pontuação e usar a API Explain, você pode obter insights sobre os fatores que afetam os resultados da pesquisa e otimizar suas consultas de pesquisa para obter maior relevância e desempenho.

Técnicas avançadas para realizar buscas por dois campos

1. Consulta com múltiplas correspondências

Uma consulta de correspondência múltipla permite pesquisar uma única sequência de consulta em vários campos. Isso é útil quando você deseja encontrar documentos que contenham a string de consulta fornecida em qualquer um dos dois campos. Aqui está um exemplo de uma consulta de correspondência múltipla que busca o termo “exemplo” nos campos “título” ou “descrição”:

2. Consulta booleana

Uma consulta booleana permite combinar várias consultas usando lógica booleana. Você pode usar a cláusula “should” para pesquisar documentos que correspondam à consulta em qualquer um dos dois campos. Aqui está um exemplo de uma consulta booleana que busca o termo “exemplo” nos campos “título” e “descrição”:

3. Reforço de campos em tempo de consulta

Às vezes, você pode querer dar mais importância a um campo em detrimento de outro durante a pesquisa. Você pode conseguir isso aplicando um fator de reforço ao campo no momento da consulta. Um valor de reforço mais alto dá mais peso ao campo, tornando-o mais propenso a influenciar a pontuação final da pesquisa. Aqui está um exemplo de uma consulta com múltiplas correspondências e um fator de reforço aplicado ao campo "título":

Neste exemplo, o campo "título" tem um fator de reforço de 3, tornando-o três vezes mais importante que o campo "descrição" na determinação da pontuação de pesquisa.

4. Combinando consultas com diferentes fatores de otimização

Você também pode combinar várias consultas com diferentes fatores de reforço usando uma consulta booleana. Isso permite ajustar a importância de cada campo nos resultados da pesquisa. Aqui está um exemplo de uma consulta booleana com diferentes fatores de ponderação aplicados aos campos “título” e “descrição”:

Neste exemplo, o campo "título" tem um fator de reforço de 3, enquanto o campo "descrição" tem um fator de reforço de 1.

Conclusão

A busca por dois campos no Elasticsearch pode ser realizada usando técnicas avançadas como consultas de correspondência múltipla, consultas booleanas e otimização de campos em tempo de consulta. Ao combinar essas técnicas, você pode criar resultados de pesquisa mais precisos e relevantes para seus usuários. Experimente diferentes combinações de consultas e fatores de otimização para encontrar a configuração de pesquisa ideal para o seu caso de uso específico.

Todas as consultas e saídas completas mencionadas neste artigo podem ser encontradas em nosso repositório de código do Elasticsearch Labs.

Por que implementar a Quantização Binária Aprimorada (BBQ) no seu caso de uso?

Embora a matemática seja fascinante, é crucial entender completamente por que suas buscas vetoriais permanecem precisas. Em última análise, tudo se resume à compressão, já que, com os algoritmos de busca vetorial atuais, o limite é a velocidade de leitura dos dados. Portanto, se você conseguir armazenar todos esses dados na memória, obterá um aumento significativo de velocidade em comparação com a leitura do armazenamento (a memória é aproximadamente 200 vezes mais rápida que os SSDs).

Há algumas coisas que você precisa ter em mente:

• Índices baseados em gráficos como HNSW (Hierarchical Navigable Small World) são os mais rápidos para recuperação de vetores.

  • HNSW: Um algoritmo de busca aproximado do vizinho mais próximo que constrói uma estrutura de gráfico multicamadas para permitir buscas eficientes de similaridade de alta dimensão.

• O HNSW é fundamentalmente limitado em velocidade pela velocidade de leitura de dados da memória ou, no pior caso, do armazenamento.

  • O ideal é que você consiga carregar todos os seus vetores armazenados na memória.

• Os modelos de incorporação geralmente produzem vetores com precisão float32, 4 bytes por número de ponto flutuante.

• E, finalmente, dependendo de quantos vetores e/ou dimensões você tem, você pode rapidamente ficar sem memória para manter todos os seus vetores.

Considerando isso como certo, você verá que um problema surge rapidamente quando você começa a ingerir milhões ou até bilhões de vetores, cada um com potencialmente centenas ou até milhares de dimensões. A seção intitulada “Números aproximados sobre as taxas de compressão” fornece alguns números aproximados.

O que você precisa para começar?

Para começar, você precisará do seguinte:

• Se estiver usando o Elastic Cloud ou no local, você precisará de uma versão do Elasticsearch superior a 8.18. Embora o BBQ tenha sido introduzido na versão 8.16, neste artigo, você usará vector_rescore, que foi introduzido na versão 8.18.

• Além disso, você também precisará garantir que haja um nó de aprendizado de máquina (ML) no seu cluster. (Observação: um nó de ML com no mínimo 4 GB é necessário para carregar o modelo, mas você provavelmente precisará de nós muito maiores para cargas de trabalho de produção completas.)

• Se estiver usando o Serverless, você precisará selecionar uma instância otimizada para vetores.

• Você também precisará de um nível básico de conhecimento sobre bancos de dados vetoriais. Se você ainda não estiver familiarizado com os conceitos de pesquisa vetorial no Elastic, talvez seja interessante primeiro conferir os seguintes recursos:

  • Navegando em um banco de dados de vetores elásticos

  • As grandes ideias por trás da geração aumentada de recuperação

Implementação de Quantização Binária Aprimorada (BBQ)

Para manter este blog simples, você usará funções integradas quando elas estiverem disponíveis. Neste caso, você tem o modelo de incorporação vetorial .multilingual-e5-small que será executado diretamente dentro do Elasticsearch em um nó de aprendizado de máquina. Observe que você pode substituir o modelo text_embedding pelo incorporador de sua escolha (OpenAI, Google AI Studio, Cohere e muitos outros). Se o seu modelo preferido ainda não estiver integrado, você também pode trazer seus próprios embeddings de vetores densos.)

Primeiro, você precisará criar um ponto final de inferência para gerar vetores para um determinado trecho de texto. Você executará todos esses comandos no Kibana Dev Tools Console. Este comando fará o download do .multilingual-e5-small. Se ainda não existir, ele configurará seu endpoint; isso pode levar um minuto para ser executado. Você pode ver a saída esperada no arquivo 01-create-an-inference-endpoint-output.json na pasta Saídas.

Quando isso retornar, seu modelo será configurado e você poderá testar se ele funciona conforme o esperado com o seguinte comando. Você pode ver a saída esperada no arquivo 02-embed-text-output.json na pasta Saídas.

Se você tiver problemas com seu modelo treinado não sendo alocado a nenhum nó, talvez seja necessário iniciar seu modelo manualmente.

Agora vamos criar um novo mapeamento com 2 propriedades, um campo de texto padrão (my_field) e um campo vetorial denso (my_vector) com 384 dimensões para corresponder à saída do modelo de incorporação. Você também substituirá o index_options.type to bbq_hnsw. Você pode ver a saída esperada no arquivo 03-create-byte-qauntized-index-output.json na pasta Saídas.

Para garantir que o Elasticsearch gere seus vetores, você pode usar um Ingest Pipeline. Este pipeline exigirá 3 coisas: o ponto final, (model_id), o input_field para o qual você deseja criar vetores e o output_field para armazenar esses vetores. O primeiro comando abaixo criará um pipeline de ingestão de inferência, que usa o serviço de inferência nos bastidores, e o segundo testará se o pipeline está funcionando corretamente. Você pode ver a saída esperada no arquivo 04-create-and-simulate-ingest-pipeline-output.json na pasta Outputs. 

Agora você está pronto para adicionar alguns documentos com os dois primeiros comandos abaixo e testar se suas pesquisas funcionam com o terceiro comando. Você pode verificar a saída esperada no arquivo 05-bbq-index-output.json na pasta Outputs. 

Conforme recomendado nesta publicação, a repontuação e a sobreamostragem são recomendadas quando você dimensiona para quantidades não triviais de dados porque elas ajudam a manter alta precisão de recall enquanto se beneficiam das vantagens da compressão. A partir da versão 8.18 do Elasticsearch, você pode fazer isso dessa maneira usando rescore_vector. A saída esperada está no arquivo 06-bbq-search-8-18-output.json na pasta Outputs.

Como essas pontuações se comparam àquelas que você obteria com dados brutos? Se você fizer tudo acima novamente, mas com index_options.type: hnsw, verá que as pontuações são muito comparáveis. Você pode ver a saída esperada no arquivo 07-raw-vector-output.json na pasta Outputs.

Números aproximados sobre as taxas de compressão

Os requisitos de armazenamento e memória podem rapidamente se tornar um desafio significativo ao trabalhar com pesquisa vetorial. A análise a seguir ilustra como diferentes técnicas de quantização reduzem drasticamente o consumo de memória de dados vetoriais.

Vetores (V)

Dimensões (D)

cru (V x D x 4)

int8 (V x (D x 1 + 4))

int4 (V x (D x 0,5 + 4))

churrasco (V x (D x 0,125 + 4))

10.000.000

384

14,31 GB

3,61 GB

1,83 GB

0,58 GB

50.000.000

384

71,53 GB

18,07 GB

9,13 GB

2,89 GB

100.000.000

384

143,05 GB

36,14 GB

18,25 GB

5,77 GB

Conclusão

BBQ é uma otimização que você pode aplicar aos seus dados vetoriais para compressão sem sacrificar a precisão. Ele funciona convertendo vetores em bits, permitindo que você pesquise os dados de forma eficaz e capacitando você a dimensionar seus fluxos de trabalho de IA para acelerar pesquisas e otimizar o armazenamento de dados.

Aprendizagem adicional

Se você estiver interessado em aprender mais sobre churrasco, não deixe de conferir os seguintes recursos:

• Quantização Binária (BBQ) em Lucene e Elasticsearch

• Melhor Quantização Binária (BBQ) vs. Quantização de Produto

• Quantização Escalar Otimizada: Quantização Binária Ainda Melhor

• Melhor Quantização Binária (BBQ): De Bytes a BBQ, O Segredo para uma Melhor Busca Vetorial por Ben Trent

A partir da versão 7.11, o Elasticsearch define automaticamente, por padrão, o tamanho do heap da JVM com base nas funções e na memória total de um nó. Para a maioria dos ambientes de produção, recomenda-se o uso do dimensionamento padrão. No entanto, se você quiser definir manualmente o tamanho do heap da JVM, como regra geral, você deve definir -Xms e -Xmx com o MESMO valor, que deve ser 50% da sua RAM total disponível, sujeito a um máximo de (aproximadamente) 31 GB.

Um tamanho de heap maior dará ao seu nó mais memória para operações de indexação e pesquisa. No entanto, seu nó também requer memória para cache, portanto, usar 50% mantém um equilíbrio saudável entre os dois. Pelo mesmo motivo, em produção, você deve evitar usar outros processos que consomem muita memória no mesmo nó que o Elasticsearch.

Normalmente, a utilização da memória heap seguirá um padrão em dente de serra, oscilando entre cerca de 30 e 70% da capacidade máxima da heap. Isso ocorre porque a JVM aumenta gradualmente a porcentagem de uso do heap até que o processo de coleta de lixo libere memória novamente. O uso elevado da memória heap ocorre quando o processo de coleta de lixo não consegue acompanhar. Um indicador de alto uso da memória heap é quando a coleta de lixo é incapaz de reduzir o uso da memória heap para cerca de 30%.

Na imagem acima, você pode ver um padrão típico de dente de serra no heap da JVM.

Você também verá que existem dois tipos de coleta de lixo: coleta de lixo jovem e coleta de lixo antiga.

Em uma JVM saudável, a coleta de lixo deve idealmente atender às seguintes condições:

• O GC jovem é processado rapidamente (em 50 ms).

• O coletor de lixo jovem não é executado com frequência (cerca de 10 segundos).

• O GC antigo é processado rapidamente (em menos de 1 segundo).

• A coleta de lixo antiga não é executada com frequência (uma vez a cada 10 minutos ou mais).

Como resolver problemas quando o uso da memória heap está muito alto ou quando o desempenho da JVM não está ideal

Existem diversos motivos pelos quais o uso da memória heap pode aumentar:

Sobrefragmentação

Consulte o documento sobre sobreparticionamento aqui.

Tamanhos de agregação grandes

Para evitar tamanhos de agregação muito grandes, mantenha o número de buckets de agregação (tamanho) em suas consultas no mínimo.

Você pode usar o registro de consultas lentas (logs lentos) e implementá-lo em um índice específico usando o seguinte.

Consultas que demoram muito para retornar resultados provavelmente são as que consomem mais recursos.

Tamanho excessivo do índice de volume

Se você estiver enviando solicitações grandes, isso pode ser a causa de um alto consumo de memória heap. Tente reduzir o tamanho das solicitações de indexação em lote.

Problemas de mapeamento

Em particular, se você usar “fielddata: true”, isso pode consumir grande parte da memória heap da sua JVM.

Tamanho do heap configurado incorretamente

O tamanho do heap pode ser definido manualmente por:

Definindo a variável de ambiente:

Edite o arquivo jvm.options no diretório de configuração do Elasticsearch:

A configuração da variável de ambiente tem prioridade sobre a configuração do arquivo.

É necessário reiniciar o nó para que a configuração seja considerada.

A nova proporção da JVM foi configurada incorretamente.

Geralmente NÃO é necessário configurar isso, pois o Elasticsearch define esse valor por padrão. Este parâmetro define a proporção de espaço disponível para objetos de “nova geração” e de “geração antiga” na JVM.

Se você perceber que as coletas de lixo antigas estão se tornando muito frequentes, pode tentar definir esse valor especificamente no arquivo jvm.options no diretório de configuração do Elasticsearch.

Quais são as melhores práticas para gerenciar o uso do tamanho do heap e a coleta de lixo da JVM em um cluster Elasticsearch de grande porte?

As melhores práticas para gerenciar o uso do tamanho do heap e a coleta de lixo da JVM em um cluster Elasticsearch de grande porte consistem em garantir que o tamanho do heap seja definido para, no máximo, 50% da RAM disponível e que as configurações de coleta de lixo da JVM sejam otimizadas para o caso de uso específico. É importante monitorar o tamanho do heap e as métricas de coleta de lixo para garantir que o cluster esteja funcionando de forma otimizada. Especificamente, é importante monitorar o tamanho do heap da JVM, o tempo de coleta de lixo e as pausas na coleta de lixo. Além disso, é importante monitorar o número de ciclos de coleta de lixo e o tempo gasto nessa atividade. Ao monitorar essas métricas, é possível identificar quaisquer problemas potenciais com o tamanho do heap ou com as configurações de coleta de lixo e tomar medidas corretivas, se necessário.

A API _split costuma ser um método mais rápido do que a API _reindex. A indexação deve ser interrompida antes de ambas as operações; caso contrário, as contagens de documentos em source_index e target_index serão diferentes.

Método 1 – usando a API dividida

A API de divisão é usada para criar um novo índice com o número desejado de shards primários, copiando as configurações e mapeando um índice existente. O número desejado de fragmentos primários pode ser definido durante a criação. As seguintes configurações devem ser verificadas antes de implementar a API dividida:

1. O índice de origem deve ser somente leitura. Isso significa que o processo de indexação precisa ser interrompido.

2. O número de shards primários no índice de destino deve ser um múltiplo do número de shards primários no índice de origem. Por exemplo, se o índice de origem tiver 5 shards primários, o número de shards primários do índice de destino pode ser definido como 10, 15, 20 e assim por diante.

Observação: Se apenas o número do fragmento primário precisar ser alterado, a API de divisão é preferível, pois é muito mais rápida do que a API de reindexação.

Implementando a API dividida

Criar um índice de teste:

O índice de origem deve ser somente leitura para poder ser dividido:

As configurações e os mapeamentos serão copiados automaticamente do índice de origem:

Você pode verificar o progresso com:

Como as configurações e os mapeamentos são copiados dos índices de origem, o índice de destino é somente leitura. Vamos habilitar a operação de escrita para o índice de destino:

Verifique a contagem de documentos (docs.count) nos índices de origem e destino antes de excluir o índice original:

O nome do índice e o nome do alias não podem ser iguais. Você precisa excluir o índice de origem e adicionar o nome do índice de origem como um alias para o índice de destino:

Após adicionar o alias test_split_source ao índice test_split_target , você deve testá-lo com:

Método 2 – usando a API de reindexação

Ao criar um novo índice com a API Reindex, é possível definir qualquer número de shards primários. Após a criação de um novo índice com o número desejado de shards primários, todos os dados do índice de origem podem ser reindexados para esse novo índice.

Além dos recursos de API dividida, os dados podem ser manipulados usando o ingest_pipeline no AP de reindexação. Com o pipeline de ingestão, somente os campos especificados que correspondem ao filtro serão indexados no índice de destino usando a consulta. O conteúdo dos dados pode ser alterado usando um script simples, e vários índices podem ser mesclados em um único índice.

Implementando a API de reindexação

Criar um reindexador de teste:

Copie as configurações e os mapeamentos do índice de origem:

Crie um índice de destino com configurações, mapeamentos e a quantidade desejada de fragmentos (shards):

*Nota: definir number_of_replicas: 0 e refresh_interval: -1 aumentará a velocidade de reindexação.

Inicie o processo de reindexação. Definir requests_per_second=-1 e slices=auto ajustará a velocidade de reindexação.

Você verá o task_id ao executar a API de reindexação. Copie isso e verifique com a API _tasks:

Atualize as configurações após a conclusão da reindexação:

Antes de excluir o índice original, verifique o número de documentos (docs.count) nos índices de origem e destino; eles devem ser iguais.

O nome do índice e o nome do alias não podem ser iguais. Exclua o índice de origem e adicione o nome do índice de origem como um alias para o índice de destino:

Após adicionar o alias test_split_source ao índice test_split_target, teste-o usando:

Resumo

Se você deseja aumentar o número de shards primários de um índice existente, precisa recriar as configurações e os mapeamentos para um novo índice. Existem dois métodos principais para fazer isso: a API de reindexação e a API de divisão. A indexação ativa deve ser interrompida antes de usar qualquer um dos métodos.

As desvantagens dessa abordagem são que ela requer alguma duplicação de hardware e pode criar dificuldades ao tentar transferir e sincronizar todos os dados sem problemas.

Também pode ser necessário realizar um procedimento semelhante se você precisar migrar aplicativos de um data center para outro.

Neste artigo, discutiremos e detalharemos três maneiras de transferir dados entre clusters do Elasticsearch.

Como migrar dados entre clusters do Elasticsearch?

Há 3 maneiras de transferir dados entre clusters do Elasticsearch:

1. Reindexação de um cluster remoto

2. Transferindo dados usando snapshots

3. Transferindo dados usando Logstash

Usar snapshots geralmente é a maneira mais rápida e confiável de transferir dados. No entanto, tenha em mente que você só pode restaurar um snapshot em um cluster de uma versão igual ou superior e nunca com uma diferença de mais de uma versão principal. Isso significa que você pode restaurar um snapshot 6.x em um cluster 7.x, mas não em um cluster 8.x.

Se precisar aumentar em mais de uma versão principal, você precisará reindexar ou usar o Logstash.

Agora, vamos analisar detalhadamente cada uma das três opções para transferir dados entre clusters do Elasticsearch.

1. Reindexando dados de um cluster remoto

Antes de começar a reindexar, lembre-se de que você precisará configurar mapeamentos apropriados para todos os índices no novo cluster. Para fazer isso, você deve criar os índices diretamente com os mapeamentos apropriados ou usar modelos de índice.

Reindexação remota — configuração necessária

Para reindexar remotamente, você deve adicionar a configuração abaixo ao arquivo elasticsesearch.yml do cluster que está recebendo os dados, que, em sistemas Linux, geralmente está localizado aqui: /etc/elasticsearch/elasticsearch.yml. A configuração a ser adicionada é a seguinte:

Se estiver usando SSL, você deve adicionar o certificado CA a cada nó e incluir o seguinte no comando para cada nó em elasticsearch.yml:

Como alternativa, você pode adicionar a linha abaixo a todos os nós do Elasticsearch para desabilitar a verificação SSL. Entretanto, essa abordagem é menos recomendada, pois não é tão segura quanto a opção anterior:

Você precisará fazer essas modificações em cada nó e executar uma reinicialização contínua. Para mais informações sobre como fazer isso, consulte nosso guia.

Comando de reindexação

Depois de definir o host remoto no arquivo elasticsearch.yml e adicionar os certificados SSL, se necessário, você pode começar a reindexar os dados com o comando abaixo:

Ao fazer isso, você pode enfrentar erros de tempo limite, então pode ser útil estabelecer valores generosos para tempos limite em vez de depender de padrões.

Agora, vamos dar uma olhada em alguns outros erros comuns que você pode encontrar ao reindexar remotamente.

Erros comuns ao reindexar remotamente

1. Reindexação não permitida

Se você encontrar esse erro, isso indica que você não definiu o endereço IP do host remoto ou o DNS do nome do nó no Elasticsearch conforme descrito acima ou esqueceu de reiniciar os serviços do Elasticsearch.

Para corrigir isso no cluster do Elasticsearch, você precisa adicionar o host remoto a todos os nós do Elasticsearch e reiniciar os serviços do Elasticsearch.

2. Exceção de handshake SSL

Este erro significa que você esqueceu de adicionar reindex.ssl.certificate_authorities ao elasticsearch.yml, conforme descrito acima. Para adicioná-lo:

2. Transferindo dados usando snapshots

Lembre-se, como mencionado acima, você só pode restaurar um snapshot em um cluster de uma versão igual ou superior e nunca com uma diferença de mais de uma versão principal

Se precisar aumentar em mais de uma versão principal, você precisará reindexar ou usar o Logstash.

As seguintes etapas são necessárias para transferir dados por meio de snapshots:

Etapa 1. Adicionando o plugin do repositório ao primeiro cluster do Elasticsearch – Para transferir dados entre clusters por meio de snapshots, você precisa garantir que o repositório seja acessível tanto pelo cluster novo quanto pelo antigo. Repositórios de armazenamento em nuvem como AWS, Google e Azure geralmente são ideais para isso. Para tirar instantâneos, consulte nosso guia e siga os passos descritos.

Etapa 2. Reinicie o serviço Elasticsearch (reinicialização contínua).

Etapa 3. Crie um repositório para o primeiro cluster do Elasticsearch.

Etapa 4 - Adicione o plugin do repositório ao segundo cluster do Elasticsearch.

Etapa 5 - Adicionar repositório como somente leitura ao segundo cluster do Elasticsearch – Você precisará adicionar um repositório repetindo as mesmas etapas executadas para criar o primeiro cluster do Elasticsearch.

Observação importante: ao conectar o segundo cluster do Elasticsearch ao mesmo repositório do AWS S3, você deve definir o repositório como um repositório somente leitura:

Isso é importante porque você quer evitar o risco de misturar versões do Elasticsearch dentro do mesmo repositório de snapshots.

Etapa 6 - Restaurando dados para o segundo cluster do Elasticsearch – Após seguir as etapas acima, você pode restaurar os dados e transferi-los para o novo cluster. Siga as etapas descritas neste artigo para restaurar dados no novo cluster. 

3. Transferindo dados usando Logstash

Antes de começar a transferir os dados com o logstash, lembre-se de que você precisará configurar mapeamentos apropriados para todos os índices no novo cluster. Para fazer isso, você precisará criar os índices diretamente ou usar modelos de índice.

Para transferir dados entre dois clusters do Elasticsearch, você pode configurar um servidor Logstash temporário e usá-lo para transferir seus dados entre dois clusters. Para clusters pequenos, uma instância de 2 GB de RAM deve ser suficiente. Para clusters maiores, você pode usar CPUs de quatro núcleos com 8 GB de RAM.

Para obter orientações sobre como instalar o Logstash, clique aqui.

Configuração do Logstash para transferência de dados de um cluster para outro

Uma configuração básica para copiar um único índice do cluster A para o cluster B é:

Para um Elasticsearch seguro, você pode usar a configuração abaixo:

Metadados de índice

Os comandos acima gravarão em um único índice nomeado. Se você quiser transferir vários índices e preservar os nomes dos índices, será necessário adicionar a seguinte linha à saída do Logstash:

Além disso, se você quiser preservar a identificação original do documento, será necessário adicionar:

Tenha em mente que definir o ID do documento tornará a transferência de dados significativamente mais lenta, portanto, preserve o ID original somente se necessário.

Sincronização de atualizações

Todos os métodos descritos acima levarão um período de tempo relativamente longo, e você poderá descobrir que os dados no cluster original foram atualizados enquanto aguardava a conclusão do processo.

Existem várias estratégias para permitir a sincronização de quaisquer atualizações que possam ter ocorrido durante o processo de transferência de dados, e você deve pensar sobre essas questões antes de iniciar o processo. Em particular, você precisa pensar sobre:

• Qual método você usa para identificar quaisquer dados que foram atualizados/adicionados desde o início do processo de transferência de dados (por exemplo, um campo “last_update_time” nos dados)?

• Que método você pode usar para transferir o último pedaço de dados?

• Existe risco de registros serem duplicados? Geralmente, existe, a menos que o método que você está usando defina o ID do documento durante a reindexação para um valor conhecido).

Os diferentes métodos para habilitar a sincronização de atualizações são descritos abaixo.

1. Utilização de sistemas de filas

Alguns sistemas de ingestão/atualização usam filas que permitem que você “reproduza” modificações de dados recebidas nos últimos x dias. Isso pode fornecer um meio de sincronizar quaisquer alterações realizadas.

2. Reindexar remotamente

Repita o processo de reindexação para todos os itens em que “last_update_time” > x dias atrás. Você pode fazer isso adicionando um parâmetro “consulta” à solicitação de reindexação.

3. Logstash

Na entrada do Logstash, você pode adicionar uma consulta para filtrar todos os itens em que “last_update_time” > x dias atrás. No entanto, esse processo causará duplicatas em dados não temporais, a menos que você tenha definido o document_id.

4. Instantâneos

Não é possível restaurar apenas parte de um índice, então você teria que usar um dos outros métodos de transferência de dados descritos acima (ou um script) para atualizar quaisquer alterações que tenham ocorrido desde que o processo de transferência de dados foi realizado.

No entanto, a restauração de snapshots é um processo muito mais rápido do que a reindexação/Logstash, então pode ser possível suspender as atualizações por um breve período de tempo enquanto os snapshots são transferidos para evitar o problema completamente.

Este blog explora como grandes modelos de linguagem (LLMs) podem ser usados para identificar e gerar sinônimos automaticamente, permitindo que esses termos sejam carregados programaticamente na API de sinônimos do Elasticsearch.

Quando usar sinônimos?

O uso de sinônimos pode ser uma solução mais rápida e econômica em comparação com a busca vetorial. Sua implementação é mais simples, pois não requer conhecimento profundo de embeddings ou um processo complexo de ingestão de vetores.

Além disso, o consumo de recursos é menor, uma vez que a busca vetorial exige maior capacidade de armazenamento e memória para indexação e recuperação de dados.

Outro aspecto importante é a regionalização da busca. Com sinônimos, é possível adaptar os termos de acordo com o idioma e os costumes locais. Isso é útil em situações em que os embeddings podem não corresponder a expressões regionais ou termos específicos de cada país. Por exemplo, algumas palavras ou siglas podem ter significados diferentes dependendo da região, mas são naturalmente tratadas como sinônimos pelos usuários locais. No Brasil, isso é bastante comum. "Abacaxi" e "ananás" são a mesma fruta (abacaxi), mas o segundo termo é mais comumente usado em algumas regiões do Nordeste. Da mesma forma, o conhecido "pão francês" no Sudeste pode ser conhecido como "pão careca" no Nordeste.

Como usar LLMs para gerar sinônimos?

Para obter sinônimos automaticamente, podemos usar Modelos de Aprendizagem Baseados em Lógica (LLMs), que analisam o contexto de um termo e sugerem variações apropriadas. Essa abordagem permite a expansão dinâmica de sinônimos, garantindo uma busca mais ampla e precisa sem depender de um dicionário fixo.

Nesta demonstração, usaremos um modelo de linguagem natural (LLM) para gerar sinônimos para produtos de comércio eletrônico. Muitas pesquisas retornam poucos ou nenhum resultado devido a variações nos termos pesquisados. Com sinônimos, podemos resolver esse problema. Por exemplo, uma busca por "smartphone" pode abranger diferentes modelos de celulares, garantindo que os usuários encontrem os produtos que procuram.

Pré-requisitos

Antes de começarmos, precisamos configurar o ambiente e definir as dependências necessárias. Utilizaremos a solução fornecida pela Elastic para executar o Elasticsearch e o Kibana localmente em um contêiner Docker. O código será escrito em Python, versão 3.9.6, com as seguintes dependências:

Criando o índice de produtos

Inicialmente, criaremos um índice de produtos sem suporte a sinônimos. Isso nos permitirá validar as consultas e compará-las com um índice que inclui sinônimos.

Para criar o índice, carregamos em massa um conjunto de dados de produtos usando o seguinte comando no Kibana DevTools:

Gerando sinônimos com LLM

Nesta etapa, utilizaremos um modelo de lógica latente (LLM) para gerar sinônimos dinamicamente. Para atingir esse objetivo, integraremos a API da OpenAI, definindo um modelo e um prompt adequados. O LLM receberá a categoria e o nome do produto, garantindo que os sinônimos sejam contextualmente relevantes.

A partir do índice de produtos criado, recuperaremos todos os itens da categoria "Eletrônicos" e enviaremos seus nomes para o LLM. O resultado esperado será algo como:

Com os sinônimos gerados, podemos registrá-los no Elasticsearch usando a API de Sinônimos.

Gerenciando sinônimos com a API de Sinônimos

A API de Sinônimos oferece uma maneira eficiente de gerenciar conjuntos de sinônimos diretamente dentro do sistema. Cada conjunto de sinônimos consiste em regras de sinonímia, onde um grupo de palavras é tratado como equivalente nas buscas.

Exemplo de criação de um conjunto de sinônimos

Isso cria um conjunto chamado "meu-conjunto-de-sinônimos", onde "olá" e "oi" são tratados como equivalentes, assim como "tchau" e "adeus".

Implementação da criação de sinônimos para o catálogo de produtos.

A seguir, está o método responsável por construir um conjunto de sinônimos e inseri-lo no Elasticsearch. As regras de sinônimos são geradas com base no mapeamento de sinônimos sugerido pelo LLM. Cada regra possui um ID, correspondente ao nome do produto no formato slug, e a lista de sinônimos calculada pelo LLM.

A seguir, está a carga útil da solicitação para criar o conjunto de sinônimos:

Com o conjunto de sinônimos criado no cluster, podemos prosseguir para a próxima etapa, que é a criação de um novo índice com suporte a sinônimos usando o conjunto definido.

O código Python completo, com os sinônimos gerados pelo LLM e a criação do conjunto de sinônimos definida pela API de Sinônimos, encontra-se abaixo:

Criando um índice com suporte a sinônimos

Um novo índice será criado onde todos os dados do índice products serão reindexados. Este índice usará o synonyms_filter, que aplica o products-synonyms-set criado anteriormente.

A seguir, o mapeamento de índice configurado para usar sinônimos:

Reindexando o índice products

Agora, usaremos a API Reindex para migrar os dados do índice products para o novo índice products_02 , que inclui suporte a sinônimos. O seguinte código foi executado no Kibana DevTools:

Após a migração, o índice products_02 será preenchido e estará pronto para validar pesquisas usando o conjunto de sinônimos configurado.

Validação da pesquisa com sinônimos

Vamos comparar os resultados da pesquisa entre os dois índices. Executaremos a mesma consulta em ambos os índices e validaremos se os sinônimos estão sendo usados para recuperar os resultados.

Pesquisar no índice products (sem sinônimos)

Usaremos o Kibana para realizar buscas e analisar os resultados. No menu Analytics > Discovery, criaremos uma visualização de dados para visualizar os dados dos índices que criamos.

Dentro do Discovery, clique em Visualização de Dados e defina um nome e um padrão de índice. Para o índice "produtos", usaremos o padrão "produtos ". Em seguida, repetiremos o processo para criar uma nova visualização de dados para o índice "products_02", usando o padrão "products_02" .

Com as visualizações de dados configuradas, podemos retornar a Analytics > Discovery e iniciar as validações.

Aqui, após selecionar os produtos DataView e pesquisar pelo termo "tablet", não obtemos resultados, embora saibamos que existem produtos como "Kindle Paperwhite" e "Apple iPad Air".

Pesquisar no índice products_02 (suporta sinônimos)

Ao executar a mesma consulta na visualização de dados "products_synonyms", que suporta sinônimos, os produtos foram recuperados com sucesso. Isso demonstra que o conjunto de sinônimos configurado está funcionando corretamente, garantindo que diferentes variações dos termos pesquisados retornem os resultados esperados.

Podemos obter o mesmo resultado executando a mesma consulta diretamente no Kibana DevTools. Basta pesquisar o índice products_02 usando a API de pesquisa do Elasticsearch:

Conclusão

A implementação de sinônimos no Elasticsearch melhorou a precisão e a abrangência das buscas no catálogo de produtos. O principal diferencial foi o uso de um LLM ( Language-Level Model), que gerou sinônimos automaticamente e contextualmente, eliminando a necessidade de listas predefinidas. O modelo analisou nomes e categorias de produtos, garantindo sinônimos relevantes para o comércio eletrônico.

Além disso, a API de Sinônimos simplificou o gerenciamento de dicionários, permitindo que os conjuntos de sinônimos fossem modificados dinamicamente. Com essa abordagem, a busca tornou-se mais flexível e adaptável a diferentes padrões de consulta do usuário.

Esse processo pode ser continuamente aprimorado com novos dados e ajustes de modelo, garantindo uma experiência de pesquisa cada vez mais eficiente.

Referências

Executar o Elasticsearch localmente

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

API de sinônimos

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

Hoje, anunciamos a disponibilidade geral do novo modo de índice do Elasticsearch, logsdb, que reduz o espaço de armazenamento de dados de log em até 65% em comparação com versões recentes do Elasticsearch sem logsdb. Essa melhoria drástica permite que as equipes de observabilidade e segurança expandam a visibilidade sem exceder seu orçamento, mantendo todos os dados imediatamente acessíveis para análise.

O logsdb otimiza a ordenação dos dados, elimina a duplicação ao reconstruir valores de campos não armazenados em tempo real com synthetic _source e melhora a compressão com algoritmos e codecs avançados, aproveitando o armazenamento em colunas no Elasticsearch para armazenamento e recuperação eficientes de logs.

Melhore a análise e reduza custos melhorando a eficiência de armazenamento com o modo de índice logsdb

Os logs fornecem sinais essenciais para detectar e corrigir problemas de observabilidade e segurança, e a utilidade está aumentando à medida que os avanços da IA facilitam a análise de dados baseados em texto, portanto, o armazenamento eficiente e o acesso de alto desempenho são mais importantes do que nunca.

Infelizmente, o crescente volume de logs gerados pela infraestrutura e pelos aplicativos está aumentando os custos, o que dificultam a análise: limitar a coleta, reduzir a retenção ou relegar dados novos a camadas de arquivamento isoladas.

O Logsdb enfrenta diretamente esses desafios. Com mais eficiência de armazenamento, você pode coletar mais dados e evitar o incômodo de uma filtragem complicada de dados. É possível reter logs por mais tempo para dar suporte à busca de ameaças, resposta a incidentes e requisitos de conformidade. E como todos os dados são sempre pesquisáveis, você pode ter insights rápidos, não importa o tamanho do seu conjunto de dados.

Inovação técnica por trás do modo de índice logsdb

O modo de índice logsdb reduz muito a pegada de disco dos dados de log com classificação inteligente de índices, synthetic _source e compressão avançada. Implementar isso pode reduzir as necessidades de armazenamento de log em até 65%, em comparação às versões recentes do Elasticsearch sem logsdb. Embora o logsdb atualmente consuma mais CPU durante a indexação, o armazenamento eficiente reduz os custos gerais para a maioria dos clientes. Para clientes que precisam de retenção a longo prazo, esperamos reduções no custo total de propriedade (TCO) de até 50%.

A classificação de índice inteligente melhora a eficiência do armazenamento em até 30% e reduz a latência da consulta em alguns conjuntos de dados de registro ao localizar dados semelhantes próximos uns dos outros. Por padrão, ele classifica os índices por host.name e @timestamp. Se seus dados tiverem campos mais adequados, você poderá especificá-los.

A compactação avançada reduz significativamente os requisitos de armazenamento para dados com muito texto, como logs, por meio da compactação Zstandard (Zstd), codificação delta, codificação de comprimento de execução e outros codecs inteligentes que são escolhidos automaticamente. Os valores doc, que são armazenados em um formato de coluna otimizado para compactação e desempenho, permitem o armazenamento e a recuperação eficientes de valores de campo para classificação, agregação e script.

O _source sintético permite que as organizações reduzam as necessidades de armazenamento em outros 20-40% descartando o campo _source e reconstruindo-o total ou parcialmente sob demanda. Embora o recurso às vezes exija mais computação para indexação e recuperação, os testes mostram que ele oferece melhorias mensuráveis na eficiência líquida. O Synthetic _source foi criado com base em quase dois anos de uso em produção com métricas, com inúmeras melhorias para logs, incluindo suporte para quase todos os tipos de campos.

As economias de armazenamento resultantes são propagadas pelas fases do ciclo de vida do índice. Uma redução de armazenamento de 65% na camada quente resultará na mesma redução nas camadas quente, fria e congelada, além de diminuir o espaço necessário para armazenar snapshots no armazenamento de buckets.

Sem comprometer a visibilidade: mantenha todos os logs para observabilidade e segurança

Logs são a fundação da visibilidade em infraestrutura e aplicações, fornecendo o sinal mais simples e essencial para monitoramento e solução de problemas. No entanto, os custos estão aumentando à medida que os volumes de dados de logging crescem. Este desafio está obrigando os clientes a implementar políticas complexas de filtragem e gerenciamento, excluir dados prematuramente e deixar logs relevantes em armazenamentos que exigem um dia ou mais para reidratar antes da análise. Sem um conjunto de dados completo, facilmente pesquisável e acessível, encontrar e resolver problemas é muito mais desafiador.

O modo de índice do Logsdb se baseia em recursos inovadores do Elasticsearch, como snapshots pesquisáveis e importação automática, para abordar esses pontos problemáticos para equipes de operações e segurança:

Reduza custos: o Logsdb reduz o espaço de armazenamento de logs em até 65%, permitindo que as organizações reduzam as despesas de armazenamento e, ao mesmo tempo, retenham mais dados. Isso se traduz em economia de custos em todos os níveis de armazenamento — do ativo ao congelado — e maior produtividade para as equipes de observabilidade e segurança que usam esses dados.

Preserve dados valiosos: o Logsdb mantém todos os seus dados de log e melhora a eficiência operacional sem depender de ferramentas extras ou filtros complicados. Com recursos como _source sintético, preserve o valor dos dados sem armazenar todo o documento de origem.

Expanda a visibilidade: o Logsdb fornece acesso eficiente a todos os dados em uma plataforma, sem silos separados para observabilidade, segurança e dados históricos. Para engenheiros de confiabilidade de site (SREs), ele acelera a resolução de problemas ao permitir a análise de logs juntamente com métricas, rastreamentos e dados comerciais. Da mesma forma, para equipes do centro de operações de segurança (SOC), ele acelera a investigação e a correção ao eliminar pontos cegos.

Simplifique o acesso aos dados: o Logsdb permite que as equipes de SRE retenham dados acionáveis de forma eficiente para solução de problemas, tendências e análises. Da mesma forma, as equipes do SOC podem pesquisar rapidamente todos os seus dados para investigação e detecção de ameaças sem incorrer em custos exorbitantes.

O Logsdb está pronto para seu ambiente

O modo de índice logsdb do Elasticsearch está geralmente disponível para clientes do Elastic Cloud Hosted e Self-Managed a partir da versão 8.17 e é habilitado por padrão para logs no Elastic Cloud Serverless.

As capacidades básicas do logsdb (incluindo a classificação inteligente de índices e a compressão avançada) estão disponíveis para organizações com licenças Padrão, Ouro e Platina. As capacidades completas do logsdb que reduzem ainda mais os requisitos de armazenamento (incluindo synthetic _source) estão disponíveis para clientes serverless e organizações com uma licença Empresarial.

Elasticsearch logsdb em ação

O logsdb permite que você mantenha todos os seus dados de log e melhore a eficiência operacional sem restringir a coleta, descartar ou isolar os dados. Com recursos como classificação inteligente de índices, compactação avançada e synthetic _source, mantenha e analise os dados que você precisa dentro de um orçamento que funcione para você.

Quer experimentar por si mesmo? Experimente o Elastic sem custos.

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.

Muitos sites de comércio eletrônico estão interessados em aprimorar a experiência de busca de receitas. A busca semântica, quando aplicada corretamente, permite que os clientes encontrem rapidamente os ingredientes necessários com base em consultas mais naturais, como "algo para o Dia dos Namorados" ou "refeições de Ação de Graças".

Neste artigo, demonstraremos como usar o Elasticsearch para implementar uma busca semântica que suporte esse tipo de consulta. Vamos configurar um índice para armazenar o catálogo de ingredientes e produtos de um supermercado e demonstrar como esse índice pode ser usado para melhorar as buscas por receitas. Ao longo do artigo, explicaremos como criar essa estrutura de dados e aplicar técnicas de processamento de linguagem natural para fornecer resultados relevantes e alinhados à intenção do cliente.

Todo o código apresentado neste artigo foi desenvolvido em Python e está disponível no GitHub. Você pode acessar o repositório para revisar o código-fonte, fazer ajustes conforme necessário e implementar as soluções diretamente em seu ambiente de desenvolvimento.

Iniciando a implementação da busca semântica

Para começar a implementar a busca semântica, primeiro precisamos definir o modelo de linguagem natural. A Elastic oferece seu próprio modelo, o ELSER, mas também oferece suporte para a integração de modelos de PNL de diversos fornecedores, como o Hugging Face. Essa flexibilidade permite que você escolha a opção que melhor se adapta às suas necessidades.

Neste artigo, utilizaremos o ELSER, que reduz a complexidade de implantação e gerenciamento de modelos de PNL (Processamento de Linguagem Natural). Além disso, o Elastic oferece o recurso semantic_text , que simplifica bastante o processo. Com o semantic_text, todo o processo de geração de embeddings torna-se simples e automatizado. Basta definir um ponto de inferência e especificar o campo que receberá os embeddings no seu mapeamento de índice. Durante a indexação de documentos, os elementos incorporados serão gerados e associados automaticamente ao campo especificado.

Etapas de configuração

A seguir estão os passos para criar um índice com suporte para pesquisa semântica. Seguindo estas instruções, você terá um índice configurado e pronto para buscas semânticas:

1. Crie o ponto de inferência.

2. Crie o índice, definindo o campo de descrição como semantic_text para que ele possa receber os embeddings.

3. Indexe os dados no índice do catálogo de produtos, que armazenará um catálogo de produtos. Este catálogo foi obtido a partir de um conjunto de dados disponível aqui.

Aplicação da busca semântica em supermercados

Agora que temos o índice preenchido com dados de produtos de supermercado, estamos testando e validando consultas para melhorar os resultados da pesquisa usando a busca semântica. Nosso objetivo é proporcionar uma experiência de busca mais inteligente, que compreenda o contexto e a intenção do usuário, oferecendo resultados mais relevantes e precisos.

Desafios resolvidos pela busca semântica

Com base no catálogo de produtos, vamos explorar como a busca semântica pode transformar a experiência de busca em supermercados, abordando problemas de vocabulário e contexto que a busca lexical tradicional costuma ter dificuldades em resolver.

1. Interpretação das intenções culinárias

Problema 01: Um cliente pode pesquisar por "frutos do mar para grelhar", mas um sistema de busca lexical pode não entender completamente a intenção por trás da consulta. Pode ser que o sistema não consiga identificar todos os frutos do mar adequados para grelhar, retornando apenas aqueles que contenham exatamente os termos "frutos do mar" ou "grelhar" no título do produto.

Primeiramente, realizaremos uma busca lexical e analisaremos os resultados. Em seguida, faremos o mesmo com uma busca semântica, comparando os resultados para o mesmo termo de busca.

Consulta de pesquisa lexical

Resultados:

Tipo de pesquisa

Nome

Pontuação

Lexical

Caranguejo-das-neves Bairdi do Alasca, peixe do noroeste

10,453125

Lexical

Molho Gourmet Original do Sr. Yoshida

7,2289705

Lexical

Pacote Variado de Frutos do Mar Premium - 20 unidades

7.1924105

Lexical

Pargo-vermelho americano - Inteiro, com cabeça, limpo

6,998647

Lexical

Garras e patas de lagosta, capturadas de forma sustentável na natureza.

6,438654

A busca lexical retornou alguns frutos do mar adequados para grelhar, como o pargo-vermelho americano e o caranguejo-das-neves-do-Alasca Bairdi da Northwest Fish. No entanto, a busca lexical retornou produtos menos relevantes no topo da lista, como o molho Mr. Yoshida, que não é um produto à base de frutos do mar, mas sim um molho para carne, sugerindo que o algoritmo lexical teve dificuldades em compreender totalmente o contexto de "para grelhar".

Solução de busca semântica

Usamos uma consulta que combina o termo "frutos do mar" com contextos de preparo como "grelhar" para retornar uma lista abrangente de opções, como filés de peixe, camarão e vieiras, que são ideais para grelhar — mesmo que as palavras "grelhar" ou "frutos do mar" não apareçam diretamente no nome do produto. Isso garante que os resultados da pesquisa estejam mais alinhados com a intenção do cliente.

Pesquisa semântica de consulta:

Tipo de pesquisa

Nome

Pontuação

Semântica

Robalo inteiro, limpo e com cabeça.

16.175909

Semântica

Bacalhau-negro do Alasca (peixe-sable)

15,855331

Semântica

Pargo-vermelho americano - Inteiro, com cabeça

15,454779

Semântica

Caranguejo-das-neves Bairdi do Alasca, peixe do noroeste

15,855331

Semântica

Pargo-vermelho americano - Inteiro, com cabeça

15,3892355

A busca semântica não apenas retornou produtos diretamente relacionados ao termo "frutos do mar", mas também compreendeu o contexto de "grelhar", apresentando peixes inteiros e filés adequados para grelhar. O ponto crucial aqui é a precisão dos resultados, que incluíram opções de peixes inteiros, como o robalo e o bacalhau negro do Alasca, ambos comumente usados para grelhar.

Problema 02 : Muitos clientes procuram soluções rápidas e fáceis para o jantar depois de um longo dia de trabalho, usando termos como "refeições fáceis para a semana". A busca lexical tradicional pode não capturar completamente o conceito de refeições rápidas, muitas vezes focando apenas em produtos que incluem a palavra "fácil" em seu nome.

Assim como fizemos no problema anterior, começaremos realizando uma busca lexical. Em seguida, aplicaremos uma solução utilizando busca semântica.

Consulta de pesquisa lexical

Resultados:

Tipo de pesquisa

Nome

Pontuação

Lexical

Etiquetas adesivas Avery Easy Peel para endereços, pacote com 4200 unidades

8.017723

Lexical

Refeições portáteis/de emergência com aquecimento automático Omeals 32

6,592727

Lexical

Poke de Atum Albacora em Cubos da Coastal Seafood

5,836883

Lexical

Espuma Hefty Super Weight de 340 g (12 oz)

5,8116536

Lexical

Guardanapos Vanity Fair Everyday, 2 camadas, pacote com 110 unidades

5,752989

A busca lexical retornou resultados muito menos relevantes, incluindo itens completamente não relacionados a refeições, como Etiquetas de Endereço Avery Easy Peel e Guardanapos Vanity Fair Everyday. Esses produtos não atendem à necessidade do usuário por refeições rápidas. Embora a busca lexical tenha retornado um produto útil (Omeals Self Heating Emergency Meals), outros resultados, como guardanapos e etiquetas, só correspondiam às palavras "fácil" ou "noite de semana" em suas descrições, sem realmente abordar a intenção do usuário de encontrar uma solução rápida para refeições.

Solução de busca semântica

Implementamos uma consulta que entende a intenção por trás de refeições rápidas e fáceis. Associa produtos que podem ser preparados rapidamente, como carnes pré-cozidas, massas congeladas ou kits de refeição, mesmo que não incluam explicitamente a palavra "fácil" no nome. Essa abordagem garante que os clientes encontrem as opções mais adequadas para jantares rápidos durante a semana, atendendo à necessidade de praticidade.

Pesquisa semântica de consulta

Resultados:

Tipo de pesquisa

Nome

Pontuação

Semântica

Refeições portáteis/de emergência com aquecimento automático Omeals 32

14.610006

Semântica

Nissin, Cup Noodles, Camarão, 70g

13,751424

Semântica

Mistura para Waffles e Panquecas Namaste Sem Glúten

13,73376

Semântica

Batatas Idaho, Batatas Hashbrown Douradas Grelhadas

12,549422

Semântica

Nissin, Cup Noodles, Frango, 24 unidades

12.034527

A busca semântica retornou produtos claramente relacionados a refeições rápidas e práticas, como macarrão instantâneo (Cup Noodles), batatas pré-cozidas e misturas para panquecas, que são opções típicas para jantares fáceis durante a semana. Isso demonstra que a busca semântica consegue captar o conceito por trás da frase "refeições fáceis para noites de semana", identificando a intenção do usuário de encontrar refeições rápidas e práticas. Curiosamente, produtos de outras categorias, como "refrigerantes", também podem ser incluídos quando relevantes no contexto (por exemplo, bebidas para acompanhar as refeições).

2. Termos regionais e variações de vocabulário

Problema: Um cliente pode pesquisar por "refrigerante", enquanto outro cliente pode usar "refrigerante" para o mesmo produto. A busca lexical tradicional não reconhece que ambos os termos se referem ao mesmo item.

Consulta de pesquisa lexical

Resultados:

Tipo de pesquisa

Nome

Pontuação

Lexical

Prime Hydration+ Sticks - Mistura para Bebida Eletrolítica

14,492869

Lexical

Capri Sun, 100% Suco, Pacote Variado

12.340851

Lexical

Bebida energética Joyburst, Frosé Rosé, 12

11,839179

Lexical

Pop-Tarts da Kellogg's, com cobertura de açúcar mascavo e canela.

9,97788

Lexical

Kind Mini Bars, Pacote Variado, 0,7

9,336912

A busca lexical concentra-se em correspondências exatas de palavras. Embora tenha retornado produtos como Prime Hydration e Capri Sun, a correspondência direta com o termo "pop" também levou a resultados irrelevantes, como Pop-Tarts da Kellogg's, que é um lanche e não uma bebida. Isso demonstra como a busca lexical pode ser menos eficaz quando um termo possui múltiplos significados ou pode ser ambíguo.

Solução de busca semântica

Em consultas semânticas, podemos superar o problema das variações de vocabulário que a busca lexical não consegue resolver. Ao expandir os termos de pesquisa, conseguimos obter resultados baseados no significado contextual, fornecendo respostas mais relevantes e abrangentes.

Consulta:

Resultados:

Tipo de pesquisa

Nome

Pontuação

Semântica

Refrigerante Prebiótico Olipop 355ml (12 oz) - Variedade

14,776867

Semântica

Bai Antioxidante Cocofusion, Pacote Variado, 18

14,663253

Semântica

Bebida energética Monster, Zero Ultra, 24

14,486348

Semântica

Joyburst Energy Variedade, 355 ml

14.007214

Semântica

Bebida energética Joyburst, Frosé Rosé, 12

13,641038

A busca semântica retorna produtos que correspondem diretamente ao conceito de "refrigerante" como sinônimo de "soda" (como Olipop Prebiotics Soda), mesmo que o termo exato "refrigerante" não esteja presente no nome do produto. A busca compreendeu a intenção do usuário — uma bebida refrescante e com baixo teor de açúcar — e conseguiu retornar produtos relevantes, incluindo opções como refrigerantes prebióticos (Olipop) e bebidas energéticas sem açúcar (Monster Energy Drink).

Conclusão

A implementação da busca semântica no contexto de supermercados provou ser altamente eficaz na compreensão de consultas complexas como "frutos do mar para grelhar" e "refeições fáceis para a semana". Essa abordagem nos permitiu interpretar a intenção do usuário com mais precisão, retornando produtos altamente relevantes.

Ao utilizar o Elasticsearch e simplificar o processo com o ELSER, conseguimos aplicar a busca semântica de forma rápida e eficiente, melhorando significativamente os resultados da busca e proporcionando uma experiência de compra mais ágil e direcionada. Isso não apenas otimizou o processo de busca, mas também aumentou a relevância dos resultados oferecidos aos clientes.

Referências

Modelo ELSER:

https://www.elastic.co/guide/en/elasticsearch/reference/current/put-inference-api.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/infer-service-elser.html

Texto semântico:

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-text.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html

Conjunto de dados:

https://www.kaggle.com/datasets/bhavikjikadara/grocery-store-dataset?select=GroceryDataset.csv

Busca semântica:

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search-semantic-text.html