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

Elasticsearch 7.7 wird deutlich weniger Heap-Speicher als vorherige Versionen verbrauchen, was das Elasticsearch-Cluster stabiler macht und die Kosten für das Speichern großer Datenmengen senkt.

<p>Elasticsearch-Nutzern, die darauf aus sind, auf einem Elasticsearch-Knoten möglichst viele Daten zu speichern, fehlt es am Ende häufig nicht so sehr an Datenspeicherplatz, sondern eher an Heap-Speicher. Das kann ganz schön ärgerlich sein, weil es aus Kostengründen oft wichtig ist, <a href="/de/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster">auf einem Knoten so viele Daten wie möglich unterbringen</a> zu können.
</p><p>Warum aber benötigt Elasticsearch zum Speichern von Daten überhaupt Heap-Speicher? Warum reicht nicht der Datenspeicher allein? Dafür gibt es mehrere Gründe, der Hauptgrund aber ist, dass Lucene einige Informationen im Heap-Speicher ablegen muss, um zu wissen, wo im Datenspeicher gesucht werden soll. So besteht beispielsweise der invertierte Index von Lucene aus einem Begriffswörterbuch, das Begriffe in Blöcke im Datenspeicher zusammenfasst und sie sortiert, und einem Begriffsindex zum schnellen Nachschlagen im Begriffswörterbuch. Dieser Begriffsindex ordnet Präfixe von Begriffen der Offset-Position auf dem Datenträger zu, an der der Block beginnt, der Begriffe mit diesem Präfix enthält. Das Begriffswörterbuch befindet sich auf dem Datenträger, aber der Begriffsindex war bis vor Kurzem im Heap-Speicher angesiedelt.
</p><p>Wie viel Speicher benötigen Indizes? In der Regel liegt der Speicherbedarf eines Index bei einigen wenigen MB pro GB Index. Das ist nicht viel, da aber der Speicherplatz von Knoten immer weiter terabyteweise aufgestockt wird, kann es schnell passieren, dass Indizes 10 bis 20&nbsp;GB Heap-Speicher benötigen, um diese Menge an Indexdaten zu speichern. Da Elastic empfiehlt, beim Heap-Speicher nicht über 30&nbsp;GB hinauszugehen, bleibt für andere Verbraucher des Heap-Speichers, wie z.&nbsp;B. Aggregationen, nicht mehr viel Platz, und wenn die JVM nicht genügend Platz für Cluster-Management-Operationen hat, sind Problemen mit der Stabilität Tür und Tor geöffnet.
</p><p>Sehen wir uns dazu ein paar Zahlen aus der Praxis an. Elastic führt <a href="https://benchmarks.elastic.co">über Nacht Benchmark-Tests</a> an mehreren Datensätzen durch und erfasst dabei verschiedene Metriken im Zeitverlauf, insbesondere die Arbeitsspeichernutzung der Segmente. Der Datensatz <a href="https://www.geonames.org/">Geonames</a> ist hier interessant, weil er <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/geonames/nightly/default/6M">ganz klar die Auswirkungen verschiedener Änderungen zeigt, die an Elasticsearch 7.x vorgenommen wurden</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="Nächtliche Benchmark-Tests am Datensatz „Geonames“" style="display: block; margin: auto;">
</p><p>Dieser Index nimmt ca. 3&nbsp;GB Datenspeicher in Anspruch und benötigte vor 6&nbsp;Monaten rund&nbsp;5,2 MB Heap-Speicher, was einem Verhältnis von Heap-Speicher zu Datenspeicher von rund 1&nbsp;:&nbsp;600 entspricht. Bei insgesamt 10&nbsp;TB pro Knoten würde man also allein 10&nbsp;TB&nbsp;: 600&nbsp;= 17&nbsp;GB Heap-Speicher benötigen, um nur das Speichern von Indizes offen zu halten, die „geonames“-ähnliche Daten enthalten. Wie Sie sehen, haben wir es aber im Laufe der Zeit geschafft, das zu verbessern: Punkte (dunkelblau) brauchten nach und nach weniger Arbeitsspeicher, gefolgt von Begriffen (pink), gespeicherten Feldern (grün) und ganz am Ende ist der Speicherbedarf für Begriffe noch um ein Vielfaches gesunken. Das Verhältnis von Heap- zu Datenspeicher beträgt jetzt rund 1&nbsp;:&nbsp;4000, was im Vergleich mit den 6.x- und frühen 7.x-Versionen eine Verbesserung um das fast 7-Fache bedeutet. Für das Offenhalten von Indizes mit 10&nbsp;TB reichen jetzt schon 2,5&nbsp;GB Platz im Heap-Speicher.
</p><p>Die tatsächlichen Werte sind <strong>STARK</strong> vom jeweiligen Datensatz abhängig, wobei „Geonames“ zu den Datensätzen gehört, bei denen sich die Heap-Nutzung noch am wenigsten verringert hat: Während sie bei „Geonames“ „nur“ um rund das 7-Fache gesunken ist, lag die Reduzierung bei den Datensätzen <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/nyc-taxis/nightly/default/6M">NYC Taxis</a> und <a href="https://elasticsearch-benchmarks.elastic.co/index.html#tracks/http-logs/nightly/default/6M">HTTP Logs</a> bei mehr als dem 100-Fachen! Zur Erinnerung: Diese Änderung hilft, die Kosten zu senken, denn es können deutlich mehr Daten pro Knoten als bei vorherigen Versionen von Elasticsearch gespeichert werden.
</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="Nächtliche Benchmark-Tests am Datensatz „NYC Taxis“" 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="Nächtliche Benchmark-Tests am Datensatz „HTTP Logs“" style="display: block; margin: auto;">
</p><p>Wie funktioniert das und wo sind die Haken? Genau dieses Rezept haben wir im Laufe der Zeit auf mehrere Komponenten von Lucene-Indizes angewendet: Datenstrukturen wurden aus dem JVM-Heap in den Datenspeicher verschoben und damit die „Hot Bits“ im Arbeitsspeicher bleiben können, wurde auf den Dateisystem-Cache (oft als Page-Cache, Seiten-Cache oder OS-Cache bezeichnet) zurückgegriffen. Das liest sich jetzt vielleicht so, als ob dieser Speicher immer noch genutzt wird und einfach nur anderswo zugeordnet wurde, Fakt ist aber, dass bei den meisten Anwendungsfällen ein beträchtlicher Teil dieses Speichers einfach nie genutzt wurde. Ein Beispiel ist die letzte starke Reduzierung bei <code>Terms</code> (Begriffe), die darauf zurückzuführen war, dass der Begriffsindex des Feldes <code>_id</code> auf den Datenträger verschoben wurde, was nur bei Nutzung der GET API oder beim Indexieren von Dokumenten mit expliziten IDs sinnvoll ist. Der allergrößte Teil der Nutzer, die Logdaten und Metriken nach Elasticsearch indexieren, führen derartige Operationen nie durch, sodass dies ein echter Ressourcengewinn für sie ist.
</p><h2>Mit 7.7 den Elasticsearch-Heap verkleinern</h2><p>Wir freuen uns über diese Verbesserungen in Elasticsearch 7.7 und hoffen, dass es Ihnen genauso geht. Halten Sie nach der anstehenden Versionsveröffentlichung Ausschau und überzeugen Sie sich dann selbst. Probieren Sie die Neuerung in Ihrem vorhandenen Deployment aus oder <a href="/de/elasticsearch/service">nutzen Sie unser Angebot eines kostenlosen Probeabonnements</a> von Elasticsearch Service auf Elastic Cloud (wo Sie stets Zugriff auf die neueste Version von Elasticsearch haben). Wie immer freuen wir uns über Ihr Feedback. Lassen Sie uns daher auf <a href="https://discuss.elastic.co/">Discuss</a> wissen, was Sie darüber denken.
</p>

blog-banner-release-elasticsearch.png

blog-thumb-release-elasticsearch.png

Coming in 7.7: Significantly decrease your Elasticsearch heap memory usage

Neu in 7.7: Deutliche Reduzierung der Nutzung des Elasticsearch-Heap-Speichers

Mit Elasticsearch 7.0 gelten typisierte APIs als veraltet. Stattdessen wurden neue typenlose APIs eingeführt und das Mapping „_default_“ wird nicht mehr

<p>In Version&nbsp;5.0 haben wir begonnen, die Voraussetzungen für ein Ende der Typen in Elasticsearch zu schaffen. Mit Version&nbsp;7.0 gehören Typen nun der Vergangenheit an. Typen waren darauf ausgelegt, mehrere Mandanten innerhalb eines einzelnen Index bereitzustellen. Dies ist jedoch nicht mit Lucene kompatibel. Leider verursachten Typen häufig mehr Probleme als sie lösten.&nbsp;Nach langen Diskussionen darüber, ob wir dieses Problem umgehen sollten (z.&nbsp;B. durch Verwendung einzigartiger Felder pro Typ oder eines Index pro Typ), entschlossen wir uns, stattdessen Typen nicht mehr zu unterstützen. Wir führten die Änderungen schrittweise über vier Hauptversionen ein, um unseren Anwendern die Umstellung zu erleichtern:
</p>
<ul>
	<li>Ab Version&nbsp;5.0 müssen Felder, die den gleichen Namen für mehrere Typen verwenden, kompatible Mappings aufweisen.</li>
	<li>Ab Version&nbsp;6.0 wird verhindert, dass Indizes mehr als einen Typ aufweisen. Zudem gilt das Mapping <code>_default_</code> ab dieser Version als veraltet.</li>
	<li>Ab Version&nbsp;7.0 gelten typisierte APIs als veraltet. Stattdessen wurden neue typenlose APIs eingeführt und das Mapping <code>_default_</code> wird nicht mehr unterstützt.</li>
	<li>In Version&nbsp;8.0 werden APIs, die Typen unterstützen, entfernt.</li>
</ul>
<h2>Typenlose APIs</h2>
<p>Alle APIs, die Typen im URL-Pfad, Anforderungstext oder Antworttext akzeptieren, erhalten eine neue typenlose Entsprechung. Dies ist für einige gängige APIs der Fall, wie z.&nbsp;B. „index creation“, „index“ und „GET“. Das folgende Beispiel veranschaulicht eine Interaktion mit einem Cluster der Version&nbsp;7.0 mit typenlosen APIs:
</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>Erforderliche Vorgehensweise</h2>
<p>Einige Änderungen sind so grundlegend, dass Sie Ihr Cluster <strong>vor</strong> dem Upgrade auf Version&nbsp;7.0 entsprechend bearbeiten müssen. Andere Änderungen sind erst für das Upgrade auf Version&nbsp;8.0 erforderlich und sollten nach dem Upgrade auf Version&nbsp;7.0 durchgeführt werden.
</p>
<h3>Vor dem Upgrade</h3>
<h4>Version&nbsp;6.8 muss installiert sein</h4>
<p>Falls Sie ein schrittweises Upgrade ohne Ausfallzeit planen, sollten Sie zunächst ein Upgrade auf Version&nbsp;6.8 durchführen. Dies ist das einzige Release der Version&nbsp;6.x, das einige für das reibungslose Upgrade auf Version&nbsp;7.0 erforderliche Funktionen enthält, wie beispielsweise die Unterstützung des Parameters <code>include_type_name</code>.
</p>
<h4>Vermeiden Sie das Mapping „_default_“</h4>
<p>Die Unterstützung des Mappings <code>_default_</code> wird ab Version&nbsp;7.0 schrittweise eingestellt. Die&nbsp;Verwendung des Mappings <code>_default_</code> in einigen vorhandenen Indizes der Version 6.x stellt kein Problem dar, da das Mapping <code>_default_</code> lediglich für neue Indizes abgelehnt wird.
</p>
<p>Aktualisieren Sie Ihre Indexvorlagen und Ihren Anwendungscode, um diese Mappings dem eigentlichen Typ hinzuzufügen, statt sie in das Mapping <code>_default_</code> zu integrieren. Wenn der Name des Typs nicht wirklich wichtig für Sie ist, sollten Sie <code>_doc</code> verwenden. Dies erleichtert Ihnen in Zukunft den Übergang zu typenlosen APIs.
</p>
<h4>Übergeben Sie <code>include_type_name=true</code> an die APIs „index creation“, „template“ und „mappings“</h4>
<p>Der Wechsel zu typenlosen APIs bedeutet, dass APIs, für deren Anforderungstext ein Typ erforderlich ist, nun ein anderes Format erwarten:
</p>
<ul>
	<li>create index</li>
	<li>put mapping</li>
	<li>put template</li>
</ul>
<p>Andere APIs, bei denen Typen in der Antwort zurückgegeben wurden, weisen hingegen nun ein anderes Antwortformat auf:
</p>
<ul>
	<li>get index</li>
	<li>get mapping</li>
	<li>get field mapping</li>
	<li>get template</li>
</ul>
<p>Damit Sie diese Änderungen unbeschadet überstehen, sollten Sie dafür sorgen, dass Ihre Anwendung <code>include_type_name=true</code> an diese API-Aufrufe übergibt. Dies ist eine No-op in Version&nbsp;6.x und weist Version&nbsp;7.x an, das Verhalten dieser APIs so zu gestalten, wie dies in Version&nbsp;6.x der Fall war. Das folgende Beispiel zeigt einen Aufruf zur Indexerstellung mit diesen Parametern. Die Funktionsweise ist in Version&nbsp;6.8 und Version&nbsp;7.x identisch.
</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>Nach dem Upgrade</h3>
<p>Wenn Sie vor dem Upgrade die empfohlenen Schritte ausgeführt haben, sollte alles weiterhin reibungslos funktionieren. In dieser Phase verwenden Sie jedoch immer noch APIs, die Typen akzeptieren, und dies löst Warnungen zu veraltetem Code aus. Migrieren Sie zu typenlosen APIs, um diese Warnungen zu vermeiden.
</p>
<p>Für die APIs „index creation“, „template“ und „mappings“ müssen Sie <code>include_type_name=true</code> aus den URL-Parametern entfernen und den Anforderungstext oder die Erwartungen hinsichtlich des Antwortformats, das keine Typen mehr enthält, ändern. Falls der Anforderungstext oder die Antwort Mappings enthielt, sah einer der Abschnitte in der Regel wie folgt aus:
</p>
<pre class="prettyprint">{
  "my_type": { // this key is no longer accepted in mappings as of 7.0
    "properties": ...
  }
}
</pre>
<p>Der Typname muss hier entfernt werden. Die aktualisierte Version würde wie folgt aussehen:
</p>
<pre class="prettyprint">{
  "properties": ...
}
</pre>
<p>Für andere APIs wie „index“, „GET“ oder „update“ muss der Typname in der URL durch <code>_doc</code> ersetzt werden. Dies funktioniert unabhängig vom Namen des Typs in Ihrem Index. Falls Sie beispielsweise zuvor Indexaufrufe für einen Index mit dem Typnamen <code>my_type</code> durchgeführt haben, hätte der Indexaufruf wie folgt ausgesehen:
</p>
<pre class="prettyprint">PUT index/my_type/1
{
  "@timestamp": "2019-02-20"
}
</pre>
<p>Dieser Indexaufruf sollte nun wie folgt ersetzt werden:
</p>
<pre class="prettyprint">PUT index/_doc/1
{
  "@timestamp": "2019-02-20"
}
</pre>
<h2>Weitere Informationen</h2>
<p>Wenn Sie mehr über das Entfernen von Typen und die Vorgehensweise zur Migration zu typenlosen APIs erfahren möchten, schauen Sie sich unsere Dokumentation zum <a href="/guide/en/elasticsearch/reference/7.0/removal-of-types.html">Entfernen von Typen</a> an, in der wir die Auswirkungen dieser Änderungen und die Vorbereitungen für diese Änderungen ausführlicher erläutern.
</p>
<p><a href="/de/downloads/elasticsearch">Laden Sie Version&nbsp;7.0.0 herunter</a>, probieren Sie diese neuen typenlosen APIs aus und geben Sie uns dann auf <a href="https://discuss.elastic.co/">Discuss</a> Feedback hierzu.
</p>

types-typeless-banner.jpg

types-typeless-thumb.jpg

Goodbye, types. Hello, typeless.

Von typisierten zu typenlosen APIs

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

headshot-adrien-grand-300x300.jpg

Tech Lead

Adrien Grand

<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>Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/elastic-cloud-account-terms" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">ausgewählte Nachrichten und Informationen</a> an die oben von Ihnen bereitgestellten Kontaktangaben zu senden. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.</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>Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/serverless-preview-terms" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, bezüglich unserer zugehörigen Produkte und Dienstleistungen und unter Nutzung der von Ihnen oben bereitgestellten Kontaktangaben <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">mit Ihnen in Kontakt zu treten</a>. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.</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>Beim Absenden akzeptieren Sie die <a href="/de/agreements/global/cloud-services-monthly" rel="nofollow">Nutzungsbedingungen von Elastic Cloud</a>. Die Verarbeitung Ihrer personenbezogenen Daten unterliegt der <a href="/de/legal/privacy-statement">Datenschutzerklärung von 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>Durch das Absenden erklären Sie, dass Sie unsere <a href="/de/legal/terms-of-use" target="_self">Nutzungsbedingungen</a> gelesen haben und mit ihnen einverstanden sind und dass Sie Elastic erlauben, bezüglich unserer zugehörigen Produkte und Dienstleistungen und unter Nutzung der von Ihnen oben bereitgestellten Kontaktangaben <a href="/de/legal/privacy-statement#how-we-use-the-information" target="_self">mit Ihnen in Kontakt zu treten</a>. Weitere Informationen, darunter auch dazu, wie Sie Ihre Einwilligung zurückziehen können, finden Sie in der <a href="/de/legal/privacy-statement/" target="_self">Datenschutzerklärung von Elastic</a>.</p>

Explore similar demos

Overview

Speakers

Close

See more insights

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.

Der Inhalt dieser Seite ist in der ausgewählten Sprache nicht verfügbar. Wir bei Elastic arbeiten daran, die bereitgestellten Inhalte in verschiedenen Sprachen anzubieten. Bis dahin bitten wir Sie um etwas Geduld und hoffen auf Ihr Verständnis!

Author

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Articles by

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

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

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

Sie können nicht dabei sein? Registrieren Sie sich, damit wir Ihnen die Aufzeichnung zukommen lassen können. Außerdem erhalten Sie eine E‑Mail mit Begleitmaterial.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Learn More

Read less

You'll also receive an email with related content

Wir schicken Ihnen zudem relevante Informationen, die von Interesse sein könnten.

Thank you for registering. We will send you a confirmation email soon.

Vielen Dank für Ihre Registrierung. Sie erhalten in Kürze eine Bestätigungs-E‑Mail von uns.

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

Neu in 7.7: Deutliche Reduzierung der Nutzung des Elasticsearch-Heap-Speichers

Von typisierten zu typenlosen APIs