O documento discute como o Elasticsearch funciona internamente de forma concisa em 3 pontos: 1. O Elasticsearch usa o Lucene para indexar e buscar documentos de forma distribuída em shards e réplicas. 2. O índice é atualizado em tempo real à medida que os documentos são adicionados ou atualizados usando um buffer e translog para garantir consistência. 3. Diferentes tipos de consultas como filtros e queries são discutidos em termos de quando usá-los e como funcionam para fornecer resultados relevantes de forma eficiente.

1. Elasticsearch
de dentro para fora

2. OPA!
Sou o Waldemar Neto
Engenheiro e consultor na ThoughtWorks.
http://walde.co
2

3. Índice invertido
Term Doc_1 Doc_2 Doc_3
Waldemar x x
Bicicleta x x x
Avião x
3
1. Score
1.1. Bicicleta 3
1.2. Waldemar 2
1.3. Avião 1

4. Overview do ecossistema4
CLUSTER
NODE
SHARD REPLICA

5. Lucene

6. Como o Lucene vê os documentos
● O Lucene não separa tipos nem objetos.
● O Lucene é apenas chave e valor.
● Como ele vê objetos?
○ produto.nome = "test"

7. o campo _source
O campo source é compactado e jogado no disco.

8. o campo _all
O campo _all e fusão de todos os campos do documento em
um só.

9. Como o SHARD funciona
● Como a busca é "real-time"?
● Como as operações de CRUD são "real-time"?
● Por que quando deletamos dados o espaço em disco
não fica livre na hora?
● O que o refresh, flush e optimize fazem e quando devo
usar eles?

10. como a busca é real-time?
● Inverted index é imutável
● Como indexar dados sem recriar todo o inverted index?
● O conceito per-segment
○ Um segment é um inverted index
○ um index no Lucene é uma coleção de segments
○ Um commit point é um arquivo que lista todos os segments

11. como a busca é real-time?
index vs shard
● Lucene Index é o que conhecemos como shard
Documentos prontos para serem commitados

12. como a busca é real-time?
processo de commit
● Novos documentos são coletados e adicionados a um buffer de memória.
● Frequentemente o buffer é commitado
○ Um novo segment é escrito em disco.
○ Um novo commit-point é escrito incluindo o novo segment.
○ O fsync entra em ação, e todas as escritas esperando no file-system cache
são escritas no disco para garantir que eles estão fisicamente salvos.
● O novo segment é aberto, fazendo com que os documentos sejam liberados para a
busca.
● O buffer de memória é liberado para receber novos documentos.

13. como a busca é real-time?
processo de commit
Depois de um commit o novo segment é adicionado ao
commit-point e o buffer é limpo.

14. como a busca é real-time?
deletes e updates
● Segments são imutáveis
○ documentos não podem ser removidos de segments velhos
○ segments não podem ser alterados para refletir a versão mais recente de um
documento.
● Cada commit-point cria um arquivo .del onde é listado todos os documentos
deletados e a qual segment pertencem.
○ Quando um documento é deletado ele basicamente é marcado como
deletado no arquivo .del
○ Um documento deletado ainda ira ser visto pelas queries mas sera removido
dos resultados.
● Updates funcionam de uma maneira parecida.
○ Quando um documento é atualizado a versão antiga é marcada como
deletada no arquivo .del
○ A nova versão do documento é indexada em um novo segment.

15. como a busca é real-time?
o gargalo do disco
● Aguardar os dados criados serem escritos em disco poderia levar mais de um
minuto.
● Commitar o novo segment para o disco depende do fsync.
○ esse processo é custoso e não pode ser feito toda vez que um documento é
indexado.
● Entre o elasticsearch e o disco fica o file-system cache
○ Novos segments são escritos no file-system cache primeiro.
○ Depois são escritos no disco, mas já no file-system cache ficam abertos para
busca.

16. como a busca é real-time?
Refresh API
● Refresh é o processo de escrever e criar um novo segment
○ Por padrão o refresh em cada shard acontece a cada segundo.
○ As mudanças não são vistas imediatamente.
● Forçar o refresh em índices com muitas escritas pode causar sérios problemas de
performance.

17. como a busca é real-time?
Refresh API
● Refresh é o processo de escrever e criar um novo segment.
○ Por padrão cada o refresh em cada shard acontece a cada segundo.
○ As mudanças não são vistas imediatamente.
● Forçar o refresh em índices com muitas escritas pode causar sérios problemas de
performance.

18. como a busca é real-time?
Translog
● Quando um documento é indexado ele é adicionado ao buffer de memória e
também ao translog.

19. como a busca é real-time?
translog
● A cada segundo o shard é atualizado pela refresh api
○ Os documentos no buffer de memória são escritos em um novo segment
(mas não escritos em disco)
○ O segment é liberado para ser buscado
○ O buffer de memória é limpo

20. como a busca é real-time?
Translog
● O processo continua com mais documentos sendo adicionados para o buffer de
memória e também ao translog

21. como a busca é real-time?
Translog
● Quando o translog se torna grande o index(lucene) passa pelo processo de flush e
um novo translog é criado.
○ Todos os documentos no buffer de memória são adicionados a um segment
○ O buffer é limpo
○ O commit-point é escrito no disco
○ O file-system cache passa por um flush usando o fsync
○ O translog é deletado

22. como a busca é real-time?
Translog
● O translog garante que as mudanças vão estar disponíveis
○ Quando buscamos/editamos/deletamos um documento por ID ele verifica
primeiro no translog por mudanças mais atuais antes de buscar do segment.

23. como a busca é real-time?
Flush API
● A ação de fazer um commit e limpar o translog é chamada de flush.
○ Shards fazem flush a cada 30 minutos automaticamente, ou quando o
translog se torna grande.

24. como a busca é real-time?
Segment Merging
● Como segments são criados a cada segundo, não demora para que tenhamos
vários deles.
○ Cada segment consome I/O, memoria e CPU.
○ Cada busca tem que checar todos os segments, quanto mais segments mais
lento sera.
● Os segments de tamanhos pareciados são mesclados em um grande segment
● Esse é o momento que os documentos deletados são removidos do file system.
○ Documentos deletados e versões antigas não são copiadas para o segment
grande.

25. como a busca é real-time?
Segment Merging

26. como a busca é real-time?
Segment Merging
● É feito flush do novo segment
● Um novo commit-point é feito com esse
segment e os velhos e menores são removidos
● O novo segment é liberado pra busca

27. ● A optimize api força o segment merging
○ É possível limitar o numero de segments forçando os merges a
acontecerem mais frequentemente.
● Reduzindo o numero de segments aumenta a velocidade da busca.
● Não deve ser usado em índices com muita escrita pois atrapalha o processo
de merging.
como a busca é real-time?
Optimize API

28. Filter

29. O que são filtros?
Filtros são a melhor forma para trabalhar com "valores
exatos" pois eles acessam diretamente o nível do Lucene
e dispensam o nível de analise, além de serem cacheados
por padrão.

30. COMO OS FILTROS
FUNCIONAM
● Combinação de termos exatos
○ Tipos como String, Numérico, Booleano, Ranges
são combinados pelo tipo.
● Executado ao nível do Lucene (search level)
● Podem ser cacheados

31. Quando usar filtros?
● Termos booleanos
● Termos que não mudam
● Termos que determinam regras
● Ranges

32. Caching

33. O que é cache?
Resultados guardados em memória, desta maneira o shard
não precisa calcular as resultados novamente nem fazer o
calculo de relevância.

34. TIPOS DE CACHE
● Shard-Level cache >= 1.4
● Filter Cache

35. Shard Level cache
Quando uma busca é executada dentro de um index, cada
shard executa sua busca localmente e calcula seu
resultado. Esse resultado é mesclado com o resultado
global no coordinating node.

36. Filter Caching
Filtros não calculam relevância e não passam por analise,
dessa maneira eles podem ser cacheados pois na maioria das
vezes eles devolvem o mesmo resultado.

37. Filtros que não são
cacheados
Alguns filtros não são cacheados por padrão pois são
usados para buscas que mudam a cada chamada como
por exemplo AND, OR e RANGE.
É possível forçar o cache usando "_cache" : true

38. Query

39. O que são queries?
● Queries determinam como a busca deve se comportar e
garantem que o conteúdo buscado vai ser procurado e
comparado da maneira certa.
● Elas conseguem calcular o quão relevante aquele
resultado é para a busca que foi feita.

40. Quando usar queries?
● Quando relevância é importante
● Quando é necessário mudar as regras do termo como
linguagens e sinônimos
● Quando o full text search é importante
● Quando analisar os termos é importante

41. Query vs filter

43. Query vs Filter

44. score

45. Score
Score é relacionado a relevância do resultado de uma busca
para com o que foi buscado. São usados dois padrões para
determinar relevância em uma Query que são TF e IDF.

46. TF - term frequency
_search?name=test
{
"_id": 1,
"name": "this name is a test or not a test"
}
2

47. IDF - Inverse Document Frequency
_search?name=test
{
"_id": 1,
"name": "this name is a test or not a test"
}, {
"_id": 2,
"name": "this name is a test"
}
2
1

48. Field Lenght Norm
_search?name=test
{
"_id": 1,
"name": "this name is a test or not a test"
}, {
"_id": 2,
"name": "this name is a test"
}

49. Analyzers impact

50. Impacto de analyzers
Prefira custo no index do que na busca.

51. PAGINATION

52. O PROBLEMA DO SIZE/FROM
● Cada shard calcula seu size
● Cada shard gera seus próprios resultados limitados
● Todos os resultados são mesclados no coordinator node
● O shard precisa percorrer os dados
○ Imagine que queremos os resultados de 1010 até
1020
■ Cada shard vai produzir 1020 resultados
○ O cordinator node vai receber 5100 resultados caso
tenha 5 shards
■ Vai remover 5090 resultados para produzir
apenas 10.

53. QUE TAL SCAN/SCROLL?
● A scroll api é usada pelo elastic para buscar grandes números de documentos.
○ Uma busca por scroll permite que façamos uma busca inicial e continuemos
buscando até que não tenha mais resultados.
■ Mais ou menos como um cursor em bancos de dados tradicionais
○ Depois da busca inicial ser feita as próximas não irão pegar atualizações de
documentos caso tenha neste intervalo.
● O scan permite que desativemos o sorting do elastic e apenas retorne os
proximos dados do scroll.
● Para usar basta fazer uma busca colocando o search_type como scan e passando
o parâmetro scroll dizendo quanto tempo esse scroll pode ficar aberto.

54. PREFIX VS REGEX
VS NGRAM

55. Prefix Query
● Prefix queries rodam em baixo nível ou seja não passam por analyzers.
● Por padrão não geram relevância, é mais como um filtro do que uma query.
● Mas como funciona?
○ O inverted index é uma lista de termos.
○ Vários termos consistem uma frase e pertencem a um campo.
● Mas como busca?
○ Lista todos os termos.
○ Checa o primeiro para ver se começa com o prefix informado.
○ Pega o id do documento que o term pertence
○ Move para o próximo
○ Se ele começar com o prefix informado pega o id
○ Move para o próximo
○ Até acabar

56. PREFIX QUERY
PREFIX = EX;
UMA FRASE DE EXEMPLO
Retorna o ID

57. WILDCARD e REGEXP query
● Funcionam da mesma maneira que a Prefix Query
● Aceitam expressões regulares como * [0-9]

58. NGRAMS
● Buscas baseadas em digitação são incrementais
○ exemplo: waldemar = wal ald lde dem ema mar
■ São produzidos 6 terms para formar o term desejado
● Só podem ser buscadas coisas que estão indexadas
○ Por que não indexar pedaços de terms?
● Edge ngram
○ Inicia do começo da palavra

59. Na produção
artigo publicado no iMasters sobre boas práticas

60. ATÉ MAIS PESSOAL!!!