Erweiterte Filter-Zwischenspeicherung in Solr
Advanced Filter Caching ist eine relativ neue Funktion in Solr, die in Version 3.4 und höher verfügbar ist. Sie ermöglicht…
Advanced Filter Caching ist eine relativ neue Funktion in Solr, die in Version 3.4 und höher verfügbar ist. Sie ermöglicht eine genaue Kontrolle darüber, wie Solr mit Filterabfragen umgeht, um die Leistung zu maximieren. Dazu gehört die Möglichkeit, festzulegen, ob ein Filter zwischengespeichert wird, in welcher Reihenfolge Filter ausgewertet werden und wie die Filter nach der Auswertung aussehen.
Filterabfragen in Solr
Das Hinzufügen eines Filters in Form einer Abfrage zu einer Solr-Anfrage ist ein Kinderspiel… fügen Sie einfach einen zusätzlichen fq-Parameter für jede Filterabfrage hinzu.
http://localhost:8983/solr/select? q=cars &fq=color:red &fq=model:Corvette &fq=year:[2005 TO *]
Standardmäßig löst Solr alle Filter *vor* der Hauptabfrage auf. Jede Filterabfrage wird einzeln im filterCache von Solr nachgeschlagen (der selbst ziemlich fortschrittlich ist und gleichzeitige Suchvorgänge, verschiedene Auslagerungsrichtlinien wie LRU oder LFU und Auto-Warming unterstützt). Das separate Zwischenspeichern jeder Filterabfrage beschleunigt den Abfragedurchsatz von Solr, indem es die Trefferquote im Cache erheblich verbessert, da viele Filtertypen bei verschiedenen Abfragen wiederverwendet werden.
Cache oder nicht Cache
Die neue erweiterte Filtersteuerungs-API bietet die Möglichkeit, einen Filter *nicht* zwischenzuspeichern. Einige Filter werden bei verschiedenen Anfragen kaum wiederverwendet, und wenn Sie nicht versuchen, sie zwischenzuspeichern, kann dies zu einem kleineren, effektiveren filterCache mit einer höheren Trefferquote führen.
Um Solr mitzuteilen, dass ein Filter nicht zwischengespeichert werden soll, verwenden wir dieselbe leistungsstarke localParam-DSL, die Metadaten zu Abfrageparametern hinzufügt und verwendet wird, um verschiedene Arten von Abfragesyntaxen und Abfrageparsern anzugeben. Für eine normale Abfrage, die keine localParam-Metadaten enthält, fügen Sie einfach einen local param mit cache=false hinzu. Zum Beispiel:
&fq={!cache=false}year:[2005 TO *]
Um cache=false zu einer Filterabfrage hinzuzufügen, die bereits localParams enthält, fügen Sie es einfach zusammen mit den übrigen Parametern ein. Wenn wir zum Beispiel die nativen räumlichen Fähigkeiten von Solr nutzen möchten, um unsere Treffer auf Orte in einem Umkreis von 50 km von Stanford zu beschränken, würde unsere Filterabfrage wie folgt aussehen:
&fq={!geofilt sfield=location pt=37.42,-122.17 d=50}
Es ist einfach, diesen Filter so zu ändern , dass Solr ihn nicht zwischenspeichert, indem Sie cache=false zu den übrigen lokalen Parametern hinzufügen:
&fq={!geofilt sfield=location pt=37.42,-122.17 d=50 cache=false}
Leapfrog gefällig?
Wenn ein Filter nicht im Voraus erstellt und zwischengespeichert wird, wird er parallel zur Hauptabfrage ausgeführt. Zunächst wird der Filter nach der ersten Dokument-ID gefragt, auf die er passt. Dann wird die Abfrage nach dem ersten Dokument gestellt, das gleich oder größer ist als dieses Dokument. Der Filter wird dann nach dem ersten Dokument gefragt, das gleich oder größer als dieses ist. Der Filter und die Abfrage spielen so lange „Bockspringen“, bis sie auf demselben Dokument landen und es als übereinstimmend erklärt wird, woraufhin das Dokument gesammelt und bewertet wird.
Wie viel kostet dieser Filter?
Die erweiterte Filterung ermöglicht eine noch feinere Kontrolle, indem der Begriff der Kosten eingeführt wird. Wenn eine Antwort mehrere nicht zwischengespeicherte Filter enthält, werden die Filter mit den niedrigeren Kosten vor denen mit den höheren Kosten geprüft.
&fq={!cache=false cost=10}year:[2005 TO *]
&fq={!geofilt cache=false cost=20}
&pt=37.42,-122.17
&sfield=location
&d=50
Im obigen Beispiel hat der auf dem Jahr basierende Filter die geringeren Kosten und wird daher immer vor dem räumlichen Filter geprüft.
Beachten Sie nebenbei, dass räumliche Abfragen globale räumliche Anfrageparameter verwenden, wenn sie nicht lokal angegeben sind. Dies macht es noch einfacher, Anfragen mit räumlichen Funktionen zu erstellen.
Teure Filter
Einige Filter sind so langsam, dass Sie sie nicht einmal parallel zur Abfrage und zu anderen Filtern laufen lassen sollten, selbst wenn sie als letztes konsultiert werden, da die Frage „Welches ist das nächste Dokument, das Sie mit oder nach diesem Dokument abgleichen? Für diese Art von Filtern sollten Sie die Frage „Passen Sie zu diesem Dokument?“ erst stellen , nachdem die Abfrage und alle anderen Filter konsultiert wurden. Solr bietet hierfür eine spezielle Unterstützung, die sogenannte„Post-Filterung„.
Die Post-Filterung wird von Filtern ausgelöst, deren Kosten>=100 sind und die explizit dafür unterstützt werden. Wenn mehrere Postfilter in einer Anfrage enthalten sind, werden sie nach Kosten geordnet.
Der frange qparser unterstützt Postfilter und ermöglicht leistungsstarke Abfragen, die Bereiche über beliebig komplexe Funktionsabfragen spezifizieren.
Wenn wir zum Beispiel den Logarithmus der Popularität nehmen, ihn durch die Quadratwurzel des Abstands teilen und Dokumente mit einem Ergebnis von weniger als 5 herausfiltern möchten, könnten wir dies als Postfilter mit frange ausführen:
&fq={!frange l=5 cache=false cost=200}div(log(popularity),sqrt(geodist()))
Die Postfilterunterstützung für die räumlichen Filterabfragen bbox und geofilt wurde gerade zu Solr 4.0 hinzugefügt. Um unseren früheren, nicht zwischengespeicherten räumlichen Filter als Postfilter auszuführen, ändern Sie einfach seine Kosten, so dass sie größer als 100 sind:
&fq={!geofilt cache=false cost=150}
&pt=37.42,-122.17
&sfield=location
&d=50
Benutzerdefinierte Filter
Wenn Sie eine teure benutzerdefinierte Logik als Postfilter hinzufügen möchten (z.B. benutzerdefinierte Sicherheits-ACLs pro Dokument), können Sie Ihr eigenes QParserPlugin implementieren, das Abfrageobjekte zurückgibt, die die PostFilter-Schnittstelle von Solr implementieren. Sie können die Standardkosten festlegen oder einen Wert von mehr als 100 eingeben, wenn Sie nur die Post-Filterung unterstützen möchten. Dann können Sie Ihren benutzerdefinierten Parser wie jeden anderen eingebauten Abfragetyp über fq={!myqueryparser} verwenden und Solr erledigt den Rest!
Probieren Sie es aus!
Abschließend hoffe ich, dass dies einen Einblick in einen der vielen Faktoren gibt, die unter der Haube arbeiten und Solr so schnell machen.
Um die neuesten Funktionen auszuprobieren, können Sie jederzeit ein Nightly Build von Trunk herunterladen. Feedback ist immer willkommen!