Anwendungsfälle von Elasticsearch und neue Lerninhalte

Einführung

Wir bei Found sehen viele verschiedene Anwendungsfälle von Elasticsearch. Häufig werden wir gefragt: „Was ist euer typischer Kunde?“ Doch auf diese Frage können wir keine klare Antwort geben, abgesehen von „Unsere Kunden bauen sich lieber etwas auf, als mit Clustern zu arbeiten!“ Wir stellen fest, dass Elasticsearch für viele unterschiedliche großartige und auch einige außergewöhnliche Zwecke verwendet wird.

Elasticsearch ist noch relativ neu, und unsere Kunden beginnen in der Regel mit der Verwendung von Elasticsearch für ein bestimmtes Projekt, und fahren später mit weiteren Clustern für Logging und Analytics fort.

Eine gewöhnliche Entwicklung beginnt mit einer einfachen Suche nach einer Website oder einer Sammlung von Dokumenten. Als nächstes kommt unter Umständen die Facettennavigation hinzu, sowie die Rechtschreibkorrektur oder Antworten wie „Meinten Sie …?“. Möglicherweise wird eine unscharfe Suche und auch Autovervollständigung durchgeführt, vielleicht sogar „Search-as-you-type“. Und weil Relevanz wichtig ist, werden schließlich fortschrittlichere Rankings hinzugefügt – beispielsweise basierend darauf, wer der Nutzer ist, wo er sich befindet oder wen er kennt. Und damit klar ist, was die Nutzer genau tun, muss die Verwendung protokolliert und die Metriken gespeichert werden, damit wir wissen, dass alles gut funktioniert.

Elasticsearch kann für all das und noch mehr verwendet werden, doch die unterschiedlichen Anwendungsfälle zeichnen sich durch ganz verschiedene Level an Komplexität und erforderlichen Ressourcen aus.

You Know, for Search! (und mehr!)

Es ist nicht überraschend, dass Elasticsearch häufig zur Implementierung einer „Suche“ verwendet wird, was in der Regel bedeutet, dass es ein Eingabefeld und ein zugehöriges Lupensymbol gibt. Was wir mit „Suche“ meinen, ist in diesem Fall mehrdeutig, und daher werde ich auf verschiedene Arten von Suchen eingehen, z. B. „einfache Suche“, „unscharfe Suche“, „Aggregationen“ – dabei bezieht sich einfach auf die Möglichkeiten einer simplen match-Abfrage.

Viele sind überrascht davon, dass einfaches Suchen zu den am wenigsten ressourcenintensiven Aufgaben von Elasticsearch gehört. Wenn Sie einfach nur die zehn besten Ergebnisse für eine reguläre, exakte match-Abfrage benötigen, können Sie Hunderte von Suchen pro Sekunde in Sammlungen mit zig Millionen von Dokumenten auf kostengünstiger Hardware durchführen. Wenn jedoch eine unscharfe Suche oder Facettennavigation zu Ihren Anforderungen gehören, müssen die CPU und der Arbeitsspeicher deutlich besser sein.

Von modernen Suchoberflächen wird in der Regel eine Art Facettennavigation erwartet, mithilfe derer der Nutzer die Distribution der Suchergebnisse schnell versteht. Wie viele Bücher stammen von einem bestimmten Autor, liegen in einer bestimmten Preisspanne und haben eine bestimmte Bewertung? Diese werden mithilfe von Aggregationen in Elasticsearch implementiert, und es gibt sie in vielen Varianten. Sie können Begriffe, Zahlenbereiche, Datumsbereiche, Geodaten und Vieles mehr zum Aggregieren verwenden.

Es erscheint vielen unlogisch, dass die Suche nach Treffern in Millionen von Dokumenten im Vergleich zum Zählen und Aggregieren von Treffern auf verschiedene Arten einen geringeren Aufwand bedeutet. Nichtsdestotrotz ist das Aggregieren kostspielig, wenn man es mit der Schwierigkeit beim Informationsabruf vergleicht: „Welche zehn Dokumente stimmen mit diesen Bedingungen überein (und sind am relevantesten)?“ Auf der Suche nach den besten Dokumenten verwendet Lucene Tricks wie „Dieser Dokumentensatz stimmt im Vergleich zu diesen Dokumenten nicht mit allen Punkten überein, also kann er nicht der passendste sein, also einfach überspringen.“ Beim Filtern nutzt Elasticsearch den Filter-Cache sehr häufig. Elasticsearch und Lucene sind gut darin, Arbeit zu vermeiden, wo es möglich ist, doch was Aggregationen betrifft, müssen sie stets alle Übereinstimmungen zählen.

In Elasticsearch von unten nach oben erklären wir, wie der invertierte Index funktioniert, und wie das Wörterbuch und Posting-Listen für eine einfache Suche verwendet werden. Dieser Artikel und unsere Artikel zur Textanalyse sollen verdeutlichen, weshalb die korrekte Verarbeitung von Text bei der Suche sehr wichtig ist. Dimensionierung von Elasticsearch und Elasticsearch in der Praxis enthalten Einzelheiten dazu, welche Art von Arbeitsspeicher Sie erwarten können.

Analytics

Analytische Workloads tendieren dazu, Elemente zu zählen und fassen Ihre Daten zusammen – viele Daten, vielleicht sogar Big Data, was auch immer das heißt! Diese basieren auf den Aggregationen von Elasticsearch, und die Aggregationen werden häufig mit Tools wie Kibana generiert.

Wir haben bereits erwähnt, dass diese Aggregationen relativ kostspielig sein können, sowohl im Hinblick auf die CPU als auch den Arbeitsspeicher. Die Anforderungen an den Arbeitsspeicher sind hoch, da Elasticsearch einen Wert schnell in einem Dokument suchen muss, was bedeutet, dass alle Daten für alle Dokumente in einem „Feld-Cache“ im Arbeitsspeicher geladen werden müssen. Dies gelingt leichter mithilfe von „Dokumentwerten“, die Sie vor dem Indexieren von Dokumenten in Ihrem Mapping aktivieren müssen.

Darüber hinaus laufen analytische Suchen häufig auf mit Zeitstempel versehenen Daten, bei denen es sinnvoll sein kann, diese beispielsweise in tägliche oder monatliche Indizes zu unterteilen. Mit je einem Index pro Zeiteinheit können Sie Ihren Suchraum ganz leicht reduzieren und veraltete Daten aufräumen und archivieren.

Unscharfe Suche

Eine unscharfe Suche verzeiht Rechtschreibfehler. Hier ein Beispiel: Sie finden Levenshtein, wenn Sie nach Levenstein suchen. Unser Artikel zur unscharfen Suche enthält weitere Einzelheiten zur Verwendung und Funktionsweise der unscharfen Suche.

Unscharfe Suchen sind einfach umzusetzen und können die Trefferquote deutlich verbessern, doch sie können auch kostspielig werden. Standardmäßig kann ein Begriff im Eingabefeld zu einem ODER mit 50 Begriffen pro Feld umgeschrieben werden, was in Verbindung mit multi_field für eine kombinatorische Explosion von Begriffen in der resultierenden umgeschriebenen Abfrage sorgen kann.

Es ist immer wichtig, Änderungen und Verbesserungen an Ihrer Suche mit einer realistischen Menge an Daten zu testen, bevor Sie sie in der Praxis verwenden. Das trifft vor allem dann zu, wenn der fuzziness-Parameter hinzugefügt wird. Diese Option ist einfach umzusetzen, doch sie wird Ihre Suchen bedeutend kostspieliger machen.

Unscharfe Suchen sind CPU-intensiv. Fügen Sie diese mit Bedacht hinzu, und besser nicht für jedes Feld.

Autovervollständigung und Sofortsuche

Die Suche, während der Nutzer tippt, gibt es in vielen Varianten. Sie kann aus einfachen Vorschlägen bestehen, z. B. bestehende Tags, die auf Basis der Suchhistorie eine Suche prognostizieren, oder eine komplett neue Suche für jeden (gedrosselten) Tastenanschlag durchführen.

Es gibt viele verschiedene Funktionen in Elasticsearch, die Unterstützung bei der Erstellung dieser Features bieten, z. B. prefix-Abfragen, match_phrase_prefix, Indexieren von ngrams, und eine Reihe verschiedener Suggester.

Suchen wie diese sind sehr latenzempfindlich. Die Grenze dessen, was nicht mehr als „sofort“ empfunden wird, liegt in der Regel bei 100 Millisekunden. Die Suche bei nahezu jedem Tastenanschlag bringt auch einen höheren Suchdurchsatz mit sich. Daher ist es maßgeblich, dass die Suchen kostengünstig sind und diese Indizes zum Arbeitsspeicher passen.

Die Autovervollständigung von Suchen und die parallele Anzeige der Ergebnisse für die am wahrscheinlichsten durchgeführte Suche, etwa so, wie Google es tut, sollten als zwei unterschiedliche Problematiken der Suche betrachtet werden. Die Menge an Daten, die bei der Autovervollständigung vorheriger Suchen durchsucht wird, ist vermutlich deutlich kleiner als die durchsuchten Inhalte, wodurch die Speicherung im Arbeitsspeicher und unscharfe Suchen leichter umzusetzen sind. Da eine autovervollständigte Suche eine deutlich höhere Suchlast als die Vollsuche mit sich bringt, ist es durch die Trennung der beiden möglich, sie separat zu skalieren, gegebenenfalls in komplett getrennten Elasticsearch-Clustern.

Als Soundcloud seine Sucherfahrung umgestaltete, wurde viel an Suchvorschlägen gearbeitet. Die Implementierung wurde gut umgesetzt, und so stellten sie nicht nur eine Steigerung der Suchgenauigkeit fest, sondern auch eine deutliche Lastreduktion in der Infrastruktur bei der Vollsuche. Wonach Nutzer suchen, folgt häufig einer Zipfschen Verteilung: In der Regel machen 10 % der eindeutigen Suchen 90 % des Suchvolumens aus. Daher ist es sehr wahrscheinlich, dass die vollständigen Ergebnisse für den besten Suchvorschlag bereits im Cache (in Ihrer Anwendungsebene) gespeichert sind und „sofort“ angezeigt werden können.

Ein großer Teil der Entwicklungsarbeit hinter dem Suche-Suggester von Soundcloud führt zu den Suggester-Funktionen von Elasticsearch. Es gibt eine tolle Präsentation von Muir und Willauer zu Abfragevorschläge bei Lucene, die weitere Informationen enthält.

Mehrere Instanzen

Häufig haben Sie mehrere Kunden oder Nutzer mit separaten Dokumentensammlungen, und ein Nutzer sollte niemals Dokumente durchsuchen können, die ihm nicht gehören. Dies führt häufig zu einem Design, bei dem jeder Nutzer seinen eigenen Index besitzt.

In den meisten Fällen resultieren daraus viel zu viele Indizes. In fast allen Fällen wird ein Index pro Nutzer implementiert, obwohl ein großer Elasticsearch-Index in der Tat besser wäre. Eine große Anzahl an kleinen Indizes bringt erhebliche Nachteile mit sich:

• Der Arbeitsspeicher-Overhead ist nicht unerheblich. Tausende kleiner Indizes verbrauchen viel Heap-Speicher. Die Anzahl der Dateideskriptoren kann ebenfalls rasant steigen.
• Es kann viele Duplikate geben. Bedenken Sie, wie der invertierte Index funktioniert, und wie Lucene Inhalte in Segmente schreibt und komprimiert.
• Snapshot/Wiederherstellen ist aktuell ein serieller Prozess mit einem Overhead je Index. Die Snapshot-Erstellung dauert bei Tausenden kleiner Indizes erheblich länger als bei wenigen großen Indizes.

In Dimensionierung von Elasticsearch finden Sie weitere Informationen zu Sharding- und Partitionierungsstrategien sowie einige weitere Referenzen. Die Überarbeitung einer Anwendung mit suboptimalem Index kann großen Aufwand mit sich bringen – daher lohnt es sich, die verschiedenen Ansätze kennenzulernen.

Sie sollten also für Ihre Multi-Instanz-Anwendung nicht einen Index pro Nutzer vergeben.

Ohne Schema/Nutzerdefinierte Schemata

Mit vielen verschiedenen Kunden entstehen viele Anwendungsfälle, bei denen unterschiedliche Nutzer möglicherweise mit komplett unterschiedlichen Dokumenten arbeiten. Wenn Sie beispielsweise einen Dienst für Nutzerumfragen/Fragebögen anbieten, ist es wahrscheinlich, dass unterschiedliche Umfragen komplett unterschiedliche Felder haben.

Daraus resultiert häufig die Verwendung des „dynamischen Mappings“ von Elasticsearch, das manchmal als schemalos beworben wird. Elasticsearch erstellt im Hintergrund ein Mapping für Sie, und es kann problematisch werden, wenn dieses zu groß wird und es zu einer „Mapping-Explosion“ kommt. Stattdessen ist es wichtig, sicherzustellen, dass Werte in einem Dokument auch Werte bleiben – und nicht zu separaten Feldern werden. Darauf wird in „Schwierigkeiten mit Keys/Werten“.

Elasticsearch hat vielseitige Mapping-Fähigkeiten mit Indexvorlagen, dynamischen Vorlagen, Multifeldern und mehr. Nutzen Sie diese!

Auch wenn Sie kein Mapping verwenden, sollten Sie wissen, welche Möglichkeiten das Mapping von Elasticsearch für Sie bietet.

Nutzerdefinierte Suchen

Mit nutzerdefinierten Modellen geht oft die Notwendigkeit einher, Endnutzern die Möglichkeit zu geben, ihre eigenen Suchen mit Filtern, Scoring und Aggregationen zu definieren. Ein gängiger Ansatz besteht darin, die Suchanfrage auf bestimmte Indizes zu begrenzen und/oder die Nutzerabfrage mit Filtern zu versehen.

Doch auch unter diesen Umständen gibt es mehrere Wege, wie ein Nutzer mit nutzerdefinierten Suchanfragen Schaden anrichten kann, z. B. durch CPU-intensive Suchen, Memory Hogging oder indem Elasticsearch zum Absturz gebracht wird. Diese Themen werden in Sechs Wege, wie Elasticsearch zum Absturz gebracht wird und Absichern Ihrer Elasticsearch-Cluster behandelt.

Seien Sie bei nutzerdefinierten Suchanfragen achtsam.

Crawling und Verarbeitung von Dokumenten

Es gibt viele Wege, Ihre Daten in Elasticsearch einzuspeisen.

Ein River ist ein Elasticsearch-Konzept, bei dem Elasticsearch Daten aus einer Quelle wie einer Datenbank durch JDBC, eine Nachrichtenwarteschlange, einen Twitter-Stream oder das Crawling von Websites gewinnt. Die ersten Schritte damit sind relativ einfach, doch der Ansatz ist schwer skalierbar und in der Praxis einzusetzen. River als solche sind veraltet, und diese Probleme sollten außerhalb von Elasticsearch gelöst werden. Logstash bietet Support für immer mehr Systeme und kann viele River ersetzen. Für nutzerdefinierte Anwendungen bestehen genügend Herausforderungen beim Synchronisieren von Daten zu Elasticsearch und Vorbereiten von Elasticsearch-Dokumenten, sodass etwas Simples und Generisches wie River nicht als ausreichende Lösung betrachtet werden sollten. Was Crawling betrifft, werden Scrapy und Nutch in Kombination mit Elasticsearch verwendet.

Ähnliches gilt für die Verarbeitung und Konvertierung von Dokumenten wie Word-Dateien oder PDFs in einfachen Text, den Elasticsearch indexieren kann. Es gibt ein „mapper-attachments“-Plugin, das für diese Konvertierung in Elasticsearch verwendet werden kann. Doch auch wenn das Plugin für Anhänge praktisch ist, empfehlen wir, die Dokumentenkonvertierung vor dem Versenden der Dokumente an Elasticsearch durchzuführen. Damit haben Sie die bestmögliche Kontrolle darüber, wie Dokumente konvertiert und ausgewählt werden. Eine solche Dokumentenkonvertierung ist in der Regel einer der ersten Schritte des „Content Refinement“ in der Dokument-/Textverarbeitungspipeline. Die Dokumente, die Sie an Elasticsearch senden, sollten das Ergebnis dieses „Content Refinement“ bzw. dieser „Vorbereitung“ sein, sodass Elasticsearch die finale Textverarbeitung und das Indexieren übernehmen kann. Die Dokumentkonvertierung ist relativ CPU-intensiv, jedoch leicht parallelisierbar. Es ist empfehlenswert, Elasticsearch zunächst Zeit für das Indexieren und Suchen zu geben und „Upstream“-Kunden die Dokumentenkonvertierung zu überlassen.

Speisen Sie verarbeitete Daten in Elasticsearch ein, rufen Sie nichts aus Elasticsearch ab und verarbeiten Sie nichts innerhalb von Elasticsearch.

Zusammenfassung

Es gibt viel zu lernen über Elasticsearch, und manchmal ist es nicht leicht, das zu identifizieren, was man braucht.

In diesem Artikel haben wir einige gewöhnliche Anwendungsfälle und wichtige Punkte besprochen, die es zu beachten gilt. Wir hoffen, dass Sie für Ihren Bedarf etwas Neues mitnehmen konnten und Ihre Elasticsearch-Anwendung bald in die Produktion gehen kann.