1. Utilizando a API_mappingpara recuperar informações de campo

2. Utilizando a API_searchpara exibir valores de campo

3. Filtrar campos usando o parâmetrofields

4. Exibindo campos aninhados

1. Utilizando a API _mapping para recuperar informações de campo

A API _mapping permite recuperar a definição de mapeamento para um índice ou vários índices. Isso inclui informações sobre os campos, seus tipos de dados e outras propriedades. Para recuperar o mapeamento de um índice específico, utilize a seguinte solicitação:

Por exemplo, se você tiver um índice chamado my_index, poderá recuperar seu mapeamento com a seguinte solicitação:

A resposta incluirá a definição de mapeamento para o índice, que contém informações sobre os campos e suas propriedades.

Também é possível recuperar o mapeamento de um campo específico. Isso pode ser útil se o seu mapeamento for muito extenso e você quiser se concentrar apenas em um campo específico. Para obter o mapeamento de um campo específico, utilize a seguinte solicitação:

Você também pode recuperar os mapeamentos de vários campos separando seus nomes com vírgulas, como na seguinte solicitação:

2. Usando a API _search para exibir valores de campo

Para exibir os valores dos campos em um índice do Elasticsearch, você pode usar a API _search . Por padrão, a API _search retorna o campo _source , que contém o documento JSON original que foi indexado. Para exibir apenas campos específicos, você pode usar o parâmetro _source na solicitação de pesquisa.

Aqui está um exemplo de uma solicitação de pesquisa que retorna os valores dos campos title e author para documentos no índice my_index :

Neste exemplo, o parâmetro _source especifica os campos a serem retornados.

3. Filtrar campos usando o parâmetro fields

Você também pode usar o parâmetro fields para filtrar os campos retornados na resposta da pesquisa. Isso pode ser útil se você precisar apenas de campos específicos e quiser reduzir o tamanho da resposta. O parâmetro fields aceita uma matriz de nomes de campos ou padrões curinga.

Por exemplo, para retornar apenas os campos title e author para documentos no índice my_index , você pode usar a seguinte solicitação de pesquisa:

Note que o parâmetro _source está definido como falso para não retornar o documento de origem.

Para retornar todos os campos com o tipo de dados text , você pode usar um padrão curinga como este:

4. Exibição de campos aninhados

Se o seu índice contiver campos aninhados, você pode usar a notação de ponto para especificar o caminho do campo aninhado no parâmetro fields . Por exemplo, se você tiver um campo aninhado chamado address.city, poderá incluí-lo na resposta da pesquisa desta forma:

Neste exemplo, a resposta da pesquisa incluirá os valores dos campos title, author e address.city .

Conclusão

Em conclusão, a exibição de campos em um índice do Elasticsearch pode ser realizada usando a API _mapping para recuperar informações do campo e a API _search para exibir os valores do campo. Você pode filtrar os campos retornados na resposta da pesquisa usando os parâmetros _source ou fields e exibir campos aninhados usando a notação de ponto. Essas técnicas podem ajudá-lo a entender a estrutura de seus dados, identificar campos específicos e solucionar problemas.

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.

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.

Neste artigo, discutiremos os motivos para excluir campos da indexação, como configurar o Elasticsearch para excluir campos específicos e algumas práticas recomendadas a serem seguidas ao fazer isso.

Motivos para excluir campos da indexação

1. Desempenho: Indexar todos os campos de um documento pode aumentar o tempo de indexação e tornar a pesquisa mais lenta. Ao excluir campos que não são necessários para pesquisa ou agregação, você pode melhorar o desempenho geral do seu cluster Elasticsearch.

2. Armazenamento: A indexação de campos consome espaço de armazenamento. Excluir campos que não são necessários para pesquisa ou agregação pode ajudar a reduzir os requisitos de armazenamento do seu cluster Elasticsearch.

3. Tamanho do índice: O tamanho de um índice do Elasticsearch está diretamente relacionado ao número de campos indexados. Ao excluir campos desnecessários, você pode minimizar o tamanho do seu índice, o que pode levar a um desempenho de pesquisa e indexação mais rápido.

Configurando o Elasticsearch para excluir campos

Para excluir um campo da indexação no Elasticsearch, você pode usar a propriedade "index" no mapeamento do campo. Ao definir a propriedade “index” como “false”, o Elasticsearch não indexará o campo, e ele não será pesquisável nem estará disponível para agregações.

Aqui está um exemplo de como excluir um campo da indexação usando o mapeamento do Elasticsearch:

Neste exemplo, estamos criando um novo índice chamado “my_index” com um único campo chamado “field_to_exclude”. Ao definir a propriedade “index” como “false”, estamos dizendo ao Elasticsearch para não indexar esse campo. O campo ainda estará disponível no documento original.

Melhores práticas para excluir campos da indexação

1. Analise seus dados: Antes de excluir campos da indexação, é essencial analisar seus dados e entender quais campos são necessários para pesquisa e agregação. Isso ajudará você a tomar decisões informadas sobre quais campos excluir.

2. Teste suas alterações: Ao excluir campos da indexação, é crucial testar as alterações para garantir que a funcionalidade de pesquisa e agregação continue funcionando conforme o esperado. Isso pode ajudar você a evitar problemas inesperados ou falhas de desempenho.

3. Monitore o desempenho: após excluir campos da indexação, monitore o desempenho do seu cluster Elasticsearch para garantir que as alterações tenham surtido o efeito desejado. Isso pode ajudar a identificar quaisquer otimizações adicionais que possam ser necessárias.

4. Utilize a filtragem por origem: Se você precisa armazenar um campo no Elasticsearch, mas não deseja que ele seja pesquisável ou disponível para agregações, considere usar a filtragem por origem. Isso permite armazenar o campo no campo _source, mas excluí-lo do índice.

Conclusão

Excluir campos da indexação no Elasticsearch pode ajudar a melhorar o desempenho, reduzir os custos de armazenamento e minimizar o tamanho geral do seu índice. Ao analisar cuidadosamente seus dados e entender quais campos são necessários para pesquisa e agregação, você pode tomar decisões informadas sobre quais campos excluir. Sempre teste suas alterações e monitore o desempenho do seu cluster Elasticsearch para garantir que suas otimizações tenham o efeito desejado.

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.

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.

• As definições de mapeamento especificam o esquema de dados.

• As configurações definem o tamanho dos fragmentos e as taxas de atualização. 

• Os aliases são usados para dar nomes alternativos ao índice.

Ao indexar um documento pela primeira vez ou criar um índice vazio usando a API Criar Índice, o índice será criado com as configurações padrão, sem esquema de dados e sem aliases. Essas configurações padrão funcionam muito bem em ambientes de desenvolvimento e teste, mas talvez seja necessário personalizar nossos índices para ambientes de produção.

Trabalhar com os mapeamentos e configurações padrão em produção pode resultar em indexação e desempenho de pesquisa deficientes. A criação manual de índices é um processo tedioso e demorado. Recriar esses índices em todos os ambientes é especialmente impraticável se tivermos um esquema de mapeamento complexo, além de configurações e aliases personalizados.

Felizmente, o Elasticsearch nos fornece uma ferramenta para aplicar automaticamente uma configuração predefinida ao criar índices na forma de modelos de índice .

Modelos de índice

Os modelos de índice permitem criar índices com configurações definidas pelo usuário. Um índice pode obter a configuração desses modelos, por exemplo, um número definido de shards e réplicas ou mapeamentos de campos, durante sua instanciação. Um modelo será definido com um padrão de nome e algumas configurações. Se o nome do índice corresponder ao padrão de nomenclatura do modelo, o novo índice será criado com a configuração definida no modelo.

O Elasticsearch atualizou sua funcionalidade de modelos na versão 7.8 com modelos compostos. Esta versão mais recente oferece muito mais modelos de índice reutilizáveis, como demonstrado neste artigo.

Tipos de modelo de índice

Os modelos de índice podem ser classificados em duas categorias:

• Modelos de índice (ou modelos de índice componíveis): Os modelos de índice componíveis podem existir por si só ou podem ser compostos por nenhum ou mais modelos componentes (consulte a segunda categoria).

• Modelos de componentes: O modelo de componente é um modelo reutilizável que define a configuração necessária. Normalmente, espera-se que o modelo de componente esteja associado a um modelo de índice. Cada um dos modelos de componentes pode ser associado a um ou mais modelos de índice. 

Como você pode ver na imagem abaixo, os modelos de índice A e B compartilham modelos de componentes (neste caso, apenas um – o Modelo 3) entre si. Um modelo de índice pode não conter nenhum ou vários modelos de componentes, e cada um dos modelos de componentes pode não estar associado a nenhum ou a vários modelos de índice. Ambos os tipos de modelos podem existir por si só, porém os modelos de componentes são inúteis a menos que estejam anexados a um modelo de índice.

A ideia geral é desenvolver um catálogo de modelos de componentes para uma organização usar em diversas necessidades (por exemplo, especificar os vários modelos de componentes para ambientes individuais) e associá-los a vários índices por meio de modelos de índice componíveis.

Como criar modelos (de índice) componíveis

O Elasticsearch fornece um endpoint _index_template para gerenciar modelos de índice. Neste modelo, o usuário fornece todos os mapeamentos, configurações e aliases necessários, juntamente com um padrão de nome de índice. Vamos analisar um exemplo de criação de um modelo para um aplicativo de microsserviços chamado customer-order-service , responsável pela lógica de geração de pedidos. 

Digamos que nossa necessidade seja criar um modelo para pedidos de clientes, representado por um padrão com caracteres curinga: *pedidos. Espera-se que este modelo tenha determinados mapeamentos e configurações, como o campo order_date, bem como números de shards e réplicas.

Qualquer índice que corresponda a este modelo durante a sua criação herdará as configurações definidas neste modelo. Por exemplo, um índice black_friday_orders terá o campo order_date, o número de shards será definido como 5 e o número de réplicas como 2. Além disso, todos os índices criados a partir deste modelo também herdarão um único nome de alias ! Vamos criar este modelo de pedidos (orders_template) com um padrão de índice definido como *orders e com um esquema de mapeamento que consiste em um único campo order_date com um formato de data predefinido dd-MM-yyyy. O código abaixo mostra como criar esse modelo de índice.

Ao executar essa consulta nas DevTools do Kibana, o modelo é criado com o padrão de índice *orders, juntamente com o mapeamento predefinido, as configurações e um alias. O `index_patterns` é uma matriz de padrões de correspondência; qualquer índice que corresponda a esse padrão derivará a configuração do modelo. Você pode executar o seguinte comando para recuperar o modelo persistido, que deverá reiterar o que fizemos:

Existe também uma prioridade, um número positivo, definida ao criar o atributo de modelo definido no modelo: cada modelo é definido com uma prioridade, de forma que quaisquer alterações conflitantes de modelos diferentes sejam resolvidas usando esse valor, com precedência dada ao valor de prioridade mais alto. A seguir, analisaremos a prioridade dos modelos com mais detalhes.

Criando um índice com o modelo

Agora que temos um modelo – um projeto para criar índices – o próximo passo é criar um índice. Quando o nome do índice corresponde ao padrão fornecido, as configurações do modelo são aplicadas automaticamente. Para comprovar esse ponto, como mostra o código abaixo, vamos criar um novo índice chamado: blackfriday_orders:

Como o nome do índice (blackfriday_orders) corresponde ao padrão de nomenclatura definido no modelo (ou seja, *pedidos), o índice deve obter toda a configuração derivada do modelo. Vamos recuperar esse índice recém-criado e verificar se isso é realmente verdade executando o seguinte código:

Isso deve retornar:

Conforme indicado na resposta, a configuração do blackfriday_orders foi herdada do modelo. Podemos tentar várias combinações de índices que herdarão com sucesso a configuração do modelo:

No entanto, os seguintes índices não herdarão a configuração, pois o nome não corresponderá ao padrão:

Um ponto importante a lembrar é que todos os índices derivados de um modelo têm o mesmo alias – all_orders – neste caso. Existe uma vantagem em ter um alias desse tipo: podemos simplesmente consultar esse único alias em vez de vários índices.

Embora criemos um modelo para *pedidos, espera-se que qualquer índice correspondente adote a configuração do modelo. Normalmente, consciente ou inconscientemente, as equipes podem criar alguns modelos adicionais por diversos motivos. Isso significa que, às vezes, o nome do índice pode corresponder a dois padrões de modelo diferentes! O Elasticsearch precisa decidir qual das configurações desses modelos deve ser aplicada. Felizmente, esse dilema pode ser resolvido usando a prioridade do modelo.

Como criar modelos de componentes

Aprendemos sobre modelos de índice na parte anterior deste artigo. Existem algumas desvantagens em criar modelos com a configuração já integrada – uma delas é que a configuração não pode ser exportada para outros modelos. Se desejarmos ter uma configuração semelhante, por exemplo, para modelos relacionados a clientes (*clientes), talvez tenhamos que recriar todo o modelo. Isso significa que podemos estar criando dezenas deles em uma organização típica (e você pode ter alguns outros dependendo do ambiente).

Como sempre buscamos a reutilização, o Elasticsearch redesenhou os modelos levando isso em consideração. Os modelos de componentes atendem a essa necessidade. Se você tem experiência em DevOps, provavelmente precisará criar índices com uma configuração predefinida para cada um dos ambientes. Em vez de aplicar manualmente cada uma dessas configurações de forma tediosa, você pode criar um modelo de componente para cada um dos ambientes.

Um modelo de componente nada mais é do que um bloco reutilizável de configurações que podemos usar para criar mais modelos de índice. Note que os modelos de componentes não têm utilidade a menos que sejam combinados com modelos de índice. Eles são expostos através de um endpoint _component_template. Vamos ver como tudo isso se encaixa.

Configurações em um modelo de índice

Vamos extrair as configurações que definimos anteriormente em nosso modelo de índice e criar um modelo de componente a partir delas. Espera-se que o settings_component_template tenha cinco shards primários com duas réplicas por shard primário. O primeiro passo, como mostra o código abaixo, é declarar e executar um modelo de componente com essa configuração.

Como mostra o código acima, usamos o endpoint _component_template para criar um modelo de componente. O corpo da solicitação contém as informações do modelo em um objeto de modelo. O modelo settings_component_template agora está disponível para uso em outros locais nos modelos de índice. Uma diferença notável é que este modelo não define nenhum padrão de índice; é simplesmente um bloco de código que configura algumas propriedades para nós.

Modelo de mapeamento

Da mesma forma, vamos criar outro modelo. Desta vez, vamos extrair o esquema de mapeamento que definimos anteriormente nos modelos de índice independentes. O código abaixo mostra o script:

Modelo de aliases

Seguindo a mesma linha de raciocínio, também podemos ter um modelo de componente com os aliases – dois aliases (all_orders e sales_orders):

Modelo de índice componível

Agora que temos esses três modelos de componentes, o próximo passo é colocá-los em uso. Podemos fazer isso permitindo que um modelo de índice, digamos, para pedidos de Natal, o utilize:

A tag `composed_of` é uma coleção de todos os modelos de componentes que compõem este modelo. Neste caso, estamos escolhendo as configurações, os mapeamentos e os modelos de componentes de aliases. Também estamos aumentando a prioridade, então este modelo terá precedência sobre qualquer outro. Assim que o modelo estiver pronto, quaisquer índices que correspondam ao padrão *orders herdarão a configuração desses três modelos de componentes.

Dito isso, caso desejemos criar um novo modelo, digamos, para clientes, utilizando apenas um dos modelos existentes (settings_component_template) e um modelo de aliases recém-criado (aliases_component_template – veja abaixo), podemos fazê-lo da seguinte forma:

O modelo de índice é o seguinte:

Você percebeu que o settings_component_template foi (re)utilizado em dois templates diferentes? Esse é o poder dos modelos de componentes.

Prioridade do modelo de índice

Existe a possibilidade de os desenvolvedores criarem vários modelos de índice sem analisar o estoque existente. É importante definir uma prioridade para cada um desses modelos, de forma que aquele com maior prioridade seja utilizado. Por exemplo, o modelo `my_orders_template_1` sobrescreve o modelo `my_orders_template_2` no seguinte trecho de código:

Quando você tem vários modelos que correspondem aos índices que estão sendo criados, o Elasticsearch aplica todas as configurações de todos os modelos correspondentes, mas sobrescreve qualquer configuração que tenha prioridade mais alta.

Precedência dos modelos

Por fim, você pode estar se perguntando sobre a precedência dos modelos – a configuração definida no modelo do componente substitui a definida no próprio modelo do índice principal? Ou vice-versa? Bem, existem algumas regras:

• Um índice criado com configurações explícitas tem precedência sobre tudo – isso significa que, se você criar um índice com configuração explícita, não espere que ela seja substituída pelos modelos.

• Os modelos legados (modelos criados antes da versão 7.8) têm uma prioridade menor do que os modelos componíveis.

Resumo

• Um índice contém mapeamentos, configurações e aliases: os mapeamentos definem o esquema dos campos, as configurações definem os parâmetros do índice, como o número de shards e réplicas, e os aliases fornecem nomes alternativos ao índice.

• Os modelos permitem criar índices com configurações predefinidas. Ao atribuir um nome a um índice que corresponda ao padrão de índice definido em um modelo específico, esse índice será configurado automaticamente de acordo com o modelo.

• O Elasticsearch introduziu modelos de índice componíveis na versão 7.8. Os modelos de índice combináveis permitem modularidade e versionamento dos modelos.

• Os modelos componíveis consistem em nenhum ou mais modelos de componentes.

• Um modelo de índice também pode ter sua própria configuração definida.

• Um modelo de componente é um modelo reutilizável com configuração predefinida, assim como um modelo de índice composto.

• No entanto, espera-se que os modelos de componentes façam parte de um modelo de índice; eles são inúteis se não forem "compostos" em um modelo de índice.

• Os modelos de componentes não têm um padrão de índice definido neles – o que é mais um motivo pelo qual "se espera" que façam parte de um modelo de índice.

• Cada um dos modelos tem uma prioridade – um número positivo. Quanto maior o número, maior a prioridade para a aplicação desse modelo.

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.

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.