Verbessern Sie zwischengespeicherte Filterabfrageergebnisse
Oder „Wie Sie niemals zwischengespeicherte Filterabfrageergebnisse wiederverwenden, obwohl Sie es vorhatten“: Filterabfragen („fq“-Klauseln) sind ein Mittel, um die Anzahl der…
Oder „Wie Sie niemals zwischengespeicherte Filterabfrageergebnisse wiederverwenden, obwohl Sie es vorhatten“:
Filterabfragen („fq“-Klauseln) sind ein Mittel, um die Anzahl der Dokumente einzuschränken, die für die Auswertung berücksichtigt werden. Eine häufige Verwendung von „fq“-Klauseln ist die Einschränkung des Datums der zurückgegebenen Dokumente, wie z.B. „am letzten Tag“, „in der letzten Woche“ usw. Dieses Muster wird häufig in Verbindung mit Facettierung verwendet. Filterabfragen verwenden einen filterCache (siehe solrconfig.xml), um die Menge der Dokumente, die der Abfrage entsprechen, einmal zu berechnen und dann diese Ergebnismenge wieder zu verwenden. Die Verwendung von NOW in Filterabfragen führt oft dazu, dass dieses Caching nutzlos ist. Hier ist der Grund dafür.
Solr verwaltet einen filterCache, in dem es die Ergebnisse von „fq“-Klauseln speichert. Sie können sich das wie eine Karte vorstellen, bei der der Schlüssel die „fq“-Klausel und der Wert die Menge der Dokumente ist, die diese Klausel erfüllen. Ich werde nicht näher darauf eingehen, wie der Dokumentensatz (der „Wert“ in dieser Map) gespeichert wird, da sich dieser Beitrag auf den Schlüssel konzentriert.
Nehmen wir also an, Sie haben zwei Filterabfragen (ob sie in derselben Abfrage stehen oder nicht, ist irrelevant), etwa so: „fq=Kategorie:Bücher&fq=Quelle:Bibliothek“. Im filterCache gibt es dann zwei Einträge, etwa so:
category:books => 1, 2, 5, 89…
source:library => 2, 5, 7, 45, 101…
Alles schön und gut bis jetzt. Ich werde hier noch eine kleine Ablenkung hinzufügen. Es geht darum, warum es oft besser ist, mehrere „fq“-Klauseln zu haben als eine einzige. Die gleichen Ergebnisse könnten mit „fq=category:books AND source:library“ erzielt werden, aber dann würde der Filter-Cache wie folgt aussehen:
category:books AND source:library => 2, 5…..
und eine fq-Klausel wie „fq=kategorie:bücher“ würde den Cache-Eintrag NICHT wiederverwenden, da der Schlüssel sehr unterschiedlich ist, ganz zu schweigen von der Ergebnismenge. Davon abgesehen kann jede Klausel, die OR enthält, nicht als separate fq-Klauseln ausgedrückt werden, da separate fq-Klauseln Schnittmengenoperationen (AND) sind. Aber genug der Ablenkung…
OK, Sie haben Daten erwähnt. Kommen Sie auf den Punkt.
Es ist üblich, Datumsbereiche als Filterabfragen zu verwenden, wie z.B. „am letzten Tag“, „in der letzten Woche“ usw. Und es gibt die praktische Datumsmathematik, die dies vereinfacht. Es ist also verlockend, sehr verlockend, Filterklauseln für Datumsbereiche wie „fq=date:[NOW-1DAY TO NOW]“ zu verwenden. Seien Sie vorsichtig bei der Verwendung von NOW!
Hier ist das Problem. Im obigen Beispiel wird nicht das Datum:[NOW-1DAY TO NOW] als Schlüssel für die fq im filterCache verwendet, sondern die Erweiterung als Schlüssel. Dies bedeutet eine Form wie: „date:[2012-01-20T08:56:23ZTO 2012-01-27T8:56:23Z]“ für den Schlüssel im filterCache. Nun fügt der Benutzer dem „q“ einen Begriff hinzu und sendet die Abfrage 30 Sekunden nach der ersten erneut ab. Die fq-Klausel sieht nun etwa so aus: „fq=date:[2012-01-20T08:56:53ZTO 2012-01-27T8:56:53Z]“ Beachten Sie, dass die Sekunden von 23 auf 53 gestiegen sind!
Der Schlüssel für diese Anfrage stimmt nicht mit dem Schlüssel für die erste überein, obwohl es oft die Absicht ist, dass die Übermittlung dieser Art von Anfrage 30 Sekunden später zu der gleichen Menge von Dokumenten führt, die dem Filter entsprechen. Nackte JETZT-Einträge in Filterklauseln garantieren, dass die zwischengespeicherten Ergebnismengen niemals wiederverwendet werden.
Gut. Was können Sie tun, um es besser zu machen?
Hier macht das Runden Sinn. Die Verwendung von Mitternacht kann aus zwei Perspektiven sinnvoll sein.
- Der Sinn, den Sie oft suchen, ist „alles mit einem Zeitstempel an einem bestimmten Tag“ (oder Monat oder Jahr oder Stunde oder ….). Wenn Sie also nur JETZT für die untere Grenze verwenden, würde alles fehlen, was zwischen Mitternacht und dem Tag (in diesem Beispiel), an dem der Benutzer die Abfrage stellt, veröffentlicht wurde.
- Die Wiederverwendung des Filter-Caches kann Ihre Abfragen erheblich beschleunigen, insbesondere wenn Sie Links wie „am letzten Tag“, „vor 1-7 Tagen“ usw. anbieten.
Ihre fq-Klauseln sehen dann so aus: „fq=date:[NOW/DAY-7DAYS TO NOW/DAY+1DAY]“. Beachten Sie, dass es sich bei dem mathematischen Operator „/“ um einen Abrundungsoperator handelt. Lassen Sie uns das also ein wenig aufschlüsseln: NOW/DAY rundet auf Mitternacht letzte Nacht ab. -7DAYS subtrahiert 7 ganze Tage. Die untere Grenze ist also wirklich „Mitternacht vor 7 Tagen“. In ähnlicher Weise rundet NOW/DAY auf Mitternacht letzte Nacht und +1DAY verschiebt das auf Mitternacht heute Abend als obere Grenze. Diese Klauseln sind bis nach Mitternacht unveränderlich, so dass diese Klauseln den ganzen Tag über dieselben Ergebnisse liefern werden. Nur die erste Übermittlung dieser fq verursacht Kosten, um herauszufinden, welche Dokumente ihr entsprechen. Natürlich werden die Caches ungültig, wenn Sie Ihren Index aktualisieren und/oder eine Replikation stattfindet, aber das ist immer der Fall.
Sie werden feststellen, dass es hier ein wenig „Schwankungen“ gibt. Wenn Ihr Index Daten enthält, die in der Zukunft liegen, können Sie diese auch erhalten. Nehmen wir an, Sie haben eine Situation, in der Ihr Index Dokumente enthält, von denen Sie nicht wollen, dass die Benutzer sie erst sehen, wenn sie später als ihr Zeitstempel sind. Es fällt mir schwer, hier ein Beispiel zu erfinden, aber nehmen wir einfach an, dass dies der Fall ist. Nehmen wir weiter an, es ist Mittag und Ihr Index enthält Zeitstempel von Dokumenten bis heute um Mitternacht. Mit der obigen Technik werden Dokumente angezeigt, die offiziell um, sagen wir, 15:00 Uhr veröffentlicht werden, obwohl es erst 12:00 Uhr ist und Sie das vielleicht nicht wollen. In diesem Fall müssen Sie eine reine NOW-Klausel verwenden und damit leben, dass Ihr Cache nicht für diese Klauseln verwendet wird. Wie ich schon sagte, ist dies etwas konstruiert, aber ich erwähne es nur der Vollständigkeit halber.
Ein paar Anmerkungen zu den Daten:
Bevor ich zum Schluss komme, noch ein paar Anmerkungen zu den Daten.
- Verwenden Sie die gröbsten Datumsangaben, die Sie finden können und die trotzdem Ihrem Anwendungsfall entsprechen. Dies gilt insbesondere, wenn Sie nach Datum sortieren. Der Ressourcenbedarf für die Sortierung steigt mit der Anzahl der eindeutigen Begriffe. Die Speicherung von Millisekundenauflösungen, wenn Sie sich nur für den Tag interessieren, kann also eine Verschwendung sein. Dies gilt auch für das Facettieren.
- Es ist oft nützlich, mehrere Felder mit Datumsdaten zu indizieren, insbesondere wenn Sie beabsichtigen, eine Facette zu erstellen.
- Die obigen Beispiele in der 3.x-Codezeile haben ein kleines Problem, wenn mehr als ein angrenzender Bereich erforderlich ist. Der Bereichsoperator „[]“ ist inklusiv. Wenn Sie also in diesen Beispielen ein Dokument haben, das genau um Mitternacht indiziert ist, könnte es in zwei Bereichen enthalten sein. Trunk Solr (4.0) erlaubt das Mischen von inklusiven „[]“ und exklusiven „{}“ Endpunkten, so dass Ausdrücke wie „date:[NOW/DAY-1DAY TO NOW/DAY+1DAY}“ möglich sind.
- Eine Übung für den Leser: Welche Folgen hat die Verwendung verschiedener Arten der Rundung? Z.B. JETZT/5MIN, JETZT/72MIN (funktioniert das überhaupt?).