Volltextsuche mit ElasticSearch
Wenn es um die Volltextsuche in großen Datenmengen geht, führte lange kein Weg an Apache Solr vorbei. Seit 2010 steht mit ElasticSearch ein weiteres ebenfalls auf Lucene aufbauendes Projekt zur Verfügung, das sich zunehmend als Alternative zum etablierten Solr positioniert.
- Oliver Fischer
Wenn es um die Volltextsuche in großen Datenmengen geht, führte lange kein Weg an Apache Solr vorbei. Seit 2010 steht mit ElasticSearch ein weiteres ebenfalls auf Lucene aufbauendes Projekt zur Verfügung, das sich zunehmend als Alternative zum etablierten Solr positioniert und immer häufiger zum Einsatz kommt.
Dass ElasticSearch erfolgreich ist, liegt an Features wie einfachem Clustering zur Umsetzung von Hochverfügbarkeit und Lastverteilung, einer vollständig REST- und Java-API sowie an der Tatsache, dass es schemalos und dokumentenorientiert arbeitet. Zudem finden Änderungen auch unter hoher Änderungslast schnell Eingang in Suchergebnisse, weshalb die ElasticSearch-Entwickler auch von Suche in Echtzeit sprechen. Der vielleicht wichtigste Aspekt ist jedoch die einfache Handhabung von ElasticSearch: Mehr als ein Java Development Kit, cURL und ein Editor wird nicht benötigt, um innerhalb von ein paar Minuten eine ElasticSearch-Instanz zum Laufen zu bringen und die ersten Dokumenten zu indizieren.
Aus der Vogelperspektive
ElasticSearch folgt, wie viele Vertreter der NoSQL-Systeme, einem dokumentenzentrierten Ansatz im Umgang mit Daten. Für die spätere Suche werden zu indizierenden Daten als JSON-Dokumente an ElasticSearch übergeben und gespeichert.
Intern legt ElasticSearch die Dokumente in Indizes ab. Ein Index stellt dabei lediglich einen logischen Namensraum dar, in dem beliebig viele Dokumente unterschiedlichen Typs abgelegt werden. Beispielsweise könnten alle Dokumente mit Adressen in einem Index addresses abgelegt und zusammengefasst werden, unabhängig ob sie deutsche oder japanische Adressen enthalten. Die physische Speicherung erfolgt dabei in mehreren als Primary Shards bezeichneten Lucene-Instanzen. Das Aufteilen eines Index dient der Lastverteilung, da sich so lang laufende oder komplexe Suchanfragen durch mehrere Instanzen parallel bearbeiten lassen. Die Shards eines Index können darüber hinaus auf unterschiedliche Knoten eines Clusters verteilt werden, um so die Last auch physisch zu verteilen. Um Datenverlust im Falle des Ausfalls eines Knotens zu verhindern, lassen sich von jedem Primary Shard mehrere als Replica Shards bezeichnete Kopien auf anderen Clusterknoten anlegen. Dieses Feature ist zur Optimierung von Suchanfragen nützlich, da das Verteilen von Shards ebenso wie das Speichern von Dokumenten und Ausführen von Suchanfragen so beeinflussbar ist.
Von Haus aus ist ElasticSearch als Clusteransatz nach dem Master-Slave-Muster konzipiert. Jeder Knoten eines ElasticSearch-Clusters kann dabei jede der beiden Rollen einnehmen. Beim Start führt jeder Knoten einen Discovery-Prozess aus und sucht via Uni- oder Multicast nach anderen Knoten im gleichen Netzwerk. Ob ein anderer Knoten zum gleichen Cluster gehört, wird dabei über den für den Knoten konfigurierten Clusternamen, eine einfache String-Eigenschaft, entschieden. So ist es möglich, mehrere Cluster parallel im gleichen Netzwerk zu betreiben. Anschließend handeln die Knoten untereinander den Masterknoten aus, dem dann die Koordination des Clusters obliegt. Fällt er aus oder ist er eine zeitlang nicht erreichbar, bestimmen die verbliebenen Knoten einen neuen Master.
Installieren, konfigurieren, loslegen
Um ElasticSearch zu installieren, ist lediglich die jeweils aktuelle Distribution herunterzuladen und zu entpacken. Anschließend lässt sie sich sofort mit
./bin/elasticsearch -f
starten. Durch die Option -f bleibt ElasticSearch im Vordergrund und gibt seine Log-Meldungen auf der Konsole aus.
Für den ElasticSearch-Server gilt ein Zero-Configuration-Ansatz, das heißt, dass für alle möglichen Einstellungen sinnvolle Standardwerte vorgegeben sind. Passen sie nicht, lassen sie sich über die im YAML-Format geschriebene und standardmäßig leere Konfigurationsdatei config/elasticsearch.yml an die eigenen Anforderungen anpassen. Auf jeden Fall sollte der Clustername der ElasticSearch-Instanz, der standardmäßig auf elasticsearch voreingestellt ist, über den Parameter cluster.name auf einen selbstgewählten Namen geändert werden. Sonst besteht die Gefahr, dass eine andere frisch gestartet Instanz im gleichen Netz dem eigenen Cluster beitritt und Daten und Suchanfragen entgegennimmt. Auch darüber hinaus ist ein Blick in die Konfigurationsdatei lohnenswert, da sie ausführlich dokumentiert ist und einen guten Einblick über mögliche Einstellungen des Servers gibt. Nach dem Start lauscht ElasticSearch auf Port 9200.
