UpdateRequestProcessors, Umwandlung von Daten bei der Eingabe in Solr

Aktualisierungsprozessoren gibt es schon seit langem, aber sie scheinen nicht viel Aufmerksamkeit erregt zu haben. Dieser Beitrag soll ihnen etwas mehr Aufmerksamkeit verschaffen und einen einfachen Anwendungsfall zeigen, auf den ich kürzlich gestoßen bin.

Ich gehe davon aus, dass Sie mit den Elementen des Solr-Schemas einigermaßen vertraut sind, insbesondere mit Analyseketten, gespeicherten/indizierten Daten usw. Daher komme ich gleich zur Sache.

Das Problem auf höchster Ebene

Wie Sie wahrscheinlich bereits wissen, gibt es eine ganze Reihe von Transformationen, die Sie auf den analysierten Text als Teil der in Ihrer schema.xml definierten Analyseketten anwenden können. Hier finden Sie eine unvollständige Liste von Analyzern und Tokenizern. Es gibt jedoch zwei Vorbehalte bei diesen:

1. All dies funktioniert nur mit Daten , nachdem sie den „Daten/Index-Zweig“ (mehr dazu weiter unten) durchlaufen haben und auf dem Weg zum indizierten (nicht gespeicherten) Zweig sind.
2. Diese können nicht mit Nicht-Text-Typen (z.B. Datum, numerisch, etc.) verwendet werden.

Der Daten/Index-Zweig

Dies ist ein Begriff, den ich selbst erfunden habe. Angenommen, Sie haben ein Feld mit ‚indexed=“true“ stored=“true“ ‚ definiert. Im Großen und Ganzen sieht das so aus:

input stream |
             |
         _____________
        |             |
     stored data      |
                  analysis chain
                      |
                    index

Das Entscheidende dabei ist, dass der rohe Eingabestrom aufgeteilt und unabhängig voneinander an die gespeicherte Abzweigung und die Indexabzweigung gesendet wird. Nehmen wir an, Sie haben eine Eingabe wie diese: „Die Flöhe meines Hundes waren am 24-Mai 2010 schlimm“. Nehmen wir weiter an, Sie möchten das Datum auslesen und in ein tdate-Feld eingeben sowie einen Teil oder die gesamte Eingabe in einem Textfeld suchen lassen. Wie würden Sie vorgehen? Eine Möglichkeit ist natürlich, einen eigenen Aktualisierungsprozessor zu schreiben. Das ist zwar durchaus sinnvoll, bringt aber einige Kosten mit sich, die Sie vielleicht nicht auf sich nehmen wollen, wenn Sie sicherstellen wollen, dass alle Ihre Knoten in einem SolrCloud-Cluster mit 100 Knoten das richtige Jar am richtigen Ort haben.

Gut, sagen Sie. Ich füge einfach ein CopyField aus dem Textfeld in ein tdate-Feld ein, wende einen Regex darauf an, um 24-Mai, 2010 herauszuziehen und es in ein richtiges Solr-Datum wie 2010-05-24T00:00:00Z umzuwandeln, und alles ist gut. Sie arbeiten also mit Ihrem Lieblings-Regex-Tool, erstellen einen wunderbaren regulären Ausdruck, der genau das tut, was Sie wollen, und fügen eine PatternReplaceCharFilterFactory in Ihr Datumsfeld ein und… Ups. tdate (und die anderen ‚primitiven‘ Typen wie int/tint, float/tfloat usw.) haben keine Analyseketten. Übrigens war Uwe Schindler so freundlich, mich darauf hinzuweisen, dass es nicht trivial ist, primitive Typen mit Analyseketten auszustatten.

Und selbst wenn Sie dies tun könnten, wären die gespeicherten Daten immer noch der ursprüngliche Text „Die Flöhe meines Hundes waren am 24-Mai 2010 schlimm“, was für einen Benutzer sehr verwirrend wäre, wenn er ein solches Datumsfeld in einem Dokument sehen würde (denken Sie daran, dass Sie die ursprüngliche Eingabe erhalten, wenn Sie ein Feld angeben, das zurückgegeben werden soll).

Update Prozessoren, wo sie in das Schema der Dinge passen

Schauen wir uns an, wie sich dieses Bild mit Update-Prozessoren verändert:

input stream |
             |
        update processor(s)
             |
         ____|_________
        |             |
     stored data      |
                  analysis chain
                      |
                    index

Beachten Sie, dass der Aktualisierungsprozessor in der Kette vor der Daten/Index-Abzweigung steht. Das bedeutet, dass alle Transformationen, die Sie an der Eingabe vornehmen, sich sowohl in den gespeicherten Daten als auch in den indizierten Daten widerspiegeln.

Welche Prozessoren gibt es bereits?

Wie Sie sich vielleicht vorstellen können, gibt es bereits mehrere davon. Nun, mehr als mehrere. Ich habe über 30 gezählt, ohne es überhaupt zu versuchen. Alexandre Rafalovitch arbeitet gerade an einer umfassenden Auflistung mit Links hier. Schauen wir uns in der Zwischenzeit einen Anwendungsfall an.

Ein einfaches Problem:

Sie haben Texteingaben, die entweder Kommas (,) oder Punkte(.) als Einheitentrennzeichen verwenden können. 1.000.000,00 und 1.000.000,00 sind gleichwertig und Sie möchten

1. Setzen Sie sie in ein tfloat-Feld
2. Konvertieren Sie sie in ein einziges Eingabeformat

Es sollte ganz einfach sein, verwenden Sie einfach ein copyField und… äh… denken Sie daran, dass Sie nichts in die Analysekette für einen primitiven Typ einfügen können. Sehen Sie sich das Diagramm oben noch einmal an, ein Aktualisierungsprozessor ist genau das Richtige!

Es gibt zwei Arten von Update-Prozessoren.

• UpdateRequestProcessor
• ScriptUpdateProcessor. Eigentlich ist dies ein spezieller UpdateRequestProcessor, aber ich möchte ihn besonders hervorheben, siehe unten.

Beide erfordern, dass Sie einige Konfigurationsänderungen vornehmen, und beide sind sehr leistungsfähig. Die Arbeit wird in einer Methode (ich verwende Java) mit einer Signatur von

processAdd(AddUpdateCommand cmd)

Die Variable „cmd“ ermöglicht den Zugriff auf das SolrInputDocument, das alle Felder und Werte für das Solr-Dokument enthält, und auf SolrQueryRequest, eine Schnittstelle, die Ihnen den Zugriff auf alle Informationen über die Anfrage ermöglicht. Sie können sich also vorstellen, dass Sie hier die Informationen haben, um so ziemlich alles zu tun, was Sie wollen.

Sie passen beide an die gleiche Stelle in der Eingabe-Pipeline, wie oben beschrieben.

Worin besteht also der Unterschied?

Der Unterschied besteht darin, dass der Skriptaktualisierungsprozessor keine Jar-Datei benötigt, um zu funktionieren, sondern lediglich eine Skriptdatei, die im conf-Verzeichnis mitgeführt wird. Hmmm, das scheint ein trivialer Unterschied zu sein. Ich meine, Sie müssen immer noch Ihre solrconfig.xml Datei ändern, den Code debuggen und all das.

Das stimmt. Aber für den Skriptaktualisierungsprozessor können Sie SolrCloud die Verteilung für Sie übernehmen lassen. Wenn Sie eine jar-Datei haben, die Ihr laufendes Solr benötigt, um zu funktionieren, sind Sie dafür verantwortlich, dass alle Knoten in Ihrem Cluster die jar-Datei an der richtigen Stelle haben. Und dass es auf dem neuesten Stand ist. Das kann ziemlich mühsam sein, es sei denn, Sie packen Ihre jar-Datei mit dem war (oder ear oder was auch immer) neu. Auch das kann mühsam sein.

Nicht so bei der Skriptversion. Da sie sich im Verzeichnis „conf“ befindet, wird sie von ZooKeeper gespeichert (natürlich müssen Sie sie dort ablegen). Von da an fragt ZooKeeper bei jedem Neuladen eines Solr-Kerns: „Hat sich meine Konfiguration geändert?“. Wenn ja, werden alle geänderten Dateien lokal heruntergeladen und „funktionieren“ einfach. Insbesondere da
Sie Knoten in Ihrer Sammlung hinzufügen oder verschieben, müssen Sie nicht daran denken, auch Ihr jar zu verschieben.

Sie können sich vorstellen, wie dies die Verwaltung gegenüber der Jar-Variante vereinfachen würde. Sie erstellen/testen Ihr Skript an einem Ort und übertragen es dann an ZK. Laden Sie Ihre Sammlung neu und Sie sind fertig.

Fazit

Update-Prozessoren verdienen mehr Wertschätzung. Sie haben Vorteile bei der Verarbeitung von Daten, insbesondere wenn Sie Daten aus einem Feld extrahieren und in ein anderes einfügen und dabei umwandeln. Und ganz besonders, wenn Sie von textuellen Daten zu „primitiven“ Typen übergehen, da primitive Typen keine Analyseketten haben.

Einen benutzerdefinierten Update-Prozessor in Java zu erstellen und das jar in Ihrem Klassenpfad für verschiedene Webcontainer mitzuführen, ist sicherlich machbar. Mit dem Skript-Aktualisierungsprozessor können Sie jedoch eine beliebige Skriptsprache verwenden und den Code automatisch an alle Knoten in einem SolrCloud-Cluster verteilen lassen.

Sie können die Variante verwenden, mit der Sie sich am wohlsten fühlen. Sie können den Prozess natürlich auch nach vorne verlagern und den Prozess, der die Dokumente in Solr einspeist, die Arbeit erledigen lassen. Welchen Weg Sie wählen, hängt von Ihrer speziellen Situation ab.

Und vergessen Sie nicht die vielen aktualisierten Prozessoren aus der Konserve, die Sie sofort verwenden können! Alexandre Rafalovitch erstellt eine Liste davon, ein großes Lob an ihn! Und ich wäre nachlässig, wenn ich Erik Hatchers Arbeit an den ScriptUpdateProcessors nicht erwähnen würde!