Das erste Mal Solr

Lange Zeit bin ich gut damit gefahren, auf MySQL-Indizes zu setzen. Wenn die Suche dann doch mal komplexer wurde, hat Zend Lucene immer gute Dienste geleistet. Bis es dann im Sommer hieß, zeitzonen.de soll zukünftig nicht nur die Uhrzeit aller Länder, sondern auch von Städten anzeigen und durchsuchbar machen.

Die Grenzen einer PHP-Lösung

Die Suche über diverse Tabellen hinweg und besonders die Performance bei für die Autocomplete-Suche, disqualifizierten MySQL. Damit war ich bei meinem alten Freund Zend Lucene. Im ersten Schritt ging es um ca. 10.000 Städte. Probleme mit der Performance gab es hier nur beim Erstellen des Indexes. Das dauerte gerne mal eine gute Stunde. War aber vertretbar und schadete dem Livebetrieb nicht. Solr befand sich zu dem Zeitpunkt sogar auf meiner Wunschliste, wurde aber gestrichen. Es lief ja alles.

Dann kam der Wunsch, auch noch all die anderen schönen Städte mit auf die Seite zu übernehmen. 10.000 und 150.000 sind verschiedene Dimensionen und plötzlich war die PHP-Lösung eine einzige Katastrophe. Den Index habe ich nie ganz erstellt bekommen. Meine Hochrechnungen beliefen sich irgendwann auf mehrere Tage.

Um so größer der Index wurde, um so länger dauerte das Schreiben. Schneller ging es nur, wenn der Index zwischendurch optimiert wurde. Das dauerte nur leider auch immer länger. Aber auch ohne einen vollständigen Index war schon zu sehen: Die Performance passt nicht. Bis zu 3 Sekunden bis zur Anzeige der ersten Ergebnisse war nicht hinnehmbar.

Solr als Heilsbringer

Damit war ein sinnvoller Grund gefunden, die gefühlt arg gehypte, Solr-Suche aus dem Papierkorb zu holen und zum Heilsbringer zu ernennen. Ich hatte mich zwar noch mit den Alternativen auseinandergesetzt, insbesondere ElasticSearch.

Beide Lucene. Beide sicher Ihre Vorteile. Meine Entscheidung viel nach einigem Hin- und Her letztlich aber klar auf Solr: Im Thema Dokumentation schien Solr die Nase vorn zu haben. Zudem wusste ich, dass unser Provider eine einfache Installation ermöglicht und die PHP-Integration machte die Nutzung sehr einfach.

Die Installation auf dem Mac

Beim Provider war die Installation auch ein Klick. Das Einrichten meiner Testumgebung unter OS X  10.10 erwies sich nur leider als einziger richtiger Stolperstein. Auch hier war zwar der Solr Server, mit Hilfe aus dem Netz, schnell installiert.

Nur wie im Quickstart Tutorial ging es dann nicht mehr so richtig weiter: Die Pfade waren alle anders, als vorgesehen und der Start des Servers endete in einer SolrException. Hilfe brachte dann dieser Post, in dem durch ein paar Softlinks die Vorgaben aus dem Tutorial und die Tatsachen auf dem Mac vereint werden.

Auch die PHP Extension wollte sich dann so gar nicht in meiner MAMP-Installation zum Laufen bringen. Letztlich war ein neu konfigurieren der genutzten PHP-Version nötig, wie hier beschrieben.

Die Konfiguration

Als dann mal alles am laufen war, ging es überraschend problemlos. Die mitgelieferten Beispiel-Cores lassen sich bereits gut als Ausgangsbasis für den eigenen Core nutzen. Detaillierte Infos zu schema.xml und solrconfig.xml gibt es in einem ausführlichen Solr-Wiki.

Ein super Beispiel, um aus der ganzen Sache eine vernünftige Autocomplete-Suche zu machen, fand ich dann auf diesem Blog. Auch wenn es bei dem Beispiel konkret schon um die Geonames-Daten geht, gibt die Beispiel-Konfiguration auch generell ein sehr gutes Verständnis, was die Konfiguration in der Praxis alles ermöglicht. Nämlich: Alles.

Der Import

Zuerst arbeitete ich mit einem PHP-Script, welches meine vorher angereicherten und übersetzen Daten einzel in den Index schieben sollte, was mir aber zu langsam war. Die Lösung war viel einfacher: Die Daten alle in eine CSV-Datei exportieren. Der Import dieser Daten ist dann nur noch eine Sache weniger Minuten. Weg waren die Stunden Wartezeit.

Zum aktualisieren des Indexes auf der Kommandozeile sind jetzt immer drei Schritte nötig. Erstmal das leeren des Indexes. Das beeinflusst noch nicht die Suche, da die Updates erst committed werden müssen, damit sie live gehen:

curl http://localhost:8983/solr/core_de/update?commit=true -H "Content-Type: text/xml" --data-binary '*:*'

Im nächsten Schritt werden die Daten importiert:

curl http://localhost:8983/solr/core_de/update/csv --data-binary @data.csv -H 'Content-type:text/plain; charset=utf-8'

Zum Schluss wird der Index dann optimiert, was auch ein Committen der Änderungen und damit live schalten der Änderungen bedeutet:

curl http://localhost:8983/solr/core_de/update?optimize=true

Das Ganze dann noch ein zweites Mal für den englischen Index und die einmal exportierten Daten sind in ca. drei Minuten auf dem neusten Stand.

Das Grinsen

Die Begeisterung die mich dann überkam, als ich anfing die Suche zu testen, ist wohl als wahnsinniges Grinsen gepaart mit Ungläubigkeit, ganz gut beschrieben.

Quasi verzögerungsfrei Ergebnisse. Ab dem zweiten Zeichen, inklusive sinniger Treffer-Vorschläge bei ungenauen Eingaben. Im Handumdrehen waren noch einzelne Felder anders priorisiert und die Suche an unsere Wünsche angepasst.

Das Einbeziehen weiterer Felder, zur Verfeinerung der Suche, war bei der PHP-Lucene-Lösung immer sofort in der Performance spürbar. Die Java-Variante Solr war davon vollkommen unbeeindruckt.

Der Umstieg war damit ein voller Erfolg. Man merkt das die Suche eigentlich noch für weitaus größere Aufgaben geschaffen ist. Trotzdem lässt sie sich eigentlich überraschend leicht zum Laufen bringen und unkompliziert anpassen. Ich bin restlos begeistert und grinse weiter selig vor mich hin.