Elasticsearch shards, index, filters and queries
0 gostou710 visualizações
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.
![WILDCARD e REGEXP query
● Funcionam da mesma maneira que a Prefix Query
● Aceitam expressões regulares como * [0-9]](https://image.slidesharecdn.com/ltg-elasticsearchtips-160625203048/85/Elasticsearch-shards-index-filters-and-queries-57-320.jpg)
Elasticsearch shards, index, filters and queries
- 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