Elasticsearch: o desafio como banco principal e cuidados em produção

Globalcode – Open4education
Trilha – NoSQL
Bruna Ramalho
Graduanda em Engenharia de Computação pelo IME

Elasticsearch: o desafio como banco
principal e cuidados em produção

Quem Sou Eu?

Quem sou eu?
● 6º período em Engenharia de
Computação pelo IME
● Desenvolvedora na Stone em
Data Science
● Apaixonada pelo universo
Elasticsearch 💚

“Com grandes poderes, vêm
grandes responsabilidades”
Tio Ben, Homem-Aranha

Conceitos básicos

Conceitos básicos
● Documento = unidade básica de
informação, em JSON
● Tipo = coleção de documentos com
campos em comum
● Índice = coleção de documentos com
características semelhantes
Um índice pode ter vários tipos
● Nó (servidor) = armazena os dados
● Cluster = coleção de nós
Um cluster pode ter vários índices
Contém todos os dados e possibilita
pesquisa por todos os nós

Conceitos básicos
● Shards:
Dividir o volume de dados em um
nó, por limitação de espaço em
disco.
Distribuir e paralelizar operações
entre shards
● Replicas:
Fornecer disponibilidade caso um
shard/nó falhe.
Escalar volume de pesquisas.

Mas por que é tão
performático???

Schema Flexible ("schema free")
Não requer especificação de um
esquema.
●
● Mas… para desenvolver ótimas
pesquisas e análises, precisamos
ajustar seus esquemas.
● User-defined schemas: cuidado com
criação de mappings indesejados.

Document Oriented DB:
desnormalização
● Usa mais espaço
● Dificulta atualização de dados
● Aumenta performance de busca
● Excelente para Write-Once-Read-Many-
Workloads (ex. Logstash)

No Transactions
● Não há como reverter um documento
indexado
● Ganho de velocidade

You Know, For Search!
● Simple search
Menos esforço do que contar e agregar os
matches

● Fuzzy search: onerosas em
performance
Aplicação: erros de ortografia

● Aggregating
Aplicação: Kibana, Big Data,...

Autocompletion e Instant Search
● Autocompletion: prever uma pesquisa
com base no histórico de pesquisas
● Instant search: fazer uma busca
completamente nova para cada tecla
digitada
● Muito sensíveis a latências.
Mais de 100 ms não é mais "instantâneo"
● Focar em pesquisas baratas e índices
que caibam na memória

● Sobrecarga de memória
● Pode gerar muita duplicação
(inverted index)
● Snapshot e backups são processos
seriais, com uma sobrecarga por índice
Muitos índices pequenos ou
poucos índices grandes?

Mas, contudo, porém,
todavia...

Não devo usar como
banco principal quando...

Robustez
● Cancelar queries
● Estar sempre operante (ES é baseado
em sempre ter memória abundante)

Distribuído
● Fácil de escalar para lidar com enormes
quantidades de dados
● Mas... problemas com consistência,
tolerância de partição e disponibilidade
● Quantidade de shards pré-estabelecida
(você pode apenas realocar shards nos
nós)

Latência, segurança e durabilidade
● Sem autenticação ou autorização
● Todo mundo com super direitos
(cuidado com permissão de scripts...)
● Dados precisos em Real-Time
Near Real-Time (NRT): latência até ser
pesquisável
● Recursos de segurança necessários
● Durabilidade
Afinal, perder seus dados nunca é bom.

Cuidados em produção

Memória
● Manutenção de cache
Estruturas de index (ex. term
dictionaries) em page cache do sistema
operacional
Field cache: usados para faceting,
sorting e scripting
Filter cache: usos futuros bem mais
rápidos
● ES sempre assume que você proveu
memória suficiente
● Consequências:
Falhar com o request
Corromper cluster state
Reduzir todo o cluster

● Não colocar de primeira o cluster de
produção nessas situações de intensa
demanda
● Entender o perfil dos requests e
monitorar o consumo dos recursos, na
medida em que dados são adicionados.
● Quanto de memória eu preciso?
Comece com mais memória que
necessário
Examine as métricas (uso de heap
space, cache stats, tamanho dos fields,
etc)
Memória - boas práticas

Segurança - boas práticas
● Exposição de dados privados: limitar as
pesquisas a determinados índices e
aplicar filtros às pesquisas.
● Restringir quem pode atualizar o que.
● Cuidado com scripts dinâmicos (ex.
updates parciais). Esses scripts não
rodam em sandbox; logo, eles têm
acesso a basicamente tudo no ES.
● Prevenir requests que podem
sobrecarregar ou quebrar nós ou todo o
cluster.

Sistema distribuído - boas práticas
● ES é mega escalável, mas cuidado com a alocação dos nós
● Split Brains: múltiplos sub-clusters autônomos e mais de um acredita que é o master.
n = número de nós elegíveis a master no cluster.
⌊n/2⌋ + 1 = número mínimo de nós master elegíveis que devem estar presentes para que o cluster
escolha um mestre e aceite requests.

Considerações sobre o cliente
● Idempotência (ex. indexar um documento com um ID específico)
● Connection pool
● Bulk endpoint (ex. indexar vários documentos de uma vez)

● Não espere maçã com gosto de uva
● “Com grandes poderes, vêm grandes responsabilidades”
Em resumo...
Dúvidas?
Sugestões? Elogios?

Bruna Ramalho
ramalho.alves.bruna@gmail.com
+55 (21) 97188-7669
brunaalvesramalho
Happy searching!
Obrigada :)

Elasticsearch: o desafio como banco principal e cuidados em produção

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (6)

Semelhante a Elasticsearch: o desafio como banco principal e cuidados em produção

Semelhante a Elasticsearch: o desafio como banco principal e cuidados em produção (20)

Elasticsearch: o desafio como banco principal e cuidados em produção