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"
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.
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
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
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.
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
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
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
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.
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
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