Elasticsearch 5.0.0 GA veröffentlicht

Der Indizierungsdurchsatz hat sich bei Version 5.0.0 drastisch verbessert, was einer Reihe von Änderungen zu verdanken ist: verbesserte nummerische Datenstrukturen (siehe Neue Datenstrukturen), weniger Konflikte beim Locking um gleichzeitige Aktualisierungen ein und desselben Dokuments zu verhindern und eine Reduzierung des Lockings beim Fsyncen des Transaktionslogs. Asynchrones Translog-Fsyncing kommt besonders Benutzern von rotierenden Festplatten zugute. Auch der Anwendungsfall Append-Only (beispielsweise bei Zeitserien) hat eine große Durchsatzverbesserung beim automatischen Generieren von Dokument-IDs unter Elasticsearch erfahren. Eine interne Änderung wie Document-GET-Anfragen in Echtzeit unterstützt werden hat mehr Speicherplatz für die Indizierungspuffer verfügbar gemacht und es geht weniger Zeit bei der Garbage Collection verloren.

Je nach Anwendungsfall dürftest du eine Steigerung des Indizierungsdurchsatzes zwischen 25 und 80 Prozent beobachten.

Deine Daten in Elasticsearch zu bekommen, haben wir ein ganzes Stück einfacher gemacht. Logstash ist ein leistungsstarkes Werkzeug, doch viele kleinere Anwender brauchen nur die dort bereitstehenden Filter ohne die vielfältigen Routingoptionen. Wir haben die beliebtesten Logstash-Filter wie grok, split, convert und date einfach direkt als Prozessoren in Elasticsearch integriert. Mehrere Prozessoren werden in einer Pipeline kombiniert, welche sich beim Indizieren über die Index-API oder die Bulk-API auf die Dokumente anwenden lassen.

Nun genügt zum Aufbereiten von Log-Nachrichten ganz einfach das Konfigurieren einer Pipeline mit der Ingest-API und das Einrichten von Filebeat für das Weiterleiten einer Log-Datei an Elasticsearch. Du kannst sogar getrennte Ingest-Knoten einsetzen, um die Aufgaben des Auslesens und Anreicherns von Suche, Aggregationen und Indizierung zu trennen. Nähere Informationen unter Eine neue Art der Datenaufnahme – Teil 1.

Skripte sind bei Elasticsearch allgegenwärtig und es war sehr frustrierend, dass man ihre Erstellung aus Sicherheitsgründen nicht einfach als Voreinstellung aktivieren konnte. Nun können wir mit Begeisterung bekanntgeben, dass wir eine neue Skriptsprache mit dem Namen Painless entwickelt haben, die schnell, sicher, stabil und standardmäßig aktiviert ist. Und das ist noch nicht alles: Painless ist jetzt bereits viermal so schnell wie Groovy – und wird noch schneller werden. Uns gefällt Painless so gut, dass wir sie zur neuen voreingestellten Skriptsprache gemacht und Groovy, Javascript und Python deprecated haben.

Mehr Informationen zu Painless findest du im Blog Painless: eine neue Skriptsprache.

Lucene 6 brachte die neue Datenstruktur Points für nummerische Felder und Block-K-D-Bäume für Geo-Point-Felder. Diese Datenstruktur hat die Art und Weise des Indizierens und Suchens numerischer Werte revolutioniert. Unsere Benchmarks weisen für Points eine um 36% schnellere Abfragezeit, eine um 71% schnellere Indizierungszeit aus und benötigen 66% weniger Festplattenspeicher sowie 85% weniger Hauptspeicher (siehe Searching numb3rs in 5.0). Dank Points kann das Feld ip jetzt IPv6 ebenso wie IPv4-Adressen. unterstützen. Obendrein haben wir noch das Feldgeo_point so geändert, dass es das neue LatLonPoint von Lucene benutzt, was die Performance von Geo-Point-Anfragen verdoppelt.

Außerdem haben wir den Feldtyp half_float für Gleitkommazahlen mittlerer Präzision (16 Bit) hinzugenommen. Zusätzlich gibt es einen Feldtyp scaled_float, der intern als Feld des Typs long implementiert wird und dadurch die für Longs verwendeten Kompressionstechniken nutzen kann.

Analyzed und not-analyzed Strings wurden durch text für die Volltextsuche und keyword für die Suche nach Identifiern, das Sortieren sowie Aggregationen ersetzt. Siehe Die Strings sind tot, langes Leben für die Strings!

Und schließlich sind die Punkte in Feldnamen zurück, doch diesmal korrekt sortiert: Ein Feld mit Punkt wie foo.bar ist äquivalent zu einem Feld mit Bindestrich oder bar und einem Objektfeld foo. Wer von euch wegen der fehlenden Unterstützung von Punkten in Feldnamen nicht von der Version 1.7 auf 2.x aktualisieren konnte, konsultiert bitte Elasticsearch 2.4.0 wo ein Migrationspfad zur Verfügung gestellt wird.

Diese Kibana-Diagramme, die eine Metrik für den Vortag, den Vormonat oder das zurückliegende Jahr grafisch darstellen, bekommen mit Instant Aggregations einen echten Temposchub. Die meisten der von diesen Diagrammen benutzten Daten kommen aus Indizes, die nicht länger aktualisiert werden; trotzdem musste Elasticsearch die Aggregation für jede Anfrage von Grund auf neu berechnen, denn es war nicht möglich, die erforderliche Zeitspanne zu puffern, etwa { "gte": "now-30d", "lte": "now" }. Nach einjährigem Refactoring an der Search-API ist Elasticsearch nun viel klüger, wenn ein Zeitraum abfragt wird: Jetzt wird die Aggregation nur noch für Indizes neu berechnet, die sich geändert haben.

Darüber hinaus gibt es bei den Aggregationen noch weitere Verbesserungen: Histogramm-Aggregationen unterstützen jetzt gestückelte Buckets und behandeln die Rundung negativer Buckets korrekt. Außerdem können Begriffs-Aggregationen effizienter berechnet werden, um das Risiko einer kombinatorischen Explosion zu reduzieren, und Aggregationen werden zudem von der Profiler API unterstützt.

Der Completion Suggester wurde komplett neu programmiert, um auch gelöschte Dokumente zu berücksichtigen, und nun gibt die Funktion ganze Dokumente statt nur Nutzdaten aus. Die Kontexte sind flexibler und es können Empfehlungen für einen konkreten Kontext, viele oder alle Kontexte abgefragt werden. Empfehlungen lassen sich nicht nur beim Indizieren gewichten, vielmehr lassen sich die Bewertungen auf der Grundlage von Präfixlänge, Kontext oder Ort anpassen.

Der Percolator wurde ebenfalls neu programmiert, um ihn schneller und speichereffizienter zu machen. Die Begriffe in Percolator-Anfragen sind nun so indiziert, dass nur die Anfragen geprüft werden müssen, die möglicherweise zutreffen; was den Brute-Force-Ansatz der früheren Version ersetzt. Die Percolator-API wurde durch die percolate-Anfrage ersetzt, die alle Funktionen der Such-API für die Percolation öffnet: Highlighting (Hervorheben), Scoring (Bewertung), Pagination (Nummerierung) usw.

Ein wichtiges Anliegen der Version 5.0.0 war es, Elasticsearch sicherer und einfacher in der Anwendung zu machen. Deshalb haben wir unserem Ansatz das Motto gegeben: „Shout loud, shout early“. Denn wenn etwas nicht stimmt, informieren wir euch lieber sofort, anstatt euch im Dunkeln zu lassen und das potentielle Risiko von Datenverlust einzugehen. Ein Beispiel für die Wirksamkeit dieses Ansatzes sind die Verbesserungen an den Einstellungen für Index und Cluster.

Einstellungen werden nun streng validiert. Wenn Elasticsearch den Wert einer Einstellung nicht versteht, beschwert sich das System. Wenn es eine Einstellung nicht erkennt, beschwert es sich auch und obendrein liefert es dir Vorschläge, was du stattdessen gemeint haben könntest. Und nicht nur das: Cluster- und Indexeinstellungen können nun zurückgesetzt werden (mit null), und du kannst dir die Voreinstellungen ansehen, indem du den Parameter include_defaults angibst. Ähnlich werden die Parameter von Body- und Query-String streng geparst, wobei ungültige oder nicht erkannte Parameter als Exception behandelt werden.

Die APIs Rollover und Shrink ermöglichen ganz neue Ansätze für das effiziente Management zeitbasierter Indizes: die Verwendung mehrerer Shards, die während der Indizierung das Maximum aus deiner Hardware herausholen, um danach die Indizes auf einen einzelnen Shard zu reduzieren (oder einige wenige Shards), um Speicherung und Suche effizienter zu gestalten.

Auch an der Indexverwaltung wurden mehrere Verbesserungen vorgenommen. Das Erstellen eines Indizes ist jetzt einfacher als vorher: Anstatt auf wait_for_status=green warten zu müssen, endet der Request zur Indexerstellung erst dann, wenn der Index einsatzbereit ist. Bei einem neu angelegten Index wird der Cluster jetzt nicht mehr red, so dass Systemadministratoren nachts in Ruhe schlafen können.

Wenn bei der Shard-Allocation doch etwas schiefgeht, versucht Elasticsearch jetzt nicht mehr, den Shard endlos lange zuzuweisen (und dabei die Logs zu füllen). Stattdessen gibt Elasticsearch nun nach fünf Versuchen auf und wartet, bis du wiederkommst und das Problem behebst. Für die Beseitigung des Problems ist die neue Cluster-Allocation-Explain-API ein essentielles Werkzeug, das herausfindet, warum ein Shard nicht zugewiesen wird.

Und schließlich ist das Deprecation-Logging nun standardmäßig aktiviert, um dich zu warnen, wenn du eine Funktion benutzt, die als deprecated markiert wurde. Dadurch sollte der Wechsel zu neuen Major-Versionen deutlich weniger stressig werden.

In diese Version wurden zahlreiche Änderungen aufgenommen, um Elasticsearch noch sicherer zu machen. Jeder Teil des verteilten Systems wurde untersucht, refactored, vereinfacht und zuverlässiger gemacht. Aktualisierungen des Clusterstatus brauchen nun die Zustimmung von allen Knoten des Clusters. Wenn ein replizierter Shard vom Primary Shard als ausgefallen markiert wird, wartet der primäre Shard nun auf die Antwort vom Master. Indizes verwenden nun zur Vermeidung von Namenskonflikten ihre UUID anstelle des Indexnamens im Datenpfad.

Dein System muss korrekt konfiguriert sein (etwa müssen ausreichend viele Dateideskriptoren verfügbar sein), da du dich sonst dem Risiko eines späteren Datenverlusts aussetzt. Elasticsearch nimmt nun Bootstrap-Checks vor und gewährleistet so, dass dich später keine unangenehmen Überraschungen erwarten. Doch die richtige Systemkonfigurierung kann schwierig sein, besonders wenn du einfach nur auf deinem Laptop herumprobierst. Deshalb startet Elasticsearch, wenn es nur auf Localhost verfügbar ist, im weniger strengen Entwicklermodus, der dich warnt, wenn die Konfiguration nicht stimmt. Sobald die Netzwerkkonfiguration das Bilden eines Cluster erlauben würde, schaltet es in den Produktionsmodus, der alle Systemprüfungen aktiviert. Siehe dazu Bootstrap-Checks: Heute etwas nerven ist besser als verheerende Auswirkungen morgen!

Wir haben einen Circuit-Breaker hinzugefügt, welcher den Speicherplatz begrenzt, der bei laufenden Anfragen benutzt werden kann. Außerdem haben wir den Request-Circuit-Breaker erweitert, um den Hauptspeicher-Verbrauch von Aggregations-Buckets zu überwachen und Anfragen abzubrechen, die Unmengen von Buckets anfordern. Obwohl eine Out-of-Memory-Exception viel weniger wahrscheinlich ist als zuvor, stirbt der Knoten im Fall des Falles nun würdevoll, anstatt in einem undefinierten Zustand dahinzusiechen.

Wir haben für Systemadministratoren zahlreiche Softlimits hinzugefügt, um deinen Cluster vor böswilligen Benutzern zu schützen und unbedarfte Anwender zu warnen, wenn sie gefährliche Befehle ausführen. Einige Beispiele: voreingestellte Such-Timeouts, deaktiviertes Laden von Fielddata bei Text-Felder, begrenzte Shard-Anzahl, die eine Suchanfrage ansteuern kann, begrenzte Anzahl an Feldern in einem Mapping usw.

Nach Jahren des Wartens haben wir endlich einen Low-Level HTTP-/REST-Client für Java herausgegeben. Er gibt euch einen einfachen HTTP-Client mit minimalen Abhängigkeiten an die Hand, der Funktionen wie Sniffing, Logging, das Verteilen von Anfragen per Round-Robin und Retries nach Knotenfehlern unterstützt. Er verwendet die REST-Schnittstelle, die stets viel stabiler als die Java-API war. Damit lässt sich der Client auch nach Aktualisierungen verwenden, möglicherweise sogar nach dem Upgrade auf eine neue Major-Version. Er funktioniert mit Java 7 und hat minimale Abhängigkeiten, wodurch weniger Dependency-Konflikte als beim Transport-Client entstehen. Er verwendet durchgehend HTTP und kann dementsprechend wie alle anderen HTTP-Clients mit Firewalls und Proxies umgehen. In unseren Benchmarks erzielt der REST-Client für Java eine ähnliche Leistung wie der Transport-Client.

Nicht vergessen: Es handelt sich um einen Low-Level Client. Auf dieser Ebene stellen wir keine Query Builder oder Hilfsprogramme zur Verfügung, die eine Autovervollständigung in deiner IDE ermöglichen. Es gilt das Prinzip JSON-in, JSON-out und wie du das JSON-Format aufbaust, ist deine Sache. Die Entwicklung ist hier jedoch noch nicht beendet. So werden wir zum Beispiel eine API hinzufügen, die dir beim Erstellen von Anfragen und Parsen von Antworten helfen wird. Die Änderungen kannst du im Issue #19055 mitverfolgen.

Der Elasticsearch Migration Helper wurde als Website-Plugin entwickelt, um dir bei der Vorbereitung deiner Migration von Elasticsearch 2.3.x/2.4.x nach Elasticsearch 5.0 zu helfen. Er enthält drei Werkzeuge:

Anleitung zum Installieren des Elasticsearch-Migrationshelfers. 

Für Anleitungen zur direkten Umstellung von Elasticsearch 1.x siehe die Upgrade-Dokumente.

Bitte lade Elasticsearch 5.0.0 herunter, teste die Version und lass uns deine Meinung auf Twitter (@elastic) oder in unserem forum wissen. Jegliche Probleme kannst du als GitHub-Issue melden.