© Excellent backgrounds/Shutterstock.com
Search-as-You-Type- und Volltextsuche mit Elasticsearch

Vom Testen der Suche


Elasticsearch als Open-Source-Suchserver erfreut sich großer Beliebtheit und wird inzwischen für ganz verschiedene Anwendungsfälle eingesetzt. So genannte Search-As-you-Type- und Volltextsuchen können jedoch sehr umfangreiche und komplexe Abfragen gegen das Elastic­search-API mit sich bringen. Das führt zu der Frage, wie man beim automatisierten Testen vorgeht und dafür den Suchserver optimal in die eigene IT-Landschaft integriert.

Angefangen hat alles mit einem Lehrgang an einer Kochschule in London. Eine Teilnehmerin war frisch mit einem gewissen Shay Banon verheiratet, der sie bei ihrer Weiterbildung unterstützen wollte. Er glaubte dies am besten tun zu können, indem er ihr eine Anwendung zum Erfassen des gesammelten Kochwissens und der Möglichkeit zur Abfrage über ein einziges Textfeld schrieb [1]. Die Auseinandersetzung mit diesem Thema bewog Banon schließlich dazu, Elasticsearch zu erschaffen und im Jahr 2010 in einer ersten Version zu veröffentlichen. Die von ihm in Folge gegründete Firma Elastic beschäftigt inzwischen Mitarbeiter in 27 Ländern, die den Suchserver zusammen mit Logstash und Kibana stetig weiterentwickeln und dabei den in die Jahre gekommenen Suchserver Apache Solr mehr und mehr verdrängen. Elasticsearch überzeugt mit einem mächtigen REST-API und ist als verteiltes System konzipiert, das sich gut horizontal skalieren lässt. Die Volltextsuche wird intern wie bei Apache Solr von der seit vielen Jahren etablierten Java-Bibliothek Apache Lucene ausgeführt.

Eine gute Suche lotst den Anwender diskret zu den gewünschten Ergebnissen. Dazu wird für jedes neu eingegebene Zeichen eine Vorschlagsliste angezeigt, aus der ein Ergebnis ausgewählt werden kann (Abb. 1). Das spart dem Anwender Zeit und verhindert Frust infolge von Tippfehlern. Dabei kann Search-as-You-Type nur eine einfache Vervollständigung des Suchbegriffs bieten (Autocomplete) oder aber zusätzlich Ergebnisse zu verwandten Themen vorschlagen und damit den Anwender in eine neue Richtung führen (Autosuggest) [2].

moeser_testen_elastic_1.tif_fmt1.jpgAbb. 1: Die wohl bekannteste aller Suchen

Eine derart zentrale Komponente wie die Suche bedarf einer guten Qualitätssicherung. Doch wie schreibt man Tests, die prüfen, ob die Such-Query die richtigen Ergebnisse liefert, sowohl von der Menge als auch von der Reihenfolge der Treffer? Welche Aspekte hinsichtlich der Architektur mit Elasticsearch als dokumenten­orientiertem Datastore sind dabei relevant? Und wie sieht es mit Testdaten und akzeptablen Build-Laufzeiten aus?

Ein Beispiel muss her

Die Herangehensweise soll an einem Beispiel aus dem Gesundheitswesen gezeigt werden. In der öffentlichen Verwaltung bilden die Arzt- und Praxisdaten als Stammdaten eine wesentliche Grundlage für die meisten Geschäftsprozesse. Mitarbeiter verschiedener Abteilungen können über eine Anwendung die Daten lesen, wobei ihnen eine As-you-Type-Suche mit folgender Spezifikation zur Verfügung steht:

  • Ärzte und Praxen müssen anhand ihrer Namen sowie ihrer jeweiligen ID gefunden werden.

  • Wenn Ärzte mittels ihrer Nachnamen gesucht werden, müssen sie auch bei ähnlicher Schreibweise gefunden werden. So muss die Servicetelefonie bei einem Anruf eines Arztes schnell einen Überblick zu dessen Daten bekommen, ohne genau zu wissen, ob der Arzt z. B. Mayer, Maier, Meier oder Mayr heißt (phonetische Suche). Auch Ärzte mit nicht deutschen Namen müssen leicht gefunden werden.

  • Auch nach Anschriften und Kontaktdaten der Ärzte und Praxen sowie nach fachlichen Attributen wie Tätigkeitsgebieten, Rechtsgrundlagen und Fachgruppen muss gesucht werden können.

  • Generell sind Suchanfragen case-insensitive und Sonderzeichen, wie Bindestriche bei Doppelnamen, müssen ignoriert werden.

  • Die Suchergebnisse müssen alle Begriffe des Eingabefelds enthalten und sind somit logisch UND-verknüpft.

Bis eine Suche wirklich zur Zufriedenheit der Fachabteilung funktioniert, benötigt man erfahrungsgemäß mehrere Iterationen. Ein agiles Vorgehensmodell und frühes Feedback sind angebracht. Bei der Implementierung sollte Test First vorgegangen werden, und am Ende muss für jeden Punkt der Spezifikation ein automatisierter Test existieren, entsprechend der Aussage Kent Becks: „Any program feature without an automated test doesn‘t exist“ [3].

Indizierung und Datenhaltung

Voraussetzung für eine Suche ist die Indizierung des Datenbestands. Elasticsearch ist dokumentenorientiert. Man muss initial die Daten als JSON-Objekte bereitstellen (Abb. 2). In der Analysephase wird für jedes Key-Value-Paar eines JSON-Objekts ein Feld in Elasticsearch angelegt, auf dem später direkt gesucht werden kann. Eine Besonderheit ist das _all-Feld, es enthält die Werte aller anderen Felder mit Leerzeichen konkateniert. Das _all-Feld wird dann bei der Volltextsuche abgefragt, z. B. durch folgende einfache Query:

curl -XGET 'localhost:9200/_search?pretty' -H 'Content-Type: application/json' -d' { "query": { "query_string": { "query": "Max Musterarzt" } } } '

Zusätzlich speicher...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang