Suche
Search Bites

Apache Lucene und Solr 7.0 veröffentlicht: Neue Index-Replika-Verfahren, bessere APIs und parallele Indexierung

Uwe Schindler

Das Apache-Lucene-Team hat Apache Lucene und Apache Solr in der Version 7.0 veröffentlicht. Uwe Schindler erklärt in seiner Kolumne Search Bites die wichtigsten Neuerungen.

Beim Update auf die Version 7.0 hat der Enterprise-Such-Server Apache Solr, der auf der Apache-Lucene-Volltext-Bibliothek aufbaut, die meisten Veränderungen abbekommen. Hier wurden in der neuen Version zahlreiche jahrelang mitgeschleppte Altlasten aufgeräumt aber eben auch interessante Neuerungen eingebaut: Benutzer der Solr Cloud können sich über neue Index-Replika-Verfahren freuen. Standard bleibt aber weiterhin die mit Solr Cloud eingeführten Transaktionslog-basierte NRT-Replizierung, bei der neu indexierte Dokumente in der Cloud umher geschickt werden und auf allen Replikas separat neu indexiert werden. Da dies auf den Suchcluster einen großen Overhead hat, haben viele Leute nach eine Variante der Replikation gefragt, die man aus der Anfangszeit von Apache Solr kennt: Die Indexierung wird nur auf einem Master durchgeführt und bei jedem Commit der geänderte Index über das Netzwerk zum Replika geschoben. Dieser in Solr Cloud nun PULL genannte Replika-Typ hat genau diese Eigenschaft. Das hilft vor allem in Umgebungen, in denen Bulk-Indexing durchgeführt wird und man einen Knoten als Indexer ausgibt. Die Replika, die hauptsächlich für Suche eingesetzt werden, bekommen die Änderungen erst mit, wenn ein Commit auf dem Master durchgeführt wird. Neben diesen zwei gegenteiligen Verfahren gibt es in Solr 7 auch noch ein Zwischending, das auch den Index als ganzes repliziert. Aber es ist trotzdem über das Transaktionslog möglich, Dokumente an alle Nodes zur Indexierung  zu schicken, aber dass nur einen Node die Arbeit wirklich ausführt. Generell sollte man weiterhin den NRT-Replica-Typ nutzen und nur in besonderen Fällen die neuen Typen benutzen.

APIs ausgebaut

Auch das bereits mit Solr 6.6 eingeführte neue REST-API für Solr wurde erweitert. Im Zuge dessen steht sie jetzt auch produktiv unter dem neuen URL-Endpunkt /api zur Verfügung. Dieser neue Endpunkt soll auf lange Sicht die altmodische und schwer zu benutzende CGI like API unter /solr ersetzen. Derzeit lassen sich damit viele Dinge für das Management von Collections/Cores und die Cloud-Konfiguration durchführen. Nach und nach werden dann auch das Indexieren oder Löschen von Dokumenten mit standardmäßigen PUT/POST/GET/DELETE-Operationen auf die Dokument-URI ersetzt werden. Leider ist man derzeit noch dazu gezwungen, teilweise parallel beide APIs zu benutzen. Auf jeden Fall lässt sich aber das neue API nun auch über den SolrJ Java Client nutzen.

In diesem Zusammenhang wurden auch neue Funktionen und die dazu passenden APIs unter dem Oberbegriff Autoscaling angesiedelt. Der Hintergrund ist, dass es schwierig ist, einen Cluster aus vielen Solr Nodes vernünftig zu verwalten, wenn sich der Cluster häufig ändert, weil zum Beispiel im Weihnachtsgeschäft neue Nodes zugeschaltet werden, um die Last besser verwalten zu können. In der Vergangenheit musste man hierfür oft manuell die Zuordnung von Shards und Replicas auf die Nodes anpassen, weshalb zahlreiche Kunden ihre eigenen APIs und Tools zum Management des Clusters implementiert haben. Um den Autoscaling-Prozess zu steuern, können Policies und Rules definiert werden, sodass bei Änderungen die Anpassungen im Cluster – also die Verteilung von Shards oder Replicas – automatisch durchgeführt werden können. Dies erspart dem Administrator das manuelle Anpassen und erlaubt es, gerade in der heißen Phase (Weihnachtsgeschäft), die Last gut zu verteilen. Das Autoscaling-API verhindert damit auch menschliche Fehler, die teilweise zum Ausfall von Clustern führen konnten. Die neue Solr-Komponente behält zum Beispiel auch den Festplattenplatzverbrauch der Index-Shards im Auge und verteilt diese anhand der Größe geschickter im Cluster.

Obacht: Schematypen deprecated

Darüberhinaus wurden in Solr zahlreiche alte Schematypen und Einstellungen in der Konfiguration deprecated und werden spätestens mit Version 8 verschwinden. So ist jetzt angesagt, auf die neuen PointFields umzustellen, welche die alten TrieFields für numerische Werte und geografische Koordinaten ersetzen. Diese wurden zwar schon in Solr 6.5 eingeführt, aber es hakte noch an einigen Stellen, sodass die alten TrieFields nicht für jeden Anwendungsfall ersetzt werden konnten. So funktionieren jetzt Facetten und andere Analytics auch korrekt mit PointFields.

Apache Lucene: Keine Probleme mehr bei paralleler Indexierung

Die unter Solr liegende Bibliothek Apache Lucene bekam in der Version 7 auch einiges Neues spendiert, was neben Apache Solr auch dem Projekt Elasticsearch zugute kommt: Obwohl Apache Lucene Dokumente problemlos mit mehreren Threads parallel indexieren kann, kam es bisher an einer Stelle trotzdem zu Engpässen: Löschoperationen mussten an einer zentralen Stelle aufeinander synchronisiert werden können, was dann auch Dokumentupdates, die aus einer Lösch- und einer anschließenden Indexierungoperation bestehen, sehr verlangsamt hatte. Lucene 7 ist nun in der Lage, auch das Löschen oder Änderungen an Docvalues-Feldern parallel abzuarbeiten. Dadurch müssen mehrere Aktualisierungsthreads nicht mehr aufeinander warten. Komplett entfernt aus diesem Release wurde die so genannte Query-Normalisierung und der Coordination Factor, der ein Relikt aus den Zeiten von TF-IDF ist. Damit war es möglich einige Optimierungen auch zur Query-Ausführung einzubauen, denn hierarchisch geschachtelte boolsche Ausdrücke können teilweise flach geklopft werden, ohne den Score zu verändern. Um ein bekanntes Verfahren zur Veränderung des Rankings von Suchergebnissen zu vereinfachen, nämlich das Stacking von Termen, wurde ein neues Indexing-Attribut hinzugefügt. Dieses erlaubt er, einen Term fiktiv im Quelldokument zu wiederholen, um dessen Signifikanz zu erhöhen. Dieses Attribut lässt sich in zahlreichen TokenFiltern einsetzen, aber Lucene 7 liefert auch einen Neuen extra zu diesem Zweck mit. Selbstverständlich enthält das Release auch zahlreiche Bugfixes, die oft aus Backwards-Kompatibilitätsgründen zurückgestellt wurden. Unter anderem ist es nun nicht mehr möglich, negative Offsets von Termen zu indexieren. An diesen scheiterten oftmals die Highlighter, welche die Suchterme in Suchergebnissen markieren sollten.

Lucene und Solr können schon mit Java 9

Apache Lucene und Solr 7.0 kommen fast zeitgleich mit Java 9 heraus und als eins der wenigen großen Java-basierten Serverprojekte kann das Projekt heute schon hundertprozentige Kompatibilität mit dem GA-Release von Java 9 garantieren. Alle User sind eingeladen, mit dem Update auf Apache Lucene/Solr 7 zeitgleich auch auf Java 9 zu aktualisieren, denn gerade mit der neuen Java-Version sind einige gravierende Performance-Sprünge bei Suchanfragen zu erwarten! Die Liste der Änderungen von Apache Lucene und Apache Solr sind auf der Projekt-Webseite zu finden.

Geschrieben von
Uwe Schindler
Uwe Schindler
Uwe Schindler ist Mitglied des Project Management Committee im Apache-Lucene-Projekt. Er ist mit seiner Consulting-Firma SD DataSolutions GmbH in Bremen ansässig und kümmert sich am Zentrum für Marine Umweltwissenschaften (MARUM) um die Suche nach geowissenschaftlichen Daten in der Umweltdatenbank PANGAEA.Blog: http://blog.thetaphi.deTwitter: @ThetaPh1
Kommentare

Schreibe einen Kommentar

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