Apache Lucene is combining two optimizations for evaluating disjunctive queries, bringing significant speedups to top-k queries, especially with many terms and/or high-frequency terms.

elastic-blog-2-high-freq-graph.png

What is BS1?

What are MAXSCORE and WAND?

MAXSCORE meets BS1

elastic-blog-2-graph.png

enterprise-search-performing-website-dark-1680x980.png

Bringing speedups to top-k queries with many and/or high-frequency terms

Elasticsearch 8.9 introduces optimizations to cardinality aggregations by filtering out documents whose value has already been collected.

How does it work?

When does it kick in?

Conclusion

the-end-of-databases-B_(1).jpg

Achieve faster cardinality aggregations via dynamic pruning

Data ingestion involves a lot of things that usually take a non-negligible amount of time. Fortunately, we've got improvements in 8.6, 8.7, and 8.8, which enabled some good speedups for end-to-end ingestion.

elastic-blog-ingestion-speedups.png

Faster merging of kNN vectors

Optimizations to ingest pipelines

elastic-blog-total-ingest-pipline.png

Optimizations to keyword and numeric fields

Optimizations to index sorting

A new merge policy for time-based data

blog-search-results-dark-720x420.png

How we sped up data ingestion in Elasticsearch 8.6, 8.7, and 8.8

O Elasticsearch 7.7 usará muito menos memória heap do que as versões anteriores, o que melhora a estabilidade do cluster do Elasticsearch e reduz o custo do armazenamento de grandes quantidades de dados.

<p>Como os usuários do Elasticsearch estão ampliando os limites de quantos dados podem armazenar em um nó do Elasticsearch, eles às vezes ficam sem memória heap antes de ficar sem espaço em disco. Esse é um problema frustrante para esses usuários, pois costuma ser importante <a href="/pt/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster">ter o máximo de dados possível em cada nó</a> a fim de reduzir custos.
</p><p>Mas por que o Elasticsearch precisa de memória heap para armazenar dados? Por que ele não precisa apenas de espaço em disco? Existem alguns motivos, mas o principal é que o Lucene precisa armazenar algumas informações na memória para saber onde procurar no disco. Por exemplo, o índice invertido do Lucene é composto por um dicionário de termos que agrupa os termos em blocos no disco em ordem classificada e um índice de termos para pesquisa rápida no dicionário. Esse índice de termos mapeia os prefixos dos termos com o deslocamento no disco onde começa o bloco contendo os termos com esse prefixo. O dicionário de termos fica no disco, mas o índice de termos ficava no heap até recentemente.
</p><p>De quanta memória os índices precisam? Normalmente, em torno de alguns MB por GB de índice. Não é muito, mas como estamos vendo os usuários anexarem mais e mais terabytes de disco a seus nós, os índices começam rapidamente a exigir entre 10 e 20 GB de memória heap para armazenar esses terabytes de índices. Dada a recomendação da Elastic de não ultrapassar 30 GB de heap, não sobra muito para outros consumidores de memória heap, como as agregações. Além disso, aumentará a probabilidade de ocorrerem problemas de estabilidade se a JVM não tiver espaço suficiente para as operações de gerenciamento de cluster.
</p><p>Vejamos alguns números práticos. A Elastic executa <a href="https://benchmarks.elastic.co">benchmarks noturnos</a> em vários conjuntos de dados e controla várias métricas ao longo do tempo, em particular o uso de memória dos segmentos. O conjunto de dados <a href="https://www.geonames.org/">Geonames</a> é interessante porque <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/geonames/nightly/default/6M">mostra claramente o impacto de várias mudanças que aconteceram no Elasticsearch 7.x</a>:
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb41b157438550179/5ea2ddf2ae23d30cd1dfb100/heap-reduction-7-7-nightly-geonames-blog.png" data-sys-asset-uid="bltb41b157438550179" alt="Benchmarks noturnos no conjunto de dados de nomes geográficos" style="display: block; margin: auto;">
</p><p>Esse índice ocupa cerca de 3 GB no disco e costumava exigir cerca de 5,2 MB de memória há 6 meses, com uma proporção de heap:armazenamento de cerca de 1:600. Então, se você tivesse um total de 10 TB anexado a cada nó, precisaria de 10 TB/600 = 17 GB de heap, apenas para ser capaz de manter abertos os índices que armazenam dados semelhantes aos nomes geográficos. Mas, como você pode ver, tornamos as coisas melhores com o tempo: os pontos (azul-escuro) começaram a exigir menos memória, depois os termos (rosa), os campos armazenados (verde) e, finalmente, os termos novamente com uma diferença significativa. A proporção de heap:armazenamento agora é de cerca de 1:4.000, uma melhoria de quase 7x em comparação com a versão 6.x e as primeiras versões 7.x. Agora você só precisaria de 2,5 GB de memória heap para manter abertos 10 TB de índices.
</p><p>Os números variam <strong>MUITO</strong> entre os conjuntos de dados, e a boa notícia é que o Geonames é um dos conjuntos de dados que apresentou a menor redução do uso de heap: enquanto o uso de heap baixou cerca de 7x no Geonames, ele baixou mais de 100x nos conjuntos de dados <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/nyc-taxis/nightly/default/6M">NYC taxis</a> (Táxis de NYC) e <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/http-logs/nightly/default/6M">HTTP Logs</a> (Logs HTTP). Novamente, essa mudança ajudará a reduzir custos, pois muito mais dados são armazenados por nó em comparação com as versões anteriores do Elasticsearch.
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7c2002e630ac3974/5ea2de1f52608c261aab78aa/heap-reduction-7-7-nightly-taxis-blog.png" data-sys-asset-uid="blt7c2002e630ac3974" alt="Benchmarks noturnos no conjunto de dados de táxis de Nova York" style="display: block; margin: auto;">
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb15c6244ebc49571/5ea2de6952608c261aab78b0/heap-reduction-7-7-nightly-http-logs-blog.png" data-sys-asset-uid="bltb15c6244ebc49571" alt="Benchmarks noturnos no conjunto de dados de logs HTTP" style="display: block; margin: auto;">
</p><p>Como isso funciona e quais são as armadilhas? A mesma receita foi aplicada a vários componentes dos índices do Lucene ao longo do tempo: mover estruturas de dados do heap da JVM para o disco e contar com o cache do sistema de arquivos (frequentemente chamado de cache de página ou cache do sistema operacional) para manter os bits ativos na memória. Isso pode significar que essa memória ainda esteja sendo usada e esteja apenas alocada em outro lugar, mas a realidade é que uma parte significativa dessa memória simplesmente nunca foi usada, dependendo do seu caso de uso. Por exemplo, a última queda para <code>Terms</code> foi devida à movimentação do índice de termos do campo <code>_id</code> no disco, o que só é útil ao usar a API GET ou ao indexar documentos com IDs explícitos. A grande maioria dos usuários que indexam logs e métricas no Elasticsearch nunca faz nenhuma dessas operações; portanto, isso será um ganho líquido de recursos para eles.
</p><h2>Reduza o heap do seu Elasticsearch com a versão 7.7!</h2><p>Estamos muito animados com essas melhorias que estarão disponíveis no Elasticsearch 7.7 e esperamos que você também fique. Fique de olho no anúncio de lançamento que está por vir e faça o teste. Experimente na sua implantação existente ou <a href="/pt/elasticsearch/service">faça uma avaliação gratuita</a> do Elasticsearch Service no Elastic Cloud (que sempre tem a versão mais recente do Elasticsearch). Estamos ansiosos para receber seu feedback, então diga-nos o que você acha no <a href="https://discuss.elastic.co/">Discuss</a>.
</p>

blog-banner-release-elasticsearch.png

blog-thumb-release-elasticsearch.png

Coming in 7.7: Significantly decrease your Elasticsearch heap memory usage

Na versão 7.7: diminua significativamente o uso de memória heap do Elasticsearch

O Elasticsearch 7.0 deixou de usar APIs que aceitam types, introduziu novas APIs typeless e acabou com o suporte para o mapeamento _default_.

<p>Desde a versão 5.0, estamos abrindo caminho para remover os types do Elasticsearch e, com a versão 7.0, eles caíram em desuso. O objetivo dos types era oferecer a possibilidade de ser multi-tenancy dentro de um único índice, o que é incompatível com o Lucene. Infelizmente, os types acabaram causando mais problema do que qualquer outra coisa.&nbsp;Depois de longas discussões sobre o que fazer (usar campos únicos por type ou ter um índice por type), decidimos remover o recurso. Para facilitar a transição para os usuários, diluímos as alterações em 4 grandes versões:
</p><ul>
	<li>Na 5.0, campos que têm o mesmo nome em diversos types têm mapeamentos compatíveis.</li>
	<li>Na 6.0, começamos a impedir novos índices de ter mais do que um type e colocamos em desuso o mapeamento <code>_default_</code>.</li>
	<li>Na 7.0, deixamos de usar APIs que aceitam types, introduzimos novas APIs typeless e acabamos com o suporte para o mapeamento <code>_default_</code>.</li>
	<li>A versão 8.0 vai remover APIs que aceitam types.</li>
</ul><h2>APIs typeless</h2><p>Todas as APIs que aceitam types no caminho do URL, corpo da solicitação ou da resposta estão recebendo uma contraparte typeless. É o caso de algumas APIs muito comuns, como criação de índice, índice e GET. Um exemplo vale mais do que mil palavras, então veja como é uma interação com um cluster 7.0 com APIs typeless.
</p><pre class="prettyprint">PUT index
{
  "mappings": {
    "properties": { // Note how there is no top-level key with the type name
      "@timestamp": {
        "type": "date"
      }
    }
  }
}
PUT index/_doc/1 // _doc becomes the new endpoint for document index, get and delete requests
{
  "@timestamp": "2019-02-20"
}
POST index/_bulk
{"index": {"_id": "2"}} // no _type in the URL or in document metadata
{"@timestamp": "2019-03-01"}
{"update": {"_id": "1"}}
{"@timestamp": "2019-02-21"}
GET index/_doc/2
GET index/_search // unchanged, the `GET index/{type}/_search` endpoint is deprecated however
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2019-01-01"
      }
    }
  }
}
GET index/_explain/1 // note how the type does not appear in the URL anymore, this would have been "GET index/{type}/1/_explain" in 6.x
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2019-01-01"
      }
    }
  }
}
</pre><h2>O que preciso fazer?</h2><p>Algumas mudanças já estão acontecendo e vão precisar que você faça alterações em seu cluster <strong>antes</strong> de atualizar para a versão 7.0. Outras só serão necessárias no upgrade para a versão 8.0 e devem ser feitas depois da atualização para a 7.0.
</p><h3>Antes do upgrade</h3><h4>Veja se você está na versão 6.8</h4><p>Se você pretende fazer o upgrade sem tempo de inatividade, primeiro faça para a 6.8, que é a única versão 6.x a ter recursos como suporte ao parâmetro <code>include_type_name</code>, necessário para um upgrade sem problemas para a 7.0.
</p><h4>Pare de usar mapeamentos _default_</h4><p>O mapeamento <code>_default_</code> vai acabar na 7.0. Se algum índice da 6.x tiver mapeamento <code>_default_</code>, ele vai funcionar sem problemas, já que o mapeamento  <code>_default_</code> só será rejeitado nos novos índices.
</p><p>Você precisa atualizar seus modelos de índice e seu código do aplicativo para adicionar esses mapeamentos ao type atual em vez de incluí-los no mapeamento <code>_default_</code>. Se o nome do type não for importante para você, recomendamos usar <code>_doc</code>, pois isso facilitará a transição para as APIs typeless no futuro.
</p><h4>Passe <code>include_type_name=true</code> para as APIs de criação de índice, modelo e mapeamento.</h4><p>A mudança para APIs typeless significa que as APIs cujo corpo da solicitação tenha exigido um type hoje terão um formato diferente:
</p><ul>
	<li>create index</li>
	<li>put mapping</li>
	<li>put template</li>
</ul><p>enquanto outras APIs que retornavam types como resposta terão outro formato de resposta:
</p><ul>
	<li>get index</li>
	<li>get mapping</li>
	<li>get field mapping</li>
	<li>get template</li>
</ul><p>Para não se prejudicar com essa mudança, você deve fazer seu aplicativo passar <code>include_type_name=true</code> para essas chamadas API, que é um no-op na 6.x e dirá para a 7.x fazer essas APIs se comportarem como faziam na 6.x. Por exemplo, veja uma chamada de criação de índice com esse parâmetro. Funciona do mesmo jeito na 6.8 e na 7.x.
</p><pre class="prettyprint">PUT index?include_type_name=true
{
  "mappings": {
    "my_type": {
      "properties": { // Note how there is no top-level key with the type name
        "@timestamp": {
          "type": "date"
        }
      }
    }
  }
}
</pre><h3>Depois do upgrade</h3><p>Se você seguiu as etapas de pré-upgrade recomendadas, tudo deve continuar funcionando. No entanto, nesse momento, você ainda está usando APIs que aceitam types e isso gera alertas de desuso. Para evitar isso, é importante passar para as APIs typeless.
</p><p>Para APIs de modelo e mapeamentos e criação de índice, você precisará remover <code>include_type_name=true</code> dos parâmetros do URL e alterar os corpos da solicitação ou expectativas sobre o formato de resposta, que não incluem mais types. Normalmente, se o corpo da solicitação ou a resposta incluíssem mapeamentos, eles teriam uma seção assim:
</p><pre class="prettyprint">{
  "my_type": { // this key is no longer accepted in mappings as of 7.0
    "properties": ...
  }
}
</pre><pre class="prettyprint">{
  "properties": ...
}
</pre><p>Para outras APIs, como de índice, GET ou de atualização, você precisa substituir o nome do type na URL por <code>_doc</code>. Isso funcionará independentemente do nome do type no seu índice. Por exemplo, se você realizava chamadas de índice para um índice cujo nome de type fosse <code>my_type</code>, a chamada do índice era assim:
</p><pre class="prettyprint">PUT index/my_type/1
{
  "@timestamp": "2019-02-20"
}
</pre><pre class="prettyprint">PUT index/_doc/1
{
  "@timestamp": "2019-02-20"
}
</pre><h2>Saiba mais</h2><p>Se quiser saber mais sobre a remoção de types e como migrar para APIs typeless, recomendo dar uma olhada na <a href="/guide/en/elasticsearch/reference/7.0/removal-of-types.html">documentação sobre remoção de types</a>, em que falamos em mais detalhes sobre as implicações dessa mudança e como se preparar para ela.
</p><p><a href="/pt/downloads/elasticsearch">Baixe a versão 7.0.0</a>, experimente as APIs typeless e conte para nós o que achou em uma <a href="https://discuss.elastic.co/">discussão</a>.
</p>

types-typeless-banner.jpg

types-typeless-thumb.jpg

Goodbye, types. Hello, typeless.

Adeus, types. Olá, typeless.

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

headshot-adrien-grand-300x300.jpg

Tech Lead

Adrien Grand

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

O conteúdo desta página não está disponível no idioma selecionado. A Elastic está trabalhando para garantir que o conteúdo esteja disponível em vários idiomas. Agradecemos a compreensão.

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Communication Preferences - ONLY for /communication-preferences

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/elastic-cloud-account-terms" target="_self">Termos de Serviço</a> e também concorda em receber <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">comunicações especiais</a> por meio dos dados de contato que forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Serverless GDPR Text

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/serverless-preview-terms" target="_self">Termos de Serviço</a> e que a Elastic pode <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">entrar em contato com você</a> para divulgar nossos produtos e serviços relacionados usando os dados que você forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

<p>By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.</p>

Cloud Trial GDPR Text

<p>Ao enviar, você concorda com os <a href="/pt/agreements/global/cloud-services-monthly" rel="nofollow">Termos de Serviço do Elastic Cloud</a>. Seus dados pessoais serão tratados de acordo com a <a href="/pt/legal/privacy-statement">Declaração de Privacidade da Elastic</a>.
</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

<p>Ao enviar a confirmação, você reconhece que leu e concorda com nossos <a href="/pt/legal/terms-of-use" target="_self">Termos de Serviço</a> e que a Elastic pode <a href="/pt/legal/privacy-statement#how-we-use-the-information" target="_self">entrar em contato com você</a> para divulgar nossos produtos e serviços relacionados usando os dados que você forneceu acima. Consulte a <a href="/pt/legal/privacy-statement/" target="_self">Declaração de Privacidade da Elastic</a> para saber mais detalhes ou para cancelar a qualquer momento.</p>

Explore similar demos

Explore outras demonstrações semelhantes

Overview

Load More

Speakers

Close

See more insights

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

Consultar a hora de início do webinar no meu fuso horário

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

Não vai conseguir participar? Inscreva-se e nós lhe enviaremos a gravação. Você também receberá um email com conteúdo relacionado.

Author

Articles by Adrien Grand

Tech Lead, Elastic

Bringing speedups to top-k queries with many and/or high-frequency terms

Achieve faster cardinality aggregations via dynamic pruning

How we sped up data ingestion in Elasticsearch 8.6, 8.7, and 8.8

Na versão 7.7: diminua significativamente o uso de memória heap do Elasticsearch

Adeus, types. Olá, typeless.