Highlights von Apache Lucene & Solr in der Version 4.0

Nachdem die BETA-Version im August 2012 verfügbar war, erschien vor wenigen Wochen die von der Apache Software Foundation offiziell angekündigte Version 4.0 von Lucene & Solr. Um den jetzigen Status zu erreichen mussten viele Hürden genommen werden – vielen Dank an die Entwickler, alle Verantwortlichen, die Endecker des Kaffee und die Hersteller der Energy-Drinks. Super Arbeit, Leute!

Highlights von Lucene 4.0

  • Die FuzzyQuery ist 100x mal schneller geworden. Im Blog von Mike McCandless findet sich eine tolle Geschichte wie das Ziel erreicht wurde. Angefangen mit einem Paper über einen effizienten Algorithmus um den Levenshtein-Automaton zu bauen, langen Bier- und Kaffeesessions und einem Open-Source Paket namens Moman(von jemandem nebenher geschrieben, der auch die Assasin´s Creed-Spiele für Ubisoft mitentwickelt), zu einer generellen AutomatonQuery, welche jetzt bei der Wildcard-, Regex- und FuzzyQuery im Einsatz ist. Wegen dieser Leistungssteigerung arbeitet auch der DirectSpellChecker wie auf Steroiden, er braucht ürbigens keinen separaten Index mehr für das Spellchecking.
  • Die Such-Logik arbeitet nach einem Indexreader-Umbau segmentweise. Der Reader wurde in zwei Unterklassen aufgeteilt: AtomicReader & CompositeReader. Bei Versionen vor Lucene 2.9 wurde die Suche auf dem kompletten Index abgefeuert, ein Optimize, von Zeit zu Zeit, war wichtig um den Index auf ein Segment runterzubrechen. Es gehört der Vergangenheit an.
  • neuer BlockPostingFormat mit einer unglaublichen Steigerung der Suchperformance.
  • Mit der neuen Codec-API gibt es die Möglichkeit den Index-Format mit eigenen Codecs zu versehen, Codename „Flexible Indexing„.
  • Änderung der Scoring-Architektur. Neue Ranking-Algorithmen wie Okapi BM25 Model, Sprach-Models, usw., können eingesetzt werden. Klasse Sache für Leute die frustriert waren die TF/IDF Gewichtung zu optimieren.
  • Geschwindigkeitssteigerung beim Indizieren, Stichwort „Concurrent Flushing„.
  • Und vieles mehr

Die API von Lucene wurde übrigens ohne Rücksicht auf Rückwärtskompatibilität umgebaut, die REST-API von Solr wurde aber von vielen Änderungen verschont.

Highlights von Solr 4.0

  • Ein immens großes Paket an neuen Funktionen für die vereinfachte Skalierung in verteilten Systemen namens SolrCloud.
  • Ein nagelneues Admin UI, mit visuellen Gimmicks für die Speicherverwaltung, einem schöneren Schema-Browser, der Core-Administration oder einer „Cloud-Sicht.“ Und die Ausgaben aus dem Logfile werden farblich dargestellt.
  • Apache Zookeeper Integration, Split-Brain-Immunität wegen dem Einsatz der Paxos-Protokolle
  • Polygon-Support für die Geo-Suche. Mehr Details in diesem Video: Search with Polygons.
  • Atomare Dokumentenänderungen ohne Reindizieren jetzt möglich. Eine weitere Möglichkeit für partielle Änderungen ist das optimistic concurrency control.
  • Real-Time Get(nicht zu verwechseln mit NearRealTimeSearch), um die letzte Version eines Dokuments ohne Commit oder dem Neuöffnen eines Searchers zu erhalten. Hier wird das „transaction log“ eingesetzt um die nicht-commiteten Dokumente zu überwachen. Ist übrigens auch eine Garantie dass wir keine Dokumente ohne Commit verlieren.
  • Pivot-Facettierung, also die Möglichkeit bereits facettierte Dokumente nochmals zu facettieren.
  • Und vieles mehr

All die gegebenen Vorteile von NoSQL in Lucene kombiniert mit den eigenen Features von Solr lassen Solr zu einem primären Data-Store anwachsen. Solr ist kein simpler Suchindex mehr, es ist eine NoSQL-Datenbank.

Zukunftsentwicklung

Die zwei führenden Search-Engines auf dem Markt, ElasticSearch und Solr, profitieren von den grundlegenden Änderungen in Lucene und legen noch eine Schippe mit eigenen Features drauf. Wie sieht aber die Zukunftsentwicklung aus?
Ich verglich beide Search-Engines schon einmal in einem Blogpost und erwähnte dort ihre Pros & und Kontras.
In ElasticSearch fehlt die Funktionalität für das Grouping und das Spellchecking, was in Solr verfügbar ist. ElasticSearch setzt auch beim nächste Release 0.20 auf die ältere Lucene 3.6 Version. Ab dem Release 0.21 mit Lucene 4.0 sollen beide Features vorhanden sein, im Fall von Spellchecking sogar mit dem neuen DirectSpellChecker.
Solr fehlen zwei spezielle Features, die ElasticSearch mit sich bringt. Das Eine ist der Percolator. Da gibt es auch keine nennenswerte Entwicklung in dieser Richtung. Das Zweite ist die „nested documents“-Funktionalität, speziell für die Zugriffsbeschränkung von Dokumenten. Ich fand zwei Jira-Issues, SOLR-1834 und SOLR-1872. Ist hier etwas neues geplant?

Ich freue mich auf weitere Entwicklungen und bedanke mich nochmals bei den Verantwortlichen für die neuen Features.

Hier sind noch einige Links zu interessanten Inhalten:

Note: You can read this post in english here: http://www.sentric.ch/blog/highlights-of-apache-lucene-solr-4-0

 

Apache Solr Entwicklung in Eclipse

Was ist Solr?

Solr bietet auf Basis von Lucene eine sehr mächtige und dabei leicht zu bedienende und zu integrierende Suchplattform. Es kann durch die hohe Anzahl der mitgelieferten Module und Schnittstellen an die jeweiligen Datenstrukturen und Suchbedürfnisse angepasst werden.
Der Einsatz von Solr und Lucene ist auch kommerziell kostenfrei.

Es besteht oftmals der Wunsch oder der Bedarf  an der Sourcecode-Basis von „Apache Solr“ Änderungen vorzunehmen. Die Vorgehensweise zum Einrichten einer Entwicklermaschine wird hier detailliert beschrieben.

Eclipse installieren

Als IDE empfiehlt sich Eclipse, die neueste Version ist unter
Eclipse-Downloads zu finden. Empfehlenswert ist der Download der vollen Version, der „IDE for Java EE Developers“.

Sourcecode von Solr auschecken

Sourcecode von Solr ist im Trunk zu finden, und mit Hilfe von SVN leicht auszuchecken. Bei einer Einrichtung auf einer Windows-Maschine empfiehlt sich dafür der Client
TortoiseSVN. Der Link zum Solr-Trunk und der SVN-Befehl um an den Sourcecode zu kommen lautet:
svn checkout https://svn.apache.org/repos/asf/lucene/dev/trunk/ lucene-solr

Servlet-Engine installieren, oder was ist “RunJettyRun”

Solr benötigt eine Servlet-Engine um lauffähig zu sein, wie z.B. Apache Tomcat od. Jetty.
Nach dem Installieren von Eclipse kann somit aus dem „Eclipse Market“ (Help->Eclipse Market) das Plugin „RunJettyRun“ heruntergeladen und installiert werden.

Solr bauen und in Eclipse importieren

Im nächsten Schritt wird im ausgecheckten Solr Source-Ordner der Befehl „ant eclipse“ ausgeführt, um ein eclipse-Projekt zu erstellen.
Anschliessend importieren wir das Projekt in unseren Eclipse-Workspace(File->Import->Existing Projects into Workspace->zur Source directory navigieren->Add und Finish).

Solr-Konfiguration anpassen

Bei Bedarf können jetzt das Solr-Schema(schema.xml) und die Solr-Configuration(solrconfig.xml) an die eigenen Bedürfnisse angepasst werden. Diese befinden sich im ausgecheckten Solr-Sourcecode unter solr/example/solr/conf/.
Eventuell sollte dabei auch die Data-Directory angepasst werden, der Pfad zum Index.
Diese Angabe befindet sich in der solrconfig.xml unter <dataDir>xxx<dataDir/>

Sollte bereits ein Index vorhanden sein(Segmente in der dataDir), und wird eine Änderung des Schemas vorgenommen, dann muss der alte Index gelöscht werden(Konsolenbefehl: rm -rf).

RunJettyRun konfigurieren

Als nächstet konfigurieren wir das RunJettyRun-Plugin in Eclipse.
Die Änderungen sind in den Screenshots zu sehen. Die Konfiguration ist unter RUN -> Run Configurations erreichbar.

Wie im ersten Screenshot der Konfiguration ersichtlich müssen der Port, der Context sowie der Link zur WebApp angegeben werden. Die Standard-Angaben dazu sind Port:8080 und Context /solr.

Der zweite Screenshot zeigt die nächste notwendige Anpassung. Unter VM-Arguments wird das Solr-Home Verzeichnis eingebunden. Mit „Run“ wird die Konfiguration beendet.

Erster Lauf

Beim Ausführen des Projekts über die Hauptleiste in Eclipse (run) fährt bei richtiger Konfiguration der Servlet-Container “Jetty” hoch.
Ist es der Fall, dann kann im Eclipse-eigenen Browser die Solr GUI unter http://localhost:8080/solr/ erreicht werden.

Index mit einem .csv-Import befüllen

Der Index ist beim ersten Start leer.
Eine Möglichkeit den Index zu füllen ist der CSV-Import.

Die Erstellung der .csv-Datei läuft wie folgt ab.
In der ersten Zeile werden die Namen der Index-Felder eingetragen(im Screenshot “text” und “title”). In der zweiten und den weiteren Zeilen der zu indizierende Inhalt.

Nach der Erstellung der Datei wird diese beispielweise mit einem Curl-Befehl an Solr übertragen:

curl http://localhost:8080/solr/update/csv  –data-binary @import.csv -H ‚Content-type:text/plain; charset=utf-8‘

Nach dem fehlerfreien Import sollten bei einer Suche im Index bereits die Ergebnisse zu sehen sein. Zu berücksichtigen ist dabei die voreingestellte Commit-Zeit, welche evtl. erst abgewartet werden muss damit Ergebnisse zu sehen sind.

Es läuft, was mache ich jetzt?

Die Änderungen am Quellcode, sei es Bug-Fixing oder die Entwicklung eigener neuer Komponenten können der Community bereitgestellt werden. Mehr dazu in den nachfolgenden Links.

http://lucene.apache.org/solr/
http://wiki.apache.org/solr/HowToContribute
http://wiki.apache.org/solr/SolrPlugins
http://wiki.apache.org/solr/SearchComponent

Wie ist Ihre Erfahrung mit dem Aufsetzen einer Entwicklermaschine für Apache Solr? Ich freue mich über weitere Tipps!

Note: Dieser Artikel ist eine Kopie des Blogposts, welchen ich bei sentric.ch verfasst habe.