Fragmentos e réplicas do Elasticsearch: um guia prático

Novo no Elasticsearch? Participe do nosso webinar Introdução ao Elasticsearch. Você também pode iniciar um teste gratuito na nuvem do Elastic ou experimentar o Elastic em sua máquina agora.

O Elasticsearch potencializa o Lucene ao construir um sistema distribuído sobre ele, o que resolve os problemas de escalabilidade e tolerância a falhas. Também disponibiliza uma API REST baseada em JSON, tornando a interoperabilidade com outros sistemas muito simples.

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.