Elasticsearch shards, index, filters and queries
-
Upload
waldemar-neto -
Category
Technology
-
view
267 -
download
0
Transcript of Elasticsearch shards, index, filters and queries
Elasticsearch de dentro para fora
OPA!Sou o Waldemar NetoEngenheiro e consultor na ThoughtWorks.http://walde.co
2
Índice invertido
Term Doc_1 Doc_2 Doc_3
Waldemar x x
Bicicleta x x x
Avião x
3
1. Score1.1. Bicicleta 31.2. Waldemar 21.3. Avião 1
Overview do ecossistema4
CLUSTER
NODE
SHARD REPLICA
Lucene
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"
o campo _source
O campo source é compactado e jogado no disco.
o campo _all
O campo _all e fusão de todos os campos do documento em um só.
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?
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
como a busca é real-time? index vs shard
● Lucene Index é o que conhecemos como shard
Documentos prontos para serem commitados
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.
como a busca é real-time? processo de commit
Depois de um commit o novo segment é adicionado ao commit-point e o buffer é limpo.
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.
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.
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.
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.
como a busca é real-time? Translog
● Quando um documento é indexado ele é adicionado ao buffer de memória e também ao translog.
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
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
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
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.
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.
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.
como a busca é real-time? Segment Merging
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
● 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
Filter
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.
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
Quando usar filtros?
● Termos booleanos● Termos que não mudam● Termos que determinam regras● Ranges
Caching
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.
TIPOS DE CACHE
● Shard-Level cache >= 1.4● Filter Cache
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.
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.
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
Query
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.
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
Query vs filter
Query vs Filter
score
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.
TF - term frequency
_search?name=test{ "_id": 1,
"name": "this name is a test or not a test"}
2
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
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"
}
Analyzers impact
Impacto de analyzers
Prefira custo no index do que na busca.
PAGINATION
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.
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.
PREFIX VS REGEX VS NGRAM
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
PREFIX QUERY
PREFIX = EX;UMA FRASE DE EXEMPLO
Retorna o ID
WILDCARD e REGEXP query
● Funcionam da mesma maneira que a Prefix Query● Aceitam expressões regulares como * [0-9]
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
Na produçãoartigo publicado no iMasters sobre boas práticas
ATÉ MAIS PESSOAL!!!