Die Such-Engine startet durch

Elasticsearch 1.2: Was ist neu?

Valentin Zacharias
© shutterstock.com/Africa Studio

Elasticsearch ist in letzter Zeit geradezu kometenhaft aufgestiegen. Die Such-Engine hat sich zu einer der prominentesten Lösungen für die Suche in Textdaten und allgemein für die Echtzeit-Analyse von semistrukturierten Daten (wie insbesondere Logs) entwickelt. In Java geschrieben und auf Lucene aufbauend, überzeugt die Technologie besonders durch die Kombination aus einfacher Nutzung, Flexibilität und Skalierbarkeit. 

In großen Installationen bei beispielsweise GitHub, Xing und Soundcloud hat Elasticsearch schon lange seine Praxistauglichkeit bewiesen. Seit Ende Mai gibt es nun mit Elasticsearch 1.2 (und seit einigen Tagen 1.2.1) eine neue Version mit vielen Verbesserungen, die hier kurz vorgestellt werden sollen: angefangen bei neuer Funktionalität über Änderungen, die in erster Linie die Geschwindigkeit betreffen, bis schließlich zu einer kurzen Übersicht weiterer Änderungen, die zu Kompatibilitätsproblemen mit früheren Versionen führen können.

Neues Feature: Context Suggestor

Eine der spannendsten Neuerungen ist der Context Suggestor, eine Erweiterung des Completion Suggestors, der oft für die Realisierung der Autovervollständigung von Suchanfragen verwendet wird. Eine Einschränkung war allerdings bisher, dass hier keine Filter oder ähnliches verwendet werden konnten (da er mit einem separaten In-memory-Index realisiert, der viele der ansonsten in Elasticsearch vorhandenen Features nicht unterstützt). 

Mit dem neuen Context Suggestor ändert sich das: Es wird möglich, einen Kontext für die Autovervollständigung zu nutzen, der die in der Autovervollständigung vorgeschlagenen Begriffe einschränkt. So können jetzt einfach nur Vorschläge aus der Nähe des Aufenthaltsorts des Nutzers oder nur solche aus der Kategorie, in der er gerade stöbert, generiert werden. Es werden zwei Arten von Kontexten unterstützt:

  • Category Context: Hier wird/werden jedem Dokument bei der Indizierung eine (oder mehrere) Kategorie(n) zugewiesen. Zusätzlich kann ein Default für Dokumente ohne das entsprechende Feld definiert werden. Bei der Anfrage zur Vervollständigung werden dann nur die Dokumente zurückgegeben, die mindestens eine Kategorie mit der Query gemein haben.
  • Geo Location Context: Dieser Kontext erlaubt es, Ergebnisse auf Orte einzuschränken. Hier sind jedem Dokument beliebig viele Orte zugeordnet, und ein Dokument wird nur zurückgegeben, wenn es in der Nähe eines bei der Query angegebenen Ortes liegt. Der Teufel steckt hier allerdings im Detail bzw. in der Definition von Nähe. Tatsächlich wird jeder Ort einem Quadrat zugeordnet (die Größe der verwendeten Quadrate kann dabei über den Parameter precision konfiguriert werden). Ein Treffer ist es, wenn Anfrage und Dokument mindestens einem identischen Quadrat zugeordnet sind. Da dies bedeutet, dass rein zufällig auch nur einen Meter entfernte Orte in unterschiedlichen Quadraten landen können, werden per Default auch Matches aus den benachbarten Quadraten berücksichtigt.

Neues Feature: Reverse Nested Aggregator

Der Reverse Nested Aggregator ist eine spezielle Aggregation, mit der es möglich ist, Aggregationen über das Root-Dokument oder andere Dokumente „über“ dem aktuellen zu machen. Am besten kann man das anhand des Beispiels aus der Elasticsearch-Dokumentation verstehen. Gegeben ist ein Ticketsystem mit Kommentaren, die als Teil der Dokumente gespeichert werden. Ein Mapping hierfür könnte die folgende Struktur haben:  

"issue" : {
        "properties" : {
            "tags" : { "type" : "string" }
            "comments" : { 
                "type" : "nested"
                "properties" : {
                    "username" : { "type" : "string", "index" : "not_analyzed" },
                    "comment" : { "type" : "string" }
                }
            }
        }
    }

Das unten stehende Codebeispiel zeigt nun, wie man darauf Aggregations so definieren kann, dass die Top-Usernames für jeden Kommentar berechnet werden (mit einer normalen Bucket Aggregation) und weiterhin für jeden dabei betrachteten User die Tags der Issues, zu denen dieser User sonst kommentiert hat, geliefert werden. Diese zweite Angabe – die aus dem Kontext der Anfrage „ausbricht“ und alle Kommentare des Nutzers betrachtet, ist erst durch den Reverse Nested Aggregator möglich geworden.   

{
    "query" : {
        "match" : { "name" : "led tv" }
    }
    "aggs" : {
        "comments" : {
            "nested" : {
                "path" : "comments"
            },
            "aggs" : {
                "top_usernames" : {
                    "terms" : {
                        "field" : "comments.username"
                    }
                },
                "aggs" : {
                    "comment_to_issue" : {
                        "reverse_nested" : { 
                        },
                        "aggs" : {
                            "top_tags_per_comment" : {
                                "terms" : { "field" : "tags" }
                            }
                        }
                    }
                }
            }
        }
    }
}

Der entscheidende (und neue) Teil ist die zweite Aggregation comment_to_issue. Durch diese Aggregation wird ein Join zurück auf das Root-Dokument gemacht (das ist das Default-Verhalten, es kann aber auch ein Pfad angegeben werden) und darin dann eine normale Bucket Aggregation gemacht, um die Top-Tags zu berechnen.

Neues Feature: Field Value Factor

Ein häufig über Skripte realisiertes Verhalten ist, einzelne Dokumente über ein Feld wie Popularität zu boosten, d. h. im Suchergebnis höher zu gewichten. Um diese Möglichkeit sichtbarer und einfacher nutzbar zu machen, so dass sie auch ohne Dynamic Scripting funktioniert, wurde hierfür eine bequemere Syntax eingefügt. Die Gewichtung über die Popularität lässt sich nun wie folgt realisieren:  

"field_value_factor": {
    "field":    "popularity",
    "factor":   1.2,
    "modifier": "sqrt"
}

[ header = Andere neue Features ]

Andere neue Features

Drei weitere neue Features wollen wir hier noch kurz nennen:

  • Significant Terms mit Custom Background Sets: bei Significant Terms Aggregations ist es jetzt möglich, die Vergleichsmenge (die für die Identifikation von Signifikanz herangezogen wird) auch zu filtern. 
  • Histogram und Date Histogram mit definierten Start- und Endpunkten: Bisher haben die Histogramm-Funktionen leere Mengen (Buckets) am Anfang und Ende weggelassen – erstellte man also z. B. ein Histogramm für die Verteilung von Zugriffen über die Tage einer Woche, und hatte man ein gerade erst hinzugefügtes Dokument, dann hatte das zugehörige Histogramm auch nur eine Menge – die für den heutigen Tag. Da dies oft zu Verwirrung führte, kann man nun die Histogramme „zwingen“, bei bestimmten Werten zu beginnen und zu enden und im Zweifel auch entsprechend leere Mengen zu generieren.
  • ScrollScroll ist ein neuer Suchtyp der es erlaubt, auch sehr große Dokumentmengen effektiv sortiert zu durchlaufen (Vergleichbares gab es bisher nur mit scan-scroll – dort war aber die Reihenfolge der Dokumente zufällig). 

Geschwindigkeitsverbesserungen

Mit Elasticsearch 1.2 gibt es Geschwindigkeitsverbesserungen, besonders in zwei Gebieten – bei IO-Operationen in der Indexverarbeitung und bei Aggregations. Bei Aggregations wurden vielfältige Verbesserungen umgesetzt, um die Speichernutzung zu senken und die Geschwindigkeit zu erhöhen. Besonders große Verbesserungen gibt es laut Elasticsearch bei den Aggregations Terms, Significant Terms und hierarchischen Aggregationen. Zusätzlich gibt es neue Sicherheitsmechanismen, die verhindern sollen, dass besonders anspruchsvolle Queries den ganzen Cluster lahmlegen (allerdings ist dieser Aggregations Circuit Breaker aufgrund von unerwünschten Nebenwirkungen in der jetzt aktuellen Version 1.2.1 erst mal wieder deaktiviert).

Die Verbesserungen bei der Indexverarbeitung adressieren das Zusammenspiel des eigentlichen Indexschrittes und den des Mergens (also des Zusammenfügens der unterschiedlichen Indexdateien, die beim Indexieren generiert werden). Die Herausforderung hier ist, dass ein großer Merge einen Knoten so belasten kann, dass die Suche darunter leidet. Nutzt man aber eine harte Obergrenze für die Nutzung von IO-Bandbreite durch Merge-Operationen, so kann es auf der anderen Seite dazu kommen, dass bei vielen zu indexierenden Dokumenten die Anzahl der Indexdateien immer weiter steigt und dadurch wiederum die Suchleistung sinkt. Um dieses Zusammenspiel zu optimieren, wurden viele Verbesserungen durchgeführt. Besonders bemerkenswert sind die folgenden: Erstens ist es nun möglich, die entsprechenden Einstellungen (wie die maximale Anzahl der gleichzeitig zu mergenden Index-Segmente) dynamisch anzupassen. Auch automatisches Verzögern von Index-Updates, wenn aktuell zu viele Merges laufen, ist möglich – eine Funktion, mit der eine gewissen Selbstheilung des Clusters erreicht und eine Überlastung verhindert wird.

Inkompatibilitäten mit vorherigen Versionen

Elasticsearch ist an ein paar Stellen inkompatibel mit vorherigen Versionen. Die wichtigsten vier, die jeder Umsteiger kennen sollte, sind: 

Java 7: Mit Elasticsearch 1.2. wird Java 6 nicht mehr unterstützt.

Dynamic Scripting per Default aus: Da dynamische Skripte in Elasticsearch ein potentielles Sicherheitsrisiko darstellen (im Endeffekt kann ein als Teil einer Query spezifiziertes Script alles, was auch der Nutzer kann der den Elasticsearch-Prozess ausführt), ist die Ausführung von dynamischen Skripten in 1.2 per Default ausgeschaltet.

Caches: Änderungen an den Caches können dazu führen, dass gewisse Queries mit der neuen Version nicht mehr funktionieren (besonders Nutzer von Logstash sollten hiermit rechnen). Diese Probleme lassen sich jedoch durch das Löschen der Caches oder das Umstellen von Cache-Parametern einfach wieder lösen.

Gateways: Die schon lange als deprecated markierten Gateways Shared Filesystem, S3 und HDFS sind nun endgültig entfernt worden, empfohlen ist stattdessen die Nutzung der Snapshot/Restore-Funktionalität. 

Zusammenfassung

Soweit die Übersicht über die Neuheiten in der neuen Version von Elasticsearch. Eine vollständige Übersicht über alle Änderungen finden Sie hier.  Wir wünschen viel Spaß beim Ausprobieren! 

Aufmacherbild: Elastic bands on hands, isolated on white von shutterstock.com / Urheberrecht: Africa Studio

Geschrieben von
Valentin Zacharias
Valentin Zacharias
Valentin begeistert sich für die Entwicklung von Strategien und Systemen zur Lösung komplexer Herausforderungen im Informationsmanagement – besonders mit Hadoop, Analytics und Methoden der künstlichen Intelligenz.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Elasticsearch 1.2: Was ist neu?"

avatar
400
  Subscribe  
Benachrichtige mich zu:
David W
Gast

Dafür, dass die Engine in Java geschrieben wurde, finde ich die Dokumentation gerade der Java-API unterirdisch schlecht. Ist man Java-Entwickler, dann wird einem der Einstieg nicht gerade sehr leicht gemacht. Anfang des Jahres hat man bereits Besserung gelobt, doch seitdem hat sich nicht so viel getan.