Skip to Content

O que é arquitetura Elasticsearch?

Lançado em 2010, o Elasticsearch foi um dos primeiros mecanismos de pesquisa distribuídos feitos para consulta rápida de dados para exibição em análise ou saída de Big Data. Na época, mais empresas estavam acumulando grandes quantidades de dados, mas os mecanismos de banco de dados tradicionais não conseguiam acompanhar. O Elasticsearch foi introduzido como um banco de dados vetorial capaz de armazenar dados estruturados e não estruturados. Foi o primeiro grande salto na indexação de Big Data e consultas mais rápidas quando a análise corporativa excedeu terabytes de dados, causando problemas de desempenho.

O que é o Elasticsearch?

O Elasticsearch é um datastore usado para reunir dados e torná-los pesquisáveis por meio de uma API. Ele é baseado no Apache Lucene, que é um serviço de indexação e armazenamento que distribui dados em fragmentos. Cada shard mantém seus próprios dados, mas os shards são mantidos separados um do outro para distribuir dados entre nós. O Elasticsearch reúne todos os fragmentos e fornece uma API para desenvolvedores consultarem dados. Com a API, os administradores podem definir permissões para usuários específicos para proteger ainda mais os dados e dar acesso a dados específicos apenas para usuários autorizados.

Os desenvolvedores não estão limitados a dados estruturados ou não estruturados. O Elasticsearch permite que os usuários extraiam dados estruturados e não estruturados, mas consulta dados em seus fragmentos distribuídos como se o armazenamento fosse um banco de dados grande. A maneira como o Elasticsearch lida com dados torna tudo muito mais rápido do que um mecanismo de banco de dados padrão, por isso é melhor para aplicativos com análise, funcionalidade de pesquisa em muitos dados ou análise de tráfego de rede.

Principais componentes da arquitetura Elasticsearch

O primeiro componente central do Elasticsearch é o nó. Um nó é um servidor ou dispositivo onde os dados são armazenados. Os clusters são compostos por um conjunto de nós. Nós e clusters podem ser distribuídos entre datacenters para redundância, mas os dados distribuídos são o que melhora o desempenho em consultas de dados. O Elasticsearch é um banco de dados de vetores, mas armazena dados como documento. Um documento é uma entidade que armazena dados não estruturados, embora os dados estruturados também possam ser armazenados nele.

Os dados são fragmentados entre nós. Os fragmentos são uma parte dos dados para segmentar grandes datatores em partes menores, o que facilita a distribuição e a consulta simultânea para reunir dados em um conjunto de resultados para o aplicativo de front-end. O Logstash é usado como o fluxo de dados, que pega os dados em sua forma bruta e os transforma em uma forma utilizável. 

O Elasticsearch também tem uma API que é o gateway para dados. Os desenvolvedores devem autenticar na API e consultá-la com uma chave. A API controla o acesso aos dados e a maneira como os desenvolvedores podem consultá-los. Ter uma API também obscurece a arquitetura de back-end e a protege, tornando-a acessível para desenvolvedores não familiarizados com a forma como o Apache Lucene e outros componentes funcionam.

Nós e clusters

Um cluster é um grupo de nós, mas os nós têm sua própria função específica em um cluster. O nó mestre, geralmente falando, controla o cluster. O nó mestre pode criar ou excluir índices e rastrear outros nós que participam do cluster. Cada cluster tem um nó mestre.

Um nó de dados armazena os dados. Qualquer manipulação ou alteração nos dados é de responsabilidade do nó de dados. Conforme você agrega dados, adiciona ao nó de dados. A funcionalidade de pesquisa também acontece no nó de dados.

Pense em nós coordenados como os gateways que controlam o tráfego para o nó certo. Um nó coordenador envia solicitações para o nó mestre ou nós de dados, dependendo do destino. Por exemplo, quando uma pesquisa é enviada para o cluster, o nó coordenador gerencia sua solicitação.

O Elasticsearch tem um fluxo para transformar e mover dados. O nó de entrada é responsável por gerenciar documentos e transformá-los para indexação. A Elasticsearch recomenda ter um nó de entrada independente dos nós mestre e de dados em ambientes com transferências de dados pesadas.

Os nós qualificados remotamente enviam solicitações para outros clusters no sistema Elasticsearch. As consultas de pesquisa podem encontrar dados usando a funcionalidade de cluster cruzado com um nó qualificado para remoto. A replicação de dados entre clusters também é responsabilidade dos nós elegíveis remotamente.

Fragmentos e réplicas

Pesquisas e consultas rápidas exigem índices. Os índices são a maneira de um datastore organizar dados de uma maneira que torna as pesquisas mais rápidas. No Elasticsearch, cada índice é composto por vários fragmentos. Os fragmentos são armazenados em nós onde o Elasticsearch os distribui pelo cluster para processamento mais rápido. Os shards contêm uma cópia dos dados, mas o Elasticsearch pode realizar pesquisas simultâneas em vários shards.

A redundância é necessária para failover e tolerância a falhas, portanto, as réplicas lidam com uma cópia de fragmentos. As réplicas são armazenadas em diferentes nós para que os dados não sejam perdidos quando um nó falha. Se um nó falhar, o Elasticsearch poderá acessar dados em uma réplica em um nó diferente.

Fluxo de dados no Elasticsearch

O Elasticsearch fornece uma API para desenvolvedores enviarem suas consultas. A API protege os desenvolvedores da complexidade do back-end. O back-end, conforme discutido, é composto por vários componentes, incluindo fragmentos, nós, índices e réplicas. Em vez de forçar os desenvolvedores a gerenciar pesquisadores do Elasticsearch, o fluxo de dados começa com uma consulta à API.

A API envia a consulta primeiro para um coordenador. O coordenador envia para o nó apropriado onde os fragmentos estão localizados. Uma consulta também poderia ser enviada para vários fragmentos, cada um com seu próprio conjunto de dados. O roteamento é feito pelo coordenador, que determina os fragmentos certos para a consulta.

Depois que os shards coletam documentos, os índices dos documentos são enviados de volta ao coordenador. Quando vários shards enviam dados de volta para o coordenador, o coordenador organiza os índices, os mescla e os classifica. Com os índices classificados, o coordenador recupera os documentos reais dos fragmentos. Depois que os dados são recuperados, eles são enviados de volta ao aplicativo por meio da API.

Melhores práticas para otimizar a arquitetura Elasticsearch

O Elasticsearch é muito mais complexo do que o mecanismo de banco de dados comum, portanto, a otimização exige uma abordagem diferente. Primeiro, você precisa garantir que recursos suficientes estejam sendo executados no back-end. Se as consultas forem muito lentas, considere aumentar a capacidade de armazenamento da CPU, da memória ou do servidor.

Os índices são necessários para pesquisar dados, mas alguns dados não são usados com tanta frequência quanto outros dados. O Elasticsearch permite congelar índices, que move índices não usados para outro fragmento. Os coordenadores têm menos fragmentos para pesquisar cada consulta, melhorando o desempenho.

Os pools de threads nos tamanhos de consulta de controle do Elasticsearch devem ser otimizados para dar suporte à quantidade de dados tratados em cada consulta. Configure pools de threads para lidar com dados suficientes para suas consultas, mas eles também estão vinculados aos recursos do nó. Tanto nós quanto pools de threads devem ter recursos suficientes, ou você pode ver desempenho degradado durante consultas de alto volume.

Conclusão

O Elasticsearch é muito mais complexo do que um banco de dados padrão, portanto, é necessário ter os recursos corretos de arquitetura e computação para um desempenho ideal. Use as práticas recomendadas ao configurar o Elasticsearch, mas também é importante ter os recursos de computação certos para dar suporte às consultas e ao armazenamento de dados necessários para o back-end.

Uma maneira de garantir que você tenha recursos de armazenamento suficientes é aproveitar o FlashBlade® da Pure Storage®. O FlashBlade oferece suporte a um crescimento exponencial para pequenas e grandes empresas. Seus aplicativos podem ser expandidos conforme mais usuários armazenam dados e oferecem suporte a qualquer número de clientes.

03/2025
A Buyer’s Guide to Cyber Resilience
Cyber resilience from Pure Storage® is an integrated solution designed to safeguard critical data, proactively detect threats, and deliver near-instant recovery.
Guia do comprador
12 pages
ENTRE EM CONTATO
Entre em contato com a PureÍcone de informações
Ícone de chat
Dúvidas ou comentários?

Tem dúvidas ou comentários sobre produtos ou certificações da Pure?  Estamos aqui para ajudar.

Ícone de chave
Agende uma demonstração

Agende uma demonstração ao vivo e veja você mesmo como a Pure pode ajudar a transformar seus dados em resultados poderosos. 

Telefone: 55-11-2844-8366

Imprensa: pr@purestorage.com

 

Sede da Pure Storage

Av. Juscelino Kubitschek, 2041

Torre B, 5º andar - Vila Olímpia

São Paulo, SP

04543-011 Brasil

info@purestorage.com

FECHAR
FecharÍcone X para fechar
Seu navegador não é mais compatível.

Navegadores antigos normalmente representam riscos de segurança. Para oferecer a melhor experiência possível ao usar nosso site, atualize para qualquer um destes navegadores mais atualizados.