Com os temas de Big Data e Analytics nunca antes tão em alta, você certamente já ouviu falar sobre o uso de bancos de dados não relacionais, suas buscas e agregações mais performáticas, o conceito de schema free, entre outros. Pois bem, Elasticsearch (ES) não é à toa um dos DBs mais usados para esse fim. O poder das buscas full-text é o que faz o Facebook, Netflix, LinkedIn, Stone Co., entre outras empresas a adotarem a ferramenta.

Por isso, neste artigo, vamos abordar essencialmente cuidados que devem ser tomados com o Elasticsearch em produção e que, se não levados em conta, podem fazer da ferramenta uma dor de cabeça.

Memória

O Elasticsearch sempre pressupõe que você forneceu a ele memória suficiente. E, para prover sua alta performance, ele cria e mantém muitos caches diferentes, por exemplo:

  • Page cache: nem tudo vira trabalho só para o Elasticsearch. As partes complexas das estruturas de índice, como term dictionaries, posting lists, etc., são guardadas principalmente no cache de páginas do sistema operacional.
  • Field cache: onde armazenamos os valores de campos usados em buscas e scripts.
  • Filter cache: onde armazenamos os filtros, aumentando a performance de uso desses mesmos filtros futuramente.

Além do mais, as próprias estruturas de index requerem muita memória. Por exemplo, na figura 1, vemos como o Elasticsearch guarda um determinado campo setado como analyzed (configuração default, caso você não especifique que seja not_analyzed).

Se você quer indexar o valor analisável “Baseball is played during summer months.”, ele vai dividir em [“Baseball”, “is”, “played”, “during”, “summer”, “months”]. Caso o campo não seja analisável, ele indexará normalmente como “Baseball is played during summer months”. Você também pode setar para lowerCase, entre outras funcionalidades, mas que não é o nosso foco aqui. O fato é que essa complexa estrutura de dicionário é criada automaticamente, o que facilita buscas futuras por tais termos.

Inverted-index table: indexação de um texto analisável.

Figura 1 – Inverted-index table: indexação de um texto analisável.

Novamente, o ES assume que você forneceu memória suficiente a ele. Enquanto ele não é tão resiliente assim, os erros de OutOfMemory podem acabar desde em uma falha no request, até em corromper o estado do cluster ou reduzir todo o cluster.

Aprendemos então nosso primeiro mandamento:

Primeiro mandamento

Mas na prática, como lidar com isso? Não dá para simplesmente fornecer todo o recurso do mundo.

Primeiramente, não coloque seu cluster de produção nessas situações de intensa demanda de primeira. Entenda a demanda de seu perfil de memória e vá monitorando continuamente o consumo de recursos do seu cluster, à medida que mais dados são adicionados. Comece com mais memória do que o necessário e vá reduzindo até encontrar o ponto ideal.

Com os serviços em nuvem e alugando a capacidade por hora, é barato começar com muito, indexar os dados e testar a performance. Por fim, examine as métricas que o próprio Elasticsearch fornece (uso de heap space, cache stats, tamanho dos fields, entre outras).

Em suma, o quanto de memória necessária depende de vários fatores, como os tipos e diversidade de buscas, taxas de crescimento e atualização de dados, etc..

 Figura 2 - Métricas de saúde do seu cluster

Figura 2 – Métricas de saúde do seu cluster

Segurança

Não espere que o Elastic configure autenticação e autorização. Como ele não faz distinção de permissão de usuário, você precisa tomar as seguintes boas práticas na camada de aplicação:

  • Ninguém quer expor dados privados. Portanto, limite as pesquisas a determinados índices e aplique filtros. Na figura 3, por exemplo, o artifício do * pode ser útil, mas também perigoso. Isso porque o usuário acaba por acessar todos os índices que derem match ao formato inicial “insight-2017-09-”;

Figura 3 - Busca dentre diversos índices

Figura 3 – Busca dentre diversos índices

  • Restrinja quem pode atualizar o que. Especialmente quando se tem habilitado scripts dinâmicos, e aqui vai nosso próximo conselho;
  • Muito cuidado com scripts dinâmicos: essa é uma ferramenta muito poderosa do ES. Esses scripts não rodam em sandbox, logo, eles têm acesso a basicamente tudo. Nesse caso, é bom habilitar scripts apenas no contexto necessário (os contextos são: aggs, search, update ou plugin);
  • Previna requests que podem sobrecarregar ou quebrar nós ou todo o seu cluster. Como já abordamos aqui, memória é nosso primeiro mandamento, então esteja seguro de que ninguém vá quebra-lo.

Chegamos então no nosso segundo mandamento:

Segundo mandamento

Sistema distribuído

Sabemos que o Elasticsearch foi feito pra ser escalável a vários nós, mas como todo sistema distribuído, muitas coisas podem dar errado. Alguns sistemas assim se esforçam para obter garantias seguras, outros, para disponibilidade. Mesmo que isso signifique ser impreciso algum momento ou mesmo a maior parte do tempo.

Um caso típico que precisa ser tratado é o fenômeno Split Brain. Lembrando que uma requisição pode ser enviada para todo nó dentro do cluster, porque qualquer nó sabe a localização de qualquer documento no cluster. Sendo assim, ele pode passar o request diretamente para o nó onde se encontra o documento.

Porém, um nó eleito master é responsável por coordenar todas as mudanças no cluster. Essas mudanças podem ser a adição e remoção de nós, criação, exclusão ou alteração de estado de um index. Em suma, ele é quem coordena o cluster e garante sua saúde.

Um Split Brain acontece quando existem dois ou mais subgrupos autônomos de nós, sem comunicação entre eles, e mais de um acredita que é master. Isso pode causar alterações não sincronizadas ​​e perda de dados.

Por exemplo, na figura 4, digamos que a comunicação seja feita entre os nós e o número mínimo de nós master (minimum_master_nodes) seja 1. Caso o nó 1 perca conexão com os demais, o subgrupo {1} encara como se o outro subgrupo {2,3} tivesse falhado com a conexão e continuará como master. Enquanto que o subgrupo {2,3} encara como se o subgrupo {1} tivesse falhado e elegerá algum de seus nós como master, porque possui a quantidade mínima (1).

O resultado são dois subgrupos que se consideram master, operando separadamente. Será possível indexar documentos, mas as buscas podem diferir dependendo do nó pesquisado. Do contrário, se tivéssemos colocado um mínimo de 2 nós como master, o subgrupo {1} automaticamente teria deixado sua posição de master. Assim que a conexão fosse restabelecida entre os subgrupos, as diferenças seriam devidamente tratadas.

Por isso, para evitar que dois lados de uma partição sejam elegíveis, é necessário ter uma maioria, um quorum. Assim, o número mágico (minimum_master_nodes) é de (arredondado para baixo), onde n é o número de nós elegíveis a master (master_eligible_nodes).

Figura 4 - Exemplo de alocação de nós

Figura 4 – Exemplo de alocação de nós

Terceiro mandamento

O cliente

Mesmo com todas as cautelas tomadas acima, ainda assim é preciso olhar para o cliente nos seguintes aspectos:

  • Idempotência: reenviar um request muitas vezes deve ter o mesmo efeito que enviar apenas uma vez. Isso é fundamental para manter a capacidade de retentar um request, especialmente na indexação de um documento. Por exemplo, se você tentar indexar um documento e não receber resposta, não há como saber se ele foi indexado. A solução para isso é especificar o ID para o documento, como na figura 5, e assim retentar o request. Se você deixar o Elasticsearch atribuir os IDs, então gerará duplicações caso já tenha sido indexado;

Figura 5 - Indexando um documento com ID específico (trecho de código em C#)Figura 5 – Indexando um documento com ID específico (trecho de código em C#)

  • Connection Pool: caso você use a interface HTTP do ES, estabeleça sempre um pool de conexões, pra diminuir a latência de criação de novas conexões;
  • Bulk endpoint: o Elastic possui um endpoint que permite várias operações de indexação com um único request, útil na indexação de documentos.

Quarto mandamento

Conclusão

É preciso ter em mente que o Elasticsearch tem features incríveis, em uma velocidade e escalabilidade igualmente surpreendentes. Seu schema flexível, desnormalizado e suas buscas e agregações muito performáticas fazem seu nome no mercado. Mas, para manter a melhor performance possível, é inevitável olhar todos os pontos aqui abordados.

Se você precisa de um banco normalizado, que reverta transação e que nunca possa estar inoperante ou faça autenticação, então o ES não pode ser seu banco principal. Mas se você procura um DB para ser sua melhor solução em indexação e pesquisa, então está no lugar certo.

 

Bruna Alves

Bruna Alves

Graduanda em Engenharia de Computação pelo IME e desenvolvedora na Mundi. Apaixonada pelo universo Elasticsearch, com experiência aplicando a tecnologia em BI.
Bruna Alves

Últimos posts por Bruna Alves (exibir todos)

Quer receber as novidades de e-commerce em primeira mão?

x