Big Data und Suche

Apache Solr und ElasticSearch: Auf der Suche nach dem heiligen Gral

Andrew Kenworthy und Christian Meder

Die Daten im Enterprise-Umfeld wachsen rasant und der Einfluss der Big-Data-Technologien wie Hadoop und Lucene – oft im gemeinsamen Einsatz mit traditionellen relationalen Datenbanken – nimmt ebenso stark zu. Flexibilität, Near-Realtime-Ergebnisse und ein erhebliches Datenvolumen sind inzwischen Standardanforderungen, wenn es um die Auswahl von Speicherkapazitäten und Suchtechnologien geht. In diesem Artikel werden wir uns zwei Suchserver, Apache Solr und ElasticSearch, anschauen, die beide zunehmend an Bedeutung gewinnen. Dabei werden wir auch untypische Szenarien im Hinblick auf die Erweiterung von BI-Systemen mit Suchtechnologien betrachten und untersuchen, welche Möglichkeiten in der Kombination von Suche und Hadoop bestehen.

Am Anfang war die Datenbank und die Datenbank war gut bei Index- und Join-Operationen, sie war brauchbar, wenn es um das Auffinden von einfachem Text ging und war weniger gut, wenn es um das Durchsuchen größerer Textstücke ging. Es gab LIKE und = und einige weitere Werkzeuge, aber es lässt sich nicht verheimlichen, dass die Datenbankindizes uns nur einen effizienten Pfad durch unsere Daten bieten, aber keine wirkliche Vorberechnungen für uns durchführen (außer wir bitten die Datenbank höflich in Form von UPDATE STATISTICS darum).

Betrachten wir beispielsweise einen B-Tree-Index [1]: Man kann es vereinfacht mit einer Einkaufstour vergleichen, bei der an jeder Straßenecke ein hilfreicher Mensch steht und dafür sorgt, dass man nicht falsch abbiegt. Wir werden also niemals einen längeren Weg zurücklegen als absolut nötig, aber leider müssen wir trotzdem den kompletten Weg selbst zurücklegen. Wäre es nicht viel schöner, wenn die hilfreichen Menschen an den Straßenecken bereits mit unseren Besorgungen auf uns warten würden? Damit wären wir beim invertierten Index (Inverted Index, Reverse Index): Hierbei werden direkt Ergebnisse auf Fragen nachgeschlagen, sehr ähnlich zum Index eines Buchs. Man wählt ein Wort oder einen Term im Index und findet die Seitenzahlen direkt daneben. Die Suche lässt sich damit in zwei Phasen zerlegen: die Erstellung und Aktualisierung des Index und das Nachschlagen der Ergebnisse. Letzteres kann nun extrem schnell umgesetzt werden, weil keinem komplexen Pfad gefolgt werden muss.

Genau dieser Ansatz wurde dann von verschiedenen Datenbankherstellern aufgegriffen, um einfache (aber aufwendige) LIKE-Operationen zu erweitern: Oracle nannte es interMedia Text (später Oracle Text), Microsoft SQL Server 7 delegierte Volltextsuche an den auf Windows schon vorhandenen Microsoft Search Service (später, ab SQL Server 2005, wurde der Service in den Datenbankkern mit aufgenommen [2]) und PostgreSQL bot eine Implementation des OpenGIS-Projekts t-Search als optionales Plug-in an (später wurde das Plug-in in einer überarbeiteten Version direkt in PostgreSQL als tsearch2 integriert). All diese beschriebenen Umsetzungen sind Variationen über das Thema eines invertierten Index [3], [4].

Die genannten Datenbankerweiterungen erlauben einen Großteil der Funktionalitäten, die mit Volltextsuche verbunden werden: unscharfe und wortstammbasierte Treffer, Wortähnlichkeiten, Ranglisten von Treffern oder auch den Ausschluss von so genannten Stop-Wörtern. Einige Hürden bleiben aber bestehen: Was geschieht, wenn ich das Datenbankschema ändere, muss der Index dann komplett neu erstellt werden? Wenn ich verschiedene Attribute in unterschiedlichen Kontexten verwenden möchte, brauche ich dann zwei Indizes? Wie kann ich Rechtschreibprüfung beziehungsweise Toleranz gegenüber Tippfehlern aufgrund der Volltextdaten integrieren? Volltextsuche innerhalb der Datenbanken hat hier durchaus seine Grenzen.

Lucene und Konsorten

Laut Website [5] ist Apache Lucene eine höchst effiziente, umfangreiche Bibliothek für Volltextsuche. Diese in Java implementierte Bibliothek ist plattformunabhängig für jede Anwendung geeignet, die eine Volltextsuche benötigt. Die angebotenen Möglichkeiten reichen vom Parsen, Analysieren und Abspeichern der Daten bis zum Filtern, Abfragen und Cachen.

Apache Solr [6] dagegen ist ein Suchserver, der die Lucene-Bibliotheken verwendet und um zahlreiche Möglichkeiten und Konfigurationen ergänzt. Die Analyse, das Indizieren und Abspeichern der Daten werden gekapselt und wir brauchen uns nicht um diese Interna zu kümmern, sondern können bequem über ein REST-Interface per HTTP-Aufrufen den Suchserver von verschiedenen Programmiersprachen aus verwenden. Damit können wir uns bei Solr auf die Schema Konfiguration und die Suchanforderungen konzentrieren. Solr kann alternativ auch in einer Anwendung eingebettet werden und bietet unter anderem ein Java API (SolrJ) zur Anbindung.

ElasticSearch [7] ist ein weiterer Open-Source-Suchserver, der ebenfalls auf Lucene aufbaut. Auch ElasticSearch bringt sein eigenes API zur Anbindung durch Anwendungen mit. Beide Suchserver haben einen ähnlichen Funktionsumfang, allerdings mit unterschiedlichen Schwerpunkten [8]: Solr hat aktuell die bessere Dokumentation, eine weitere Verbreitung, generell die größere Community und Nutzerzahl und eine mächtige (wenn auch funktionale) Admin-Oberfläche. ElasticSearch dagegen bietet Auto-Sharding mit der Möglichkeit, zur Laufzeit Knoten hinzuzufügen, sehr einfaches Aufsetzen auch von mehreren Indizes sowie Near-Realtime-Unterstützung. Near-Realtime ist ein Feature, das direkt in Lucene umgesetzt wurde, und daher ist es nur noch eine Frage der Zeit, bis diese Möglichkeit auch in Solr verfügbar ist. Tatsächlich ist es bereits seit geraumer Zeit im Trunk des Solr-Projekts verfügbar (siehe Ticket SOLR-2193). Im nächsten Abschnitt werden wir mit den APIs von Solr und ElasticSearch arbeiten, ein einfaches Schema mit Daten füllen und uns einige Konfigurationsoptionen anschauen.

Geschrieben von
Andrew Kenworthy und Christian Meder
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.