Flexibler

Einen genauen Blick sollte man auf eigene TokenStream-Implementierungen werfen. TokenStreams verwandeln den eingehenden Text in die Häppchen, die dem Index gefüttert werden. Hier wurde das API komplett geändert – weiteres Finetuning ist schon angekündigt. Eine neue Oberklasse AttributeSource erlaubt nun wesentlich komplexere und flexibel zusammengesteckte Operationen. Hier wartet unter Umständen einiges an Arbeit auf den Lucene-Nutzer.

Ein Index kann aus mehreren Segmenten bestehen. Bisher konnte Apache Lucene diese nur als Gesamtheit durchsuchen, was zur Invalidierung aller Such-Caches führte, sobald sich nur ein Segment geändert hatte. In 2.9 werden die Segmente separat behandelt.

Eine weitere wesentliche Änderung ist, dass nun keine Score-Werte mehr mit dem Ergebnis zurückgeliefert werden. Diese Werte sind für den Endverbraucher in der Regel nicht aussagekräftig. Sollen sie trotzdem dargestellt oder programmatisch ausgewertet werden, muss man die Berechnung der Score-Werte explizit aktivieren.

Optimiert

Bisher konnte man nur Dokumente suchen, die mit IndexWriter.commit() endgültig geschrieben worden waren. Zusätzlich musste IndexReader.reopen() aufgerufen werden. IndexWriter.getReader() ermöglicht nun eine Suche auf allen dem IndexWriter bekannt gemachten Dokumenten.

Eine Zahl sagt mehr als tausend Worte

Bisher galt: Lucene ist eine textbasierte Suchmaschine. Um Zahlen durchsuchbar zu machen, mussten sie in Text umgewandelt werden und als Strings indiziert werden. Dies führte zu Problemen, wenn zu viele verschiedene Zahlenwerte für ein Intervall im Index waren. Da jeder einzelne Wert zu einem großen Query "verODERt" wurde, konnte dies leicht zu tausenden von Termen führen, und Lucene strich die Segel. Dies war der Fall bei Datumswerten, die inklusive Millisekunden indiziert wurden, wobei die Suche dann über mehrere Monate erfolgen sollte. Auch bei Messwerten wie zum Beispiel Längen- und Breitengraden, bei denen selbst für einen annähernd gleichen Ort verschiedene Nachkommastellen herauskommen, gab es Probleme.

Der deutsche Lucene-Committer Uwe Schindler nahm sich des Problems an und ergänzte Lucene um die Fähigkeit, auch Zahlen effizient durchsuchbar zu machen. Er führte den Feldtyp NumericField ein. In solchermaßen indizierten Zahlenfeldern wie z.B. der Datumsrange 30.3.2009 bis 5.4.2009 wird nun nach allen Dokumenten gesucht, die entweder dem Wert "30.3.2009" oder dem Wert "März 2009" oder den Tagen 1.4 bis 5.4. zugeordnet sind. In der Mitte des Intervalls wird also die Suche vergröbert, nach außen hin nach Bedarf verfeinert. Dies ist extrem effizient [4]. Außerdem können NumericFields dazu dienen, die Sortierung der Suchergebnisse zu beschleunigen.

Fazit

Lucene 2.9 ist für sich genommen ein nennenswertes Release. Wer von den vielen kleinen Verbesserungen profitieren will, sollte die Migration in Angriff nehmen. Mit Lucene 3.0 stehen aber auf jeden Fall weitere einschneidende Änderungen an: Java 5 wird dann vorausgesetzt, Java 1.4 nicht mehr unterstützt. Unter Umständen kann sich das Überspringen von 3.0 also für denjenigen lohnen, der gerne alles in einem Schritt erledigt und abwarten kann, bis sich neue Features "gesetzt" haben. Für einen graduellen Übergang ist 2.9 aber ideal.

Nicht unerwähnt bleiben soll, dass das nächste Apache Solr Release basierend auf Lucene 2.9 ebenfalls in Kürze erscheinen soll.

Links & Literatur

1. http://lucene.apache.org/
2. Lucene Change Log
3. Lucene 2.9.0 API
4. Schindler, U, Diepenbroek, M, 2008. Generic XML-based Framework for Metadata Portals. Computers & Geosciences 34 (12), 1947-1955.