© Enkel/Shutterstock.com
Apache Solr und Elasticsearch

Enterprise-Suche mit Apache Lucene


Im ersten Artikel dieses Schwerpunkts haben wir uns mit Apache Lucene beschäftigt, der Bibliothek hinter den beiden bekannten Enterprise-Suchservern Apache Solr und Elasticsearch. Nun wollen wir das dort Gelernte in die Praxis umsetzen und uns anschauen, was hinter den beiden Produkten steckt.

Als Doug Cutting im Jahr 1999 Lucene zum ersten Mal veröffentlichte, war noch nicht abzusehen, dass daraus einmal ein wichtiger Baustein für die Volltextsuche werden würde – auch und gerade im Unternehmensumfeld. Wie auch für den Autor dieses Artikels war das einer der ersten Gehversuche mit der neuen Programmiersprache Java. Schon damals hat sich gezeigt, dass Java – trotz vieler Unkenrufe wie: „Das ist ja interpretiert, das kann doch nie schnell werden!“ – für die Entwicklung einer Volltextsuchmaschine eine gute Idee war; denn mit den später zur JVM hinzugekommenen JIT- und Hotspot-Compilern wurde das Ganze richtig schnell. Heutzutage ist Apache Lucene sogar deutlich schneller als die zwischenzeitlich auch in der Programmiersprache C/C++ implementierten Lucene-Abkömmlinge. Der Grund dafür liegt in der dynamischen Kompilierung und ständigen Optimierung des Java Bytecodes für die Host-CPU. Was Dougs Suchmaschine damals auch einmalig machte, war die Möglichkeit, dass Dokumente gelöscht und upgedatet werden konnten (was faktisch löschen und neu indexieren ist). Wie schon im vorherigen Artikel über Apache Lucene erläutert wurde, ermöglicht Lucene die Indexierung von Dokumenten mit einer Anzahl von Feldern (ähnlich JSON-Dokumenten oder einfach Key-Value Pairs) und ermöglicht eine feldbasierte Abfrage, zu Beginn allerdings nur auf dem Term Dictionary und den Posting Lists basierend. Die inkrementellen Updates von Dokumenten wurden durch eine damals neue Technik mit Indexsegmenten ermöglicht: Ein Lucene-Index besteht von sich aus aus mehreren kleineren Teilindexen, die im Lauf der Zeit zusammengefasst und neu geschrieben (gemergt) werden.

Überblick und Geschichte

2004 stieß dann Yonik Seeley auf der Suche nach einer firmeninternen (Web-)Suche auf Apache Lucene. Damals war REST noch neu und alle Leute begannen, mit Application-Servern wie Tomcat zu arbeiten und Servlets in Webapplikationen zu implementieren. Zu dieser Zeit wurden gewöhnlich APIs gebastelt, die sehr an die damaligen CGI-Skripte erinnerten: Alle Parameter wurden hinter das Fragezeichen in den URL eingefügt; so etwas wie REST basierend auf Dokumenten gab es noch nicht. Yonik implementierte für seinen Arbeitgeber den Vorläufer von Solr, eine Webapplikation, die XML-Dokumente als Eingabe bekam, sie in einen Lucene-Index legte und anschließend mit dem Queryparser wieder abfragen konnte.

2006 wurde der Code von Solr von der Firma CNET, bei der Yonik arbeitete, an die Apache Software Foundation übergeben. 2007 wurde Solr vom Incubator-Projekt zu einem vollständigen Apache-Projekt gemacht und die ersten Releases folgten (die ersten bekannten und teilweise heute immer noch eingesetzten Versionen waren 1.3 und 1.4). Als Erweiterung zur Lucene-Suche implementierte Yonik ebenfalls das sogenannte Facetting. Dabei handelt es sich um die Möglichkeit, die Suchergebnisse nach einer initialen textbasierten Suche weiter zu filtern, indem man dem Benutzer Teilmengen der Ergebnismenge als Vorschläge zur Filterung anbietet (bei einer Produktsuche sind das zum Beispiel Attribute wie Hersteller, Preise oder Autoren von Büchern). Der Benutzer bekommt neben dem Suchergebnis diese Facetten mit der Trefferanzahl angezeigt, die dann angeklickt werden können. Ein weiteres Feature von Solr war ein Indexschema, das die Datentypen der Felder im Lucene-Index definiert und auch bei der Indexierung überprüft.

Im März 2010 wurde dann Apache Solr in das Apache-Lucene-Projekt integriert. Im Jahr 2011 gab es das erste Release beider Produkte aus der gleichen Codebasis mit derselben Versionsnummer (Version 3.1). Im Oktober 2012 wurde Apache Solr 4.0 freigegeben. Noch immer war Solr eine Webapplikation, die standardmäßig in Jetty (statt Tomcat) deployt wurde, aber sie konnte nun auch einen Cluster aus mehreren Solr-Servern bilden und somit riesige Datenmengen verteilt über mehrere Maschinen indexieren; das war die Geburtsstunde der SolrCloud.

Etwa zur selben Zeit wie Yonik arbeitete auch Shay Banon seit 2004 an seinem Projekt Compass [1], das aus einer Kochbuchapplikation für seine Frau geboren wurde [2]. Compass wurde als eine Bibliothek für die Verwaltung und Suche von Dokumenten in Form von Java-Objekten ebenfalls um Apache Lucene herum gebaut. Compass wurde jedoch nicht als Suchserver aufgesetzt, denn vielmehr handelte es sich dabei (ähnlich dem auf JDBC basierenden Hibernate) um ein Framework zum Mapping von Java-Objekten in einen Lucene-Index (vgl. ORM). Schon früh wurde hier Index-Sharding hinzugefügt und der Anwendungsentwickler konnte mit dem Spring Framework einfach und schnell Suchapplikationen bauen. Gerade bei größeren Indexen, bestehend aus vielen Shards, kommt man schnell an die Grenzen einzelner Maschinen, sodass Shay mit dem Gedanken spielte, alles in einen Server zu packen, der von vornherein für die Cloud vorgesehen war. Man konnte Elasticsearch, wie er das neue Projekt nannte, zwar auch allein starten, aber die Erweiterung um mehrere Nodes war recht einfach. Basierend auf einem proprietären binären Protokoll kommunizierten die Server miteinander, sie fanden sich im selben Netzwerk sogar von selbst. In einem Raum konnte jeder Developer Elasticsearch lokal starten und das Ganze verwandelte sich in einen Suchcluster.

Die erste Version von Elasticsearch wurde im Februar 2010 freigegeben. Es ist bis heute ein separates Projekt und wurde anders als Apache Solr nicht in die Apache Software Foundation integriert. Im Gegensatz zu Apache Solr wurde Elasticsearch von vornherein mit einem REST-konformen, dokumentenzentrierten API versehen und spricht moderne JSON-Format an (aber das mit dem modern ist selbstverständlich Ansichtssache), was bei XML nicht der Fall ist.

Im Folgenden werden wir die Features der beiden Projekte vergleichen. Fangen wir dazu mit Apache Solr an:

Apache Solr

Die Installation von Apache Solr gestaltet sich relativ einfach: Man lädt das binäre Paket als ZIP-/TGZ-Datei von den Apache-Mirror-Servern [3] herunter, entpackt es und startet es durch Aufruf der für das jeweilige Betriebssystem vorgegebenen Start-up-Skripte. Die aktuellen Versionen benötigen mindestens ein aktuelles Java-8-Update, funktionieren aber problemlos mit dem Java-11-LTS-Release. Genau wie die Basis Apache Lucene wird Apache Solr ständig mit allen aktuellen Java-Versionen, inkl. Previewreleases, getestet – zum Zeitpunkt des Verfassens dieses Artikels ist also sogar Java 13 mit von der Partie. Für optimale Suchperformanz sollte heute am besten eine der Long-Term-Release-Versionen von Java 11 (AdoptOpenJDK oder Amazon Corretto) verwendet werden. Weder Apache Lucene noch Apache Solr benutzen interne Oracle APIs, somit läuft es problemlos mit allen gängigen JVMs, man muss sich also nicht an Oracle binden.

Nach dem Start als Einzel-Node mit ein paar Testdokumenten, die mitgeliefert werden (techproducts), kann man schon etwas reinschnuppern:

$ bin/solr start -e techproducts

Möchte man selbst eine Collection hinzufügen (so wird ein Index in der Cloudinfrastruktur genannt; oft wird er auch als Core bezeichnet, obwohl s...

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