Apache Solr - Der Suchserver meiner Wahl

, Suchserver, Apache Solr, SQL, PHP, Jity

Apache Solr – ein ausgereifter und hochperformanter Suchserver den man schnell und sauber in bestehende Applikationen integrieren kann. So wird die Software von ihren Entwicklern angepriesen und ich kann mich diesem Statement nur anschließen.

Wieso Apache Solr?

Ein Feature-reicher Suchserver der einfach aufzusetzen und sich sehr einfach in bestehende Projekte integrieren lässt, ist Apache Solr, der auf der Suchengine Apache Lucene aufsetzt und diese maßgeblich erweitert. In Java geschrieben und als Servlet in einem Web Container nutzbar, bietet Apache Solr eine sehr einfache REST-Schnittstelle für die Nutzung an. Das sind alles Vorzüge, die das Projekt mit sich bringt. Doch im Rennen war auch ein Konkurrent von Apache Solr, namens SQL Phrase Index, auch Sphinx genannt, der vollständig in C++ geschrieben wurde und etwas jünger als die Suchengine Apache Lucene ist. Ursprünglich tendierte ich zur Nutzung von Sphinx im Jity Projekt, da ich schon Erfahrungen mit dem Umgang des Ruby Klienten Ultrasphinx sammeln konnte. Diesen hatte ich durch die Konfiguration des eigenen Gitorious Services kennengelernt und ihn erfolgreich im System verankert. Begeistert von diesen Erfahrungen, stelle ich prompt die ersten Recherchen, zu einem gepflegten und eleganten PHP Klienten, an. Dieser sollte sich gut in meine Controller-Schema (MVC).">Symfony 2 Applikation einfügen und einfach zu bedienen sein. Doch leider stieß ich nicht auf Umsetzungen, die meinen Anforderungen entsprachen. Als wirklich einzige Alternative erwies sich das Search-SphinxsearchBundle, was einen recht guten ersten Eindruck machte. Mit diesem Wissen, definierte ich die Anforderung an meine Applikation, und ließ sie einige Zeit unbearbeitet im Bug-Tracker verweilen, da ich meine Kapazitäten auf die Implementierung meines TagGenerator-Bundles konzentrierte. Dabei machte ich einige interessante Entdeckungen auf packagist.org, dem Ort an dem ich auch mein erstes Controller-Schema (MVC).">Symfony 2 Bundle veröffentlicht hatte, denn die Applikation hinter diesem Dienst ist Open Source und auch in Controller-Schema (MVC).">Symfony 2 geschrieben. Perfekte Voraussetzungen also, um einen Blick hinter die Kulissen einer andere großen Applikation zu werfen, die auch eine gut funktionierende Suche beherbergt. Und siehe da, dort weht ein ganz anderer Wind und an dieser Stelle bin ich erst richtig aufmerksam auf Apache Solr geworden. Von der Eleganz und Einfachheit des PHP Klienten, der ein gut gepflegtes Controller-Schema (MVC).">Symfony 2 Bundle namens NelmioSolariumBundle besitzt, überzeugt, hatte ich begonnen zum Thema Apache Solr zu recherchieren. Von der Fülle und Qualität der Informationen begeistert, fand ich vom Projekt selbst, ein sehr gut geschriebenes Tutorial1, welches mir den Einstieg in die Software sehr einfach machte. Meine ersten Versuche begeisterten mich so sehr, dass ich meine initiale Tendenz über den Haufen warf und mich für Apache Solr als Suchserver, für das Jity Projekt, entschied.

Installation und Konfiguration

Der erste Start, ohne Date

Die Installation von Apache Solr gestaltet sich je nach System und Distribution etwas anders. Je nachdem ob sich die Software in den Paketquellen befindet, installiert man diese direkt über die Bordmittel oder über ein fertig kompiliertes Java-Paket das sich auf der Webseite des Suchservers befindet. Ich werde im weiteren den Installationsverlauf des fertig kompilierten Java-Paketes beschreiben, der in dieser Form nicht produktiv genutzt werden sollte. (Siehe Sicherheitshinweise am Ende des Kapitels) Zunächst sollte das Paket von der Webseite bezogen werden, dazu dient der folgende Befehl:

[..] $ cd /opt
[..] $ wget "http://mirror3.layerjet.com/apache/lucene/solr/4.0.0/apache-solr-4.0.0.tgz"

Im nächsten Schritt wird das geladene Paket entpackt und ausgeführt:

[..] $ tar xfvz apache-solr-4.0.0.tgz
[..] $ cd /opt/apache-solr-4.0.0/example
[..] $ java -jar start.jar

Und das war es schon mit der Installation. Ich finde das ging wirklich schnell und unkompliziert und gerade diese Kriterien sind, für einen guten ersten Eindruck, essentiell. Da der Suchserver läuft, lässt sich die Administrationsoberfläche über einen Browser unter der Adresse http://localhost:8983/solr/ ansteuern. Dort kann der Status des Servers, sowie Teile der Konfiguration in Erfahrung gebracht werden. Des Weiteren findet sich dort auch eine Übersicht aller SolrCores, die die Grundeinheit des Suchservers darstellen und alle Daten halten. Dabei kann man sich diese Cores als SQL Tabellen vorstellen, da auch diese ein festes Schema2 aufweisen, in dem alle Spalten und deren Datentypen definiert werden. Dies gilt übrigens auch für Sphinx. Um einen neuen Core zu erstellen, bedarf es lediglich eines neuen Verzeichnisses innerhalb des Pfades /opt/apache-solr-4.0.0/example/solr. Eine entsprechende Konfiguration eines SolrCores habe ich in den Projektquellen von Jity festgehalten.

Wie die Daten in den Suchserver kommen

Für dieses Unterfangen bietet Apache Solr zwei verschiedene Wege an, die beide ihre Vorzüge haben. Der erste Weg wäre durch die POST Methode über die REST Schnittstelle und der zweite Weg erfolgt über einen konfigurierten Data Importer3 der zum Beispiel zeitgesteuert Daten aus allen erdenklichen Quellen, auch von einem SQL Server, abholen kann. Der erste Weg kann direkt von der Applikation übernommen werden, was eine Echtzeit-Verarbeitung der Daten zur Folge hat. Dies kann durch die Anforderung an die Applikation gewünscht sein, jedoch zu dem Preis das die Anwendung erweitert werden muss, um genau diese Prozesse abzubilden und dadurch etwas langsamer bei der Ausführung wird. Dem gegenüber steht der zweite Weg über einen Data Importer, der völlig losgelöst von der Applikation, asynchron die Daten abholt und verarbeitet. Dies bietet natürlich den Vorteil die Applikation nicht unnötig zu erweitern und zu verlangsamen. Jedoch ist dann eine Echtzeit-Verarbeitung der gerade eingegebenen Daten zum Beispiel nicht mehr ohne weiteren Aufwand möglich. Denkbar wäre jedoch eine Kombination des Data Importer und der Erweiterung der Applikation, sodass der Importer von einem gewissen Event in der Applikation ausgelöst werden würde, zum Beispiel wenn Inhalte geändert oder neu angelegt werden. Im Jity Projekt habe ich mich für die reine Data Importer Lösung entschieden, die zeitgesteuert nach Änderungen sucht. Dem interessierten Leser sei hier die Datei data-config.xml, die sich im conf Verzeichnis eines SolrCores befindet, ans Herz gelegt, in der, der DataImporter für den Jity SolrCore verfasst wurde.

Sicherheitshinweise für den Betrieb des Suchservers

An dieser Stelle möchte ich darauf hinweisen, dass Apache Solr am Besten seinen eigenen Systembenutzer erhält und unter dessen Namen aufgeführt wird. Dies verringert maßgeblich das Risiko eines Schadens durch einen potentiellen Angriff, da die Software mit geringen Rechten auf Systemdateien, diese nicht verändern oder ausführen kann. Des Weiteren wurden in Apache Solr keine Maßnahmen zum Schutz der Zugriffe auf die Daten unternommen4. Jeder kann Daten abfragen, verändern und neue einspielen. Aus diesem Grund sollte die laufende Instanz vom Suchserver nicht von außerhalb des lokalen Netzwerks erreichbar sein.

Integration in das Jity Projekt

Die Integration von Apache Solr als Suchserver in das Jity Projekt erwies sich als überraschend einfach, da ich wie weiter oben beschrieben, auf den Weg des Data Importers, der zeitgesteuert agiert, zurückgegriffen habe. Die Applikation selbst musste nicht erweitert werden um die Daten in den Suchserver zu spielen, wohl aber um entsprechende Suchanfragen entgegennehmen zu können. Durch diese Herangehensweise führen beide Applikationen ausschließlich lesende Operationen gegeneinander aus, was ich für ein gutes Vorgehen in diesem Bereich halte. Da die Daten nicht Echtzeit-verarbeitet werden müssen, bietet sich auch für diese Anforderung ein Data Importer an. Umgesetzt wurde die Suchfunktionalität in einem Service Controller. Dieses Konzept entkoppelt die Funktionalität von den einzelnen Seiten und macht sie austausch- und erweiterbar. Somit konnte ich eine ganz normale Seite mit dem Titel „Suche“ anlegen, welche als Service die Funktionalität eines Such-Controllers bietet. Ausgehend von diesen Herangehensweisen, ergibt sich die Optionalität einer jeden Funktion innerhalb der Applikation. Die Implementierung des Service Controllers für die Suchfunktionalität ist sehr einfach gehalten und beläuft sich auf rund 220 Zeilen Quellcode.

Zusammenfassung und Ausblick

Wer ernsthaft eine Suchfunktionalität in seiner eigenen Applikation unterbringen will, dem kann ich nur einen Blick in die Richtung Apache Solr empfehlen. Auch Sphinx sollte durchaus in Betracht gezogen werden, wobei diese Entscheidung von den Vorlieben des Entwicklers und Anforderungen an die Applikation abhängig ist. Ein Einblick in beide Welten kann jedoch nie schaden.

Wie immer, wenn es einen neuen Artikel von mir gibt, gibt es auch ein Update der Live Instanz des Jity Projektes. Aus diesem Grund möchte ich darauf hinweisen, dass die Suche nun vollständig integriert ist und ihren Dienst verrichtet. Außerdem wurde der Wunsch, nach Kommentaren die ohne Anmeldung verfasst werden können, erfüllt. Das letzte Update liegt nun auch schon rund einen Monat zurück, und seitdem hat sich unter der Haube viel getan. Eine kurze Bilanz die das belegt:

129 Dateien geändert, 10099 Zeilen hinzugefügt(+), 3493 Zeilen entfernt(-)

Ganz im Sinne der Tradition möchte ich, wie gewohnt mit den Worten abschließen: ich freue mich immer über Feedback und hoffe das der Artikel spannend war. 😃

  1. Solr 4.0 Tutorial
  2. Solr Wiki – Schema Xml
  3. Solr Wiki – Quickstart zu Data Importer
  4. Solr Wiki – Security

Vorheriger ArtikelNächster Artikel