Dates, Date Boosting und JETZT

Mehr JETZT böse

Angeregt durch ein subtiles Problem, das ein Kunde aufgeworfen hat, habe ich über das Boosten nach Datum nachgedacht. Laut Wiki ist eine gute Möglichkeit, nach Datum zu boosten, etwa die folgende:

http://localhost:8983/solr/select?q={!boost b=recip(ms(NOW,manufacturedate_dt),3.16e-11,1,1)}ipod

(siehe: Link zur Datumsanzeige). Und das funktioniert gut, keine Frage.

Beim Paging gibt es jedoch ein kleines Problem. NOW bezieht sich auf die aktuelle Zeit, und jede nachfolgende Abfrage hat einen anderen Wert für NOW. Dieser Blog-Beitrag über die Auswirkungen dieser Tatsache auf Filterabfragen liefert einige nützliche Hintergrundinformationen.

Was hat das mit Date-Boosting zu tun?

Stellen Sie sich vor, Sie haben mehrere Seiten mit Ergebnissen. Normalerweise konstruiert man eine Reihe von Seitenlinks, um zu den nachfolgenden Seiten zu gelangen, etwa so
http://your solr addr/select?q=searchterms&start=10&rows=10
aber Sie müssen auch die Datumserhöhung hinzufügen, richtig? An jede dieser URLs wird also der Datumsboost von oben angehängt (oder Sie haben dies in Ihren Standardparametern in solrconfig.xml). Und genau hier verursacht dieses Fragment ein „interessantes“ Verhalten ms(NOW,manufacturedate_dt)
Hier gibt es zwei Probleme.

1. Sie können die Ergebnisse beim Blättern wiederholen oder überspringen. Dies liegt an der „Aufteilung“ der Ergebnisse. Ein paar Sekunden können die Boost-Berechnungen so verändern, dass einige Dokumente beim Blättern übersprungen oder wiederholt werden.
2. Ihr queryResultCache ist nutzlos.

Ein kurzer Überblick über queryResultCache

Der queryResultCache ist lediglich eine Abbildung der Abfrage und einer gewissen Anzahl von Dokumenten, die in dieser Reihenfolge die Ergebnisse dieser Suche sind. Wie viele Dokumente im Cache gespeichert werden, ist in solrconfig.xml konfigurierbar. Normalerweise werden 2 oder 3 Seiten mit Ergebnissen pro Abfrage gespeichert. Dies ist ausreichend, um die übliche Benutzererfahrung zu bewältigen; selten blättern die Benutzer zur zweiten Seite, geschweige denn zur dritten. Wenn eine Seitenanfrage eingeht, bei der die Ergebnisse nicht im queryResultCache enthalten sind, wird die Abfrage erneut ausgeführt.

Aber, und das ist für diese Diskussion von entscheidender Bedeutung, die Verwendung von NOW beim Date-Boosting bedeutet, dass keine Abfrage, die Date-Boosting verwendet, jemals aus dem queryResultCache geholt wird!

Ich übertreibe ein wenig. Es ist möglich, mit der Datumsverstärkungsfunktion begrenzte „Datumsberechnungen“ durchzuführen. Dinge wie …ms(NOW/MINUTE,manufacturedate_dt)…. sind möglich. Mit dieser Technik wird das Problem zwar verringert, aber nicht beseitigt.

Was kann man tun?

Mir ist noch kein sauberer Weg eingefallen, den Solr-Abfrageprozess zu ändern, um dies zu handhaben. Ich könnte mir einen neuen Parameter wie „nowIs=2012-03-28T10:30:29Z“ vorstellen, mit der Maßgabe, dass alle Verweise auf NOW in der Abfrage durch diesen Parameter ersetzt werden, aber das erscheint mir zu kompliziert. Ganz zu schweigen davon, dass dies viele Stellen betreffen würde, wenn man es richtig machen würde. Und ich garantiere Ihnen, dass es viel schwieriger wäre, als ich denke…

[Bearbeiten 12-Apr-2012]: Yonik hat mich auf SOLR-1729 hingewiesen, was Ihnen nur zeigt, wie viel ich weiß. In trunk und 3.6 können Sie einen harten Wert für NOW angeben. Zum Beispiel wird q={!boost%20b=recip(ms(NOW,manufacturedate_dt),3.16e-11,1,1)}ipod&NOW=1000 das in den Datumsberechnungen verwendete NOW durch 1000 ersetzen. Ich denke, dass dies das Problem behebt, ohne dass die App die URL bei Bedarf entsprechend konstruieren muss.

Eine andere Möglichkeit ist, dass Sie das Problem einschränken. Die Verwendung eines Ausdrucks wie NOW/DAY+1DAY würde das Problem auf Abfragen von Seitenanfragen beschränken, die über Mitternacht hinausgehen. Und dies wird sich auf die Bewertung der Dokumente auswirken, die heute in den Index aufgenommen werden. Beachten Sie bitte, dass Sie das ‚+‘ als %2B ausgeben müssen, wenn Sie dies mit einer Roh-URL versuchen.

Eine dritte Möglichkeit besteht darin, die Tatsache zu nutzen, dass Solr URL-Parameter, die es nicht versteht, gerne ignoriert. Sie könnten eine benutzerdefinierte QueryComponent erstellen und die Ersetzungen dort vornehmen. Dadurch haben Sie die Möglichkeit zu erkennen, dass sich Ihr Index geändert hat und die Abfrage in diesem Fall erneut auszuführen. Es gibt einige interessante neue Funktionen im SearcherLifetimeManager, siehe den Blogbeitrag von Mike McCandless hier, die ebenfalls hilfreich sein könnten, auch wenn ich sie mir noch nicht näher angesehen habe. Man könnte vielleicht einfach eine benutzerdefinierte Abfragekomponente schreiben, die „ms(NOW“ erkennt und die formatierte Zeit in der Abfrage ersetzt, aber alles, was so einfach ist, würde wahrscheinlich unerwartete Nebenwirkungen haben.

Eine andere Lösung besteht darin, die URLs für die Seitenaufrufe mit einer Rohzeit und nicht mit NOW zu erstellen. Dies würde wie folgt aussehen: b=recip(ms(2012-03-28T10:40:00Z,manufacturedate_dt),3.16e-11,1,1)}ipod

Die einfachste Lösung ist, das Problem ganz zu ignorieren. In erster Linie möchte ich Ihnen damit einen interessanten Einblick in die Feinheiten von NOW geben und zeigen, dass es Auswirkungen haben kann, mit denen Sie nicht rechnen. Wenn Sie daran interessiert sind, das letzte Quäntchen Leistung aus Ihren Solr-Instanzen herauszukitzeln, und wenn Sie viel mit dem Datum boosten, sollten Sie sich mit diesem „Problem“ befassen.

Aber abgesehen von der Datumsrundung (z.B. Verwendung von JETZT/TAG+1TAG anstelle des bloßen JETZT) würde ich so etwas nie tun, es sei denn, ich hätte einen absoluten Beweis dafür, dass ich das tun muss:

1. Jede Lösung, die diese Art von Prozess implementiert, kostet Zeit und Mühe, die Sie in andere Teile Ihrer Anwendung stecken könnten.
2. In den meisten Anwendungen werden Ihre Benutzer dies ohnehin nicht bemerken. Das einzige Mal, dass dies auffällt, ist, wenn Sie eine Seite aufrufen und zufällig auf einen Sonderfall stoßen. Die Benutzer gehen selten auf die zweite Seite der Suchergebnisse, so dass sich der Aufwand für die Programmierung/Qualitätssicherung kaum lohnt, es sei denn, es besteht ein nachgewiesener Bedarf.