Die Qualität einer Suche hängt von der Trefferliste ab. Selbstverständlich erwartet der Anwender das „richtige“ Dokument an erster Stelle. Aber auch die Informationen, die in der Trefferliste je Dokument angeboten werden, sind wichtig. Bisher musste man alle Informationen, die man in der Trefferliste anzeigen möchte, auch im Index ablegen. Dies führt zu einem größeren Index, schlechterer Performance und zu einer komplexeren Indexierungs-Strategie. Bestimmte Informationen, wie der „Preis eines Dokumentes“ oder das „Alter einer Person“, ändern sich regelmäßig und daher muss der Index immer wieder aktualisiert werden.
Mit den DocTransformern wird nun eine Möglichkeit geboten die von Apache Solr generierte Trefferliste zu beeinflussen, d.h. Felder bzw. Inhalte können generiert werden, die es nicht im Index gibt. Felder können manipuliert werden bevor sie an den Client geschickt werden. Felder können aber auch gelöscht werden. Mit DocTransformern kann der Index also kleiner werden, was sich wiederrum positiv auf die Performance auswirkt, und unter Umständen wird auch die Indexierung vereinfacht und beschleunigt.
Der Einsatz von DocTransformer birgt natürlich nicht nur Vorteile. Der wichtigste Nachteil auf den man sich einstallen muss, ist dass man die Daten, die über einen DocTransformer generiert werden, nicht durchsucht werden können. DocTransformer dienen allein der Erweiterung der Anzeige.
DocTransformer gibt es nun schon eine Weile. Daher ist es nicht verwunderlich, dass es auch schon eine Vielzahl von Implementierungen in das Solr Paket geschafft hat. Nachfolgend liste ich nur ein paar interessante DocTransformer auf:
- – Dieser DocTransformer ist vor allem in einem verteilten Setup wie der SolrCloud sehr hilfreich, denn er ermittelt den Shard in dem das Dokument gefunden worden ist. Dies ist vor allem beim (Relevanz) Debugging vorteilhaft.
- – Das Feature „elevate“ platziert Dokumente am Anfang einer Trefferliste. In der Trefferliste selbst erkennt man nicht ob ein Dokument durch dieses Feature platziert worden ist oder nicht. Dieser DocTransformer gibt true zurück wenn ein Dokument so an den Anfang der Trefferliste gekommen ist.
- – Dieser DocTransformer hängt „nested child“ Dokumente an das Trefferdokument an.
- – Mit diesem DocTransformer können nach der eigentlichen Suche noch weitere Solr Queries ausgeführt werden, um beispielsweise zusätzliche Felder anderer Dokumente anzuzeigen. Hiermit kann man beispielsweise den SQL JOIN nachbilden.
Den Link zur Beschreibung der aktuellen DocTransformer gibt es wie immer am Ende von diesem Blog.
Die Konfiguration bzw. Nutzung der DocTransformer ist relativ simple. Konfiguriert werden sie in der solrconfig.xml und aktiviert bzw. genutzt werden sie im „fl“ Parameter. Folgendes Beispiel zeigt wie eigene DocTransformer in solrconfig.xml konfiguriert werden.
<transformer name=“my_transformer_1″ class=“org.apache.solr.response.transform.MyTransformerFactory“ /> <transformer name=“my_transformer_2″ class=“org.apache.solr.response.transform.MyTransformerFactory“ > <double name=“defaultValue“>5</double> </transformer>Oben ist zu sehen, dass man die DocTransformer mit Parametern beeinflussen kann. Zusätzlich zu dieser statischen Konfiguration bieten manche DocTransformer die Möglichkeit Parameter im „fl“ Parameter mitzugeben, wie im folgenden Beispiel beim zu sehen ist:
…&fl=*,,Eigene DocTransformer erstellen
Apache Solr bringt, wie oben beschrieben, eine Vielzahl von vorgefertigten DocTransformern mit. Ausreichend ist dies meist jedoch nicht. In unseren Projekten stoßen wir immer wieder Situationen, wo wir projektspezifisch etwas implementieren müssen. Was sind also mögliche Szenarien für eigene DocTransformer:
- Felder hinzufügen: Auf Anzeige-Portalen ist es wichtig zu wissen, wie lange eine Produkt noch verfügbar ist bzw. wie viele Sekunden noch bleiben auf ein Produkt zu bieten. Diese Information steht nicht im Index, zumindest nicht sekundengenau. Mit einem DocTransformer kann man dies zur Anzeigezeit berechnet werden.
- Felder entfernen: Neben der klassischen dokument-basierten Sicherheit kann man mittels der DocTransformer beispielsweise eine feld-basierte Sicherheit implementieren. Je nach User kann man also Felder aus dem Treffer entfernen oder nicht.
- Felder modifizieren: Mittels DocTransformer lassen sich Daten beispielsweise in ein anderes Format bringen. Datumsformatierung beispielsweise können zwar auf dem Client durchgeführt werden, verbrauchen dann aber auch die Client-Ressourcen. Tut man dies bereits im Solr beschleunigt dies die reine Anzeigezeit der Trefferliste.
Um einen eigenen DocTransformer zu entwickeln muss man lediglich zwei Klassen implementieren. Wie bei fast jeder Solr Komponente gibt es eine Klasse für den funktionalen Code und eine Factory zum Konfigurieren der ersten Klasse. Das folgende Beispiel formatiert ein Feld vom Typ „date“ in ein gewünschtes Ausgabeformat. Hierfür wird die „dynamische“ Konfiguration verwendet.
Das folgende Bild zeigt die Factory. Man muss nur die Methode „create“ implementieren. In meinem Beispiel lese ich noch zwei Parameter (fl=*,) aus dem Request aus und nutze diese um die Logik der eigentlichen Implementierung zu beeinflussen.
Optional kann man noch die Methode „init“ implementieren. Hier könnte man Parameter auslesen, die in der solrconfig.xml für den DocTransformer konfiguriert worden sind.
Die Klasse mit der eigentlichen Logik zu implementieren ist auch nicht schwer. Es muss nur die Methode „transform“ implementiert werden. Im folgenden Beispiel werden alle Werte des betreffenden Feldes ausgelesen, denn es könnte ja ein multiValued Feld sein. Anschließend wird jeder einzelne Wert in einer Schleife in das richtige Format gebracht und unter neuen Namen im Solr Dokument gespeichert.
Fazit
DocTransformer sind super!!! DocTransformer bieten die Möglichkeit die Trefferliste bzw. die einzelnen Treffer zu manipulieren. Der Aufwand einen eigenen DocTransformer zu entwickeln ist verglichen zu dem Nutzen den er bringen kann minimal. Einen Performance Verlust muss man nicht befürchten, da DocTransformer nur für die Dokumente in der Trefferliste ausgeführt werden, d.h. nicht auf alle möglichen Treffer sondern nur auf die 10 (default), die von Solr ausgeliefert werden.
