Lucene/Solr Revolution – Workshop Day 1 – Solr under the hood –

Heute war der erste Workshop Tag im Vorfeld zur Lucene/Solr Revolution. Welch ein Andrang, Solr erfreut sich ganz offensichtlich immer grösserer Beliebtheit. Entgegen den üblichen Solr Workshops, befanden sich heute quasi ganze Schulklassen in den Räumen. Ca. 30 Teilnehmer waren in meinem Kurs, welcher bereits in zwei “Klassen” aufgesplittet wurde. Entsprechend gefordert war unser “Instructor”, der seine Aufgabe hervorragend gemeistert hat. Jason Hellmann, wenn er nicht Workshop leader ist, entwickelt bei LucidWorks an und mit Solr, und kann daher auf einen breiten Erfahrungsschatz direkt aus dem Daily Business zurückgreifen.

Aufbau

Der Workshop ist sehr gut aufgebaut. Nach einer Runde, bei der sich jeder Teilnehmer kurz vorstellt und die aktuellen Schmerzen mit den eigenen Solr-Projekten nennt, wechseln sich Theorie und Praxis immer wieder ab. Jason Hellmann geht während des Tages dann auf die einzelnen Problemfälle gezielt ein, wenn es in den Ablauf passt. In den Theorieteilen werden einem die Kenntnisse vermittelt, welche man dann in den “Labs” anwendet. Für die Labs werden einem Testdaten und Codebeispiele zur Verfügung gestellt. Ich habe mich entschlossen meine eigene Testinstanz von Solr zu verwenden, wodurch ich gezwungen war das Gelernte Wissen per Transferdenken  sofort anzuwenden.

In der Regel hatten alle Teilnehmer bereits Erfahrungen mit Solr gemacht, und sind dann bei einem spezifischen Problem ins Stocken geraten. Meistens Fehler, welche durch fehlendes Hintergrundwissen über die Solr-Architektur begangen wurden, und durch leichte “Kurskorrekturen” behoben werden können. Sei es durch effizienteres Indizieren, oder schlicht durch eine Vorverarbeitung des zu indizierenden Contents. Besonders überrascht hat mich, das Teile der Teilnehmer die geforderten Mindestteilnahmevorraussetzungen nicht erfüllten. Das liegt vermutlich an dem speziellen Termin, direkt vor der Konferenz. Grundsätzlich waren die meisten Teilnehmer übrigens aus den USA, Japan oder Russland. Ich war der einzige Teilnehmer aus Deutschland.

Ein typisches genanntes Problem, sind eine lange Dauer zum Indizieren. So benötigt die produktive Solr-Instanz eines Teilnehmers 20min für 10.000 Dokumente. <ironie>Ja, das scheint mir auch zu lang</ironie>. Mein Laptop schafft in der kleinen virtuellen Maschine die ich zum Entwickeln nutze, 10.000 Dokumente in 20 Sekunden!

Velocity

Das erste was ich heute gelernt habe, erspart mir zukünftig viel Arbeit. Daher gebe ich das gleich als Tipp weiter: Als visueller Mensch erstelle ich mir zu jedem neuen Projekt eine kleine Dummyseite, welche mir ermöglicht Anfragen an die Solr-Datenbank zu stellen, und das XML Ergebnisset gleich in HTML rendert. Solr 4.x kommt nun automatisch mit fertig eingerichtetem Velocity (einer Templating Engine samt Debugging-Tools für Tomcat). Dafür einfach das mit Solr ausgelieferte dist und contrib Directory in das Solr-Home Directory kopieren (das ist das Verzeichnis, wo sich die solr.xml drin befindet), und sicherstellen das die solrconfig.xml den “/browse”-Abschnitt enthält.

Performance

Ein wesentlicher Bestandteil der heutigen Theorie war das Thema Performance. Zusammengefasst, kann man sich folgendes merken

• Je komplexer das Suchanfrage ist, umso länger dauert eine Suchanfrage
• Daher ist es wichtig die Daten bereits vor dem Indizieren zu verarbeiten, denn je besser die Daten sind, umso einfacher und damit schneller sind die Suchanfragen.
• Es gibt grundsätzlichen keinen Grund identische Daten, in verschiedenen Indexes zu halten. Für Solr macht es performance technisch keinen Unterschied, wie gross die Datenstruktur ist. Sollten also ein und die selben Daten für unterschiedliche Applikationen verwendet werden, empfiehlt es sich sämtliche benötigten Datenmodelle in einem Modell zu vereinen, und mit verschiedenen Anfragen die Daten unterschiedlich abzufragen. Dies funktioniert “reibungsfrei”, da unterschiedliche Felder Solr-intern in unterschiedlichen Subindizes gespeichert werden. Der grosse Vorteil daran ist, das man bei Änderungen der Daten nur einen Index updaten muss.

Vorverarbeiten/manipulieren werden kann Content durch

• einen eigenen Indexer
• einen UpdateRequestHandler
• ein oder mehrere Update Processors
• eine Analysis Chain

Bereits im Indexer sollte der Content manipuliert werden, falls

• viele der eingehenden Daten aussortiert gehören (nie relevant sind)
• man ansonsten häufig Änderungen vornimmt, die zu einem Restart von Solr führen

Eigene Solr Components

Während des Workshops haben wir eigene Solr-Components in Java entwickelt, und dann eingebunden. Über das Solr-Admininterface konnten wir die dadurch erzeugten Veränderungen im Index verfolgen. Die Komponente an sich war sehr simpel, wir haben schlicht den LowerCaseFilter in einen UpperCaseFilter abgewandelt und in die update chain eingebunden. Grundsätzlich ist es nicht kompliziert eine Komponente zu schreiben, allerdings ist das Testen umso schwieriger. Der komplette Prozessstack von Lucene und Solr muss dafür im Debugger gehalten werden. Ohne, hat man sowieso keine Chance. Das macht es langwierig und damit auch in der Pflege teuer. Eine Vorverarbeitung ist hier in der Regel günstiger, und hat das gleiche Ergebnis.

Conclusio

Ich schliesse den Blogeintrag mit dem Statement, mit dem der heutige Workshop begonnen hat. Das wertvollste, was heute mitgenommen wurde, ist das Wissen wie Solr deep-inside arbeitet, und mit welchen Tools man welche Arbeitsschritte analysieren kann. Heute war der Workshoptag sehr erfolgreich, ich bin gespannt auf morgen.