Was ist neu in Apache Lucene und Solr 3.4?

Wachsen weiter zusammen: Lucene & Solr 3.4

Uwe Schindler

Bereits im März 2010 beschlossen die Entwickler, dass Apache Lucene und Apache Solr künftig näher zusammenarbeiten und sowohl der SVN-Entwicklungsbaum als auch die Release-Zyklen miteinander verknüpft werden. Ein Jahr später, im März 2011, kam erstmals die Version 3.1 beider Produkte auf den Markt.

Neben der Angleichung der Versionsnummern wurde begonnen, gemeinsam genutzte Teile an zentraler Stelle zusammenzuführen und dafür zu sorgen, dass Solr-Nutzer sofort in den Genuß neuer Lucene-Features kommen. Leider wurde ein Großteil dieser Änderungen, wie ein gemeinsamer Pool von Textanalyse-Komponenten, nur im instabilen Entwicklungszweig (kommende Version 4.0) durchgeführt, weil es sonst zu Brüchen in der Rückwärtskompatibilität gekommen wäre. Trotzdem wurden neue Komponenten auch im stabilen 3.x Branch immer gemeinsam in beiden Projekten entwickelt. Dazu zählen ein neues Testframework, welches auf JUnit 4 basiert, aber vielfältige Zusatzfunktionen anbietet, um reproduzierbare, aber trotzdem zufällige Testdurchläufe zu erhalten. Für den Anwender sichtbare neue Funktionen waren zum Beispiel Gruppierungen von Suchergebnissen, für die die technischen Grundlagen in Lucene abgebildet wurden, Solr jedoch wie gewohnt ein REST Interface und passende Abfragesyntax anbietet.

Am 14. September veröffentlichte die Apache Software Foundation schon das dritte Release von Apache Lucene und Apache Solr in diesem Jahr. Version 3.4 beinhaltet neben der Korrektur eines gravierenden Fehlers beim Synchronisieren der Datei-Caches, welcher bei einem Stromausfall dann zu nicht mehr lesbaren Indexen führen kann (Mike McCandless: „Thanks to hurricane Irene, when Mark’s electricity became unreliable, he discovered that on power loss Lucene could easily corrupt the index, which of course should never happen.“), auch zahlreiche neue Funktionen, welche sowohl Lucene als auch Solr zugute kommen.

Das wichtigste Feature der Version 3.4 ist ein neues Facetting-Modul für Lucene, was es ermöglicht, Suchergebnisse anhand von „Facetten“ einzuschränken – eine Funktion, die bisher nur Solr vorbehalten war. Man ist diese Art von Navigation in der Ergebnisliste z.B. von Amazon gewohnt, wo man bei einer Suche nach „Staubsauger“ zunächst alle Ergebnisse angezeigt bekommt, auf der linken Seite jedoch die Suchergebnisse in „Kategorien“ eingeteilt werden (wie Hersteller, Gerätetyp,…), so dass man durch weitere Klicks die Suchergebnisse einschränken kann. Die Schwierigkeit beim Facetting ist hierbei das Zählen/Schätzen der Anzahl an Resultaten, welche die gewollten Kategorien enthalten. Diese Zahlen sind vorher nicht bekannt, da diese von der aktuellen Suchanfrage abhängen.

Solr behandelte das Facetting bisher komplett dynamisch, das heißt, das Schema musste für den Drilldown nur wenig modifiziert werden, man konnte quasi auf jedem Schema-Feld On-the-fly Facetten erzeugen. Der Nachteil dieser Methode war jedoch der hohe Berechnungsaufwand zusammen mit einem riesigen Arbeitsspeicherbedarf. Das neue Lucene-basierte Facetting Modul wurde von IBM gesponsored und verfolgt einen komplett anderen Ansatz: Der Entwickler muss vorher wissen, welche Facetten er anbieten will, und seinen Index entsprechend aufbereiten. Zusätzlich wird die Taxonomie nicht im Speicher gehalten und dynamisch erzeugt, sondern während des Indexierungsprozesses in einem separaten Lucene-Index abgelegt (dem sogenannten Taxonomy-Index). Im Hauptindex stehen nur noch Zeiger (einfache Ganzzahlen) auf die Taxonomy-Einträge. Das Berechnen und Zählen der Facetten nach einer Suchanfrage sind dann nur noch Mengenoperationen mit Ganzzahlen. Für interessierte Entwickler steht ein PDF mit einer Schritt-für-Schritt-Anleitung im Lucene-Issuetracker zur Verfügung: https://issues.apache.org/jira/browse/LUCENE-3261

Für kommende Versionen von Lucene/Solr ist geplant, dieses Facetting Modul auch Solr-Entwicklern über das Schema zur Verfügung zu stellen. Hier ist jedoch noch einiges an Arbeit zu erledigen. Auf lange Sicht könnte das aufwändige Solr-Facetting dann sicher hierdurch ersetzt werden, was jedoch bei bestehenden Installationen eine Reindexierung erfordern würde (wegen des fehlenden Taxonomy-Indexes).

Geschrieben von
Uwe Schindler
Kommentare

Schreibe einen Kommentar

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