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!!!