Elasticsearch
de dentro para fora
OPA!
Sou o Waldemar Neto
Engenheiro de software
http://walde.co
2
3
‘’
“Elasticsearch is a search server based
on Lucene. It provides a distributed,
multitenant-capable full-text search
engine with a RESTful web interface
and schema-free JSON documents.
Elasticsearch is developed in Java and
is released as open source under the
terms of the Apache License.”
Banon. Shay
4
Índice invertido
Term Doc_1 Doc_2 Doc_3
Waldemar x x
Bicicleta x x x
Avião x
5
1. Score
1.1. Bicicleta 3
1.2. Waldemar 2
1.3. Avião 1
Overview do ecossistema6
CLUSTER
NODE
SHARD REPLICA
Lucene
7
Como o Lucene vê os documentos
● O Lucene não separa tipos nem objetos.
● O Lucene é apenas chave e valor.
● Como os objetos são salvos
○ produto.nome = "test"
8
o campo _source
O campo source é compactado e jogado no disco.
9
o campo _all
O campo _all e fusão de todos os campos do documento em
um só.
10
Filter - Term level Query
11
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
(term level).
12
Quando usar filtros?
● Termos booleanos
● Termos que não mudam
● Termos que determinam regras
● Ranges
13
Caching
14
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.
15
TIPOS DE CACHE
● Shard-Level cache >= 1.4
● Filter Cache
16
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.
17
Filter Caching
Filtros não calculam relevância e não passam por análise,
dessa maneira eles podem ser cacheados pois na maioria das
vezes eles devolvem o mesmo resultado.
18
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.
19
Query
20
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.
21
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
22
Query vs Filter
23
Exemplo de Query e Filter juntos24
Ordem de prioridade25
score
26
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.
27
TF - Term Frequency
_search?name=test
{
"_id": 1,
"name": "this name is a test or not a test"
}
2
28
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
29
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"
}
30
Analyzers tem impacto?
31
Pagination é bom?
32
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.
33
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.
34
PREFIX vs REGEX vs NGRAM
35
Prefix Query
● Prefix queries rodam no term level ou seja não passam por analyzers.
● Por padrão não geram relevância, é mais como um filtro do que uma query.
36
Prefix query
PREFIX = EX;
UMA FRASE DE EXEMPLO
Retorna o ID
37
WILDCARD e REGEXP query
● Funcionam da mesma maneira que a Prefix Query
● Aceitam expressões regulares como * [0-9]
38
NGRAMS
● Buscas baseadas em digitação são incrementais
○ exemplo: waldemar = w wa wal wald walde waldem waldema
waldemar
● Só podem ser buscadas coisas que estão indexadas
○ Por que não indexar pedaços de terms?
39
Exemplo de Edge Ngram
waldemar
40
wa
wald
waldem
waldemar
E na produção?
Artigo publicado no iMasters sobre boas práticas
41
E ERAS ISSO!
PERGUNTAS?
HTTP://WALDE.CO/
42

Elasticsearch de dentro para fora

  • 1.
  • 2.
    OPA! Sou o WaldemarNeto Engenheiro de software http://walde.co 2
  • 3.
  • 4.
    ‘’ “Elasticsearch is asearch server based on Lucene. It provides a distributed, multitenant-capable full-text search engine with a RESTful web interface and schema-free JSON documents. Elasticsearch is developed in Java and is released as open source under the terms of the Apache License.” Banon. Shay 4
  • 5.
    Índice invertido Term Doc_1Doc_2 Doc_3 Waldemar x x Bicicleta x x x Avião x 5 1. Score 1.1. Bicicleta 3 1.2. Waldemar 2 1.3. Avião 1
  • 6.
  • 7.
  • 8.
    Como o Lucenevê os documentos ● O Lucene não separa tipos nem objetos. ● O Lucene é apenas chave e valor. ● Como os objetos são salvos ○ produto.nome = "test" 8
  • 9.
    o campo _source Ocampo source é compactado e jogado no disco. 9
  • 10.
    o campo _all Ocampo _all e fusão de todos os campos do documento em um só. 10
  • 11.
    Filter - Termlevel Query 11
  • 12.
    O que sãofiltros? Filtros são a melhor forma para trabalhar com "valores exatos" pois eles acessam diretamente o nível do Lucene (term level). 12
  • 13.
    Quando usar filtros? ●Termos booleanos ● Termos que não mudam ● Termos que determinam regras ● Ranges 13
  • 14.
  • 15.
    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. 15
  • 16.
    TIPOS DE CACHE ●Shard-Level cache >= 1.4 ● Filter Cache 16
  • 17.
    Shard Level cache Quandouma 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. 17
  • 18.
    Filter Caching Filtros nãocalculam relevância e não passam por análise, dessa maneira eles podem ser cacheados pois na maioria das vezes eles devolvem o mesmo resultado. 18
  • 19.
    Filtros que nãosã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. 19
  • 20.
  • 21.
    O que sãoQueries? ● 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. 21
  • 22.
    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 22
  • 23.
  • 24.
    Exemplo de Querye Filter juntos24
  • 25.
  • 26.
  • 27.
    Score Score é relacionadoa 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. 27
  • 28.
    TF - TermFrequency _search?name=test { "_id": 1, "name": "this name is a test or not a test" } 2 28
  • 29.
    IDF - InverseDocument 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 29
  • 30.
    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" } 30
  • 31.
  • 32.
  • 33.
    O PROBLEMA DOSIZE/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. 33
  • 34.
    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. 34
  • 35.
    PREFIX vs REGEXvs NGRAM 35
  • 36.
    Prefix Query ● Prefixqueries rodam no term level ou seja não passam por analyzers. ● Por padrão não geram relevância, é mais como um filtro do que uma query. 36
  • 37.
    Prefix query PREFIX =EX; UMA FRASE DE EXEMPLO Retorna o ID 37
  • 38.
    WILDCARD e REGEXPquery ● Funcionam da mesma maneira que a Prefix Query ● Aceitam expressões regulares como * [0-9] 38
  • 39.
    NGRAMS ● Buscas baseadasem digitação são incrementais ○ exemplo: waldemar = w wa wal wald walde waldem waldema waldemar ● Só podem ser buscadas coisas que estão indexadas ○ Por que não indexar pedaços de terms? 39
  • 40.
    Exemplo de EdgeNgram waldemar 40 wa wald waldem waldemar
  • 41.
    E na produção? Artigopublicado no iMasters sobre boas práticas 41
  • 42.