Caches sind ein wesentlicher Faktor für die Performance des Search Servers Apache Solr. Nur wer diese Caches, ihre jeweilige Aufgabe und ihre Funktionsweise kennt, kann von Anfang an Performance-Engpässe vermeiden und das Maximale aus seiner Solr Installation herausholen.
In Solr gibt es im Gegensatz zur reinen Lucene API mehrere verschiedene Arten von Caches.
- FilterCache
- QueryCache
- DocumentCache
- FieldValueCache
- FieldCache (Lucene)
Diese Solr Caches, was Autowarming ist, wie dieses verwendet wird und was es dabei zu vermeiden gilt, erklärt dieser Beitrag.
FilterCache
Im FilterCache werden nur die Dokumente gehalten, die mit einer bestimmten Filterquery übereinstimmen. Jeder Eintrag im FilterCache ist durch ein Key-Value Paar representiert. Der Value besteht bei wenigen Dokumenten auf einer geordneten Liste von Dokument IDs und bei vielen Dokumenten aus einem unsortierten Bitset, da das Bitset weniger Speicher als das Int Array bei der sortierten Liste der Dokument IDs benötigt.
fq=doctyp:pdf -> 1, 332, 200, 4… (sortierte Liste, INT Array)
fq=doctyp:pdf -> 0,1,1,0,1,0,0… (unsortierte Liste, Bitset)
In diesen und allen folgenden Beispielen gehen wir von folgender Solr Anfrage aus:
server:port/solr?q=test&sort=price desc&fq=doctyp:pdf
QueryCache
Der QueryCache speichert die Dokument IDs, die auf eine bestimmte Kombination aus den Parametern q, sort und fq passen, als sortierte Liste. Dabei werden nicht alle Trefferdokumente gespeichert sondern nur eine bestimmte Anzahl, die in den Solr Konfigurationsdateien hinterlegt werden kann. Dies würde dann einen Key -> Value im Querycache ergeben der wie folgt aussehen könnte:
q=test&sort=price desc&fq=doctyp:pdf -> 1, 200, 332
Somit könnte bei der gleichen Anfrage die Trefferliste, ohne Suche, direkt aus dem Querycache ermittelt werden. Da auch die Sortierung gespeichert wird, entfällt auch das Scoring der Dokumente. In unserem Beispiel würde das Scoring aber immer entfallen da die Sortierung nicht nach scoring sondern dem Metafeld price statt findet.
DocumentCache
Der DocumentCache hält zu den bisher aufgerufenen Dokumenten die entsprechenden Metafelder die als stored gekennzeichnet sind. Er wird genutzt um schnellen Zugriff auf die in der Trefferliste darzustellenden Metafelder zu bekommen. Die Zuordung ist dabei wie folgt:
Docid-> Metafeld1 = test
Der DokumentCache kann im Gegensatz zu Filter- und QueryCache nicht explizit autowarmed werden.
FieldValueCache
Der FieldValueCache speichert immer alle möglichen Values zu einem Metafeld. Der FieldCache ist ähnlich dem FieldValueCache, jedoch ist er nicht im Solr-Server integriert sondern in Lucene selbst, und kann im Gegensatz zum FieldValueCache keine Multivaluefields verarbeiten. Er wird z.B. für die Sortierung verwendet.
Der FieldValueCache und der FieldCache können ebenfalls nicht explizit autowarmed werden.
Autowarming
Um die Frage zu klären was Autowarming ist, wann und wie dies gestartet wird müssen wir etwas weiter ausholen.
Die Caches sind immer einem Searcher zugeordnet. Es gibt immer nur einen Searcher der aktuelle Requests bearbeiten darf, in unserem Beispiel der Searcher1.
Der aktuelle Searcher kennt dabei immer nur den Teil des Index der zu seiner Initialisierung bereits vorhanden war. Neue Dokumente, die danach hinzugefügt wurden können über diesen Searcher nicht gefunden werden.
Ein neuer Searcher, in unserem Beispiel Searcher 2, wird immer dann erzeugt wenn ein „commit“ oder „optimize“ durchgeführt wurde. Searcher2 kennt dann sowohl die alten Indexsegmente als auch die neu hinzugefügten. Solange jedoch der Cache des Searcher2 nicht gefüllt ist werden aktuelle Requests immer noch an Searcher1 gesendet.
Nun wird der Searcher 2 autowarmed. Dabei werden erst alle Querys (die jeweiligen keys) aus dem FilterCache ausgeführt und dann die Querys + FQ + sort aus dem QueryCache. Dabei werden auch die anderen Caches indirekt befüllt da es sich um eine normale Suche handelt. Zusätzlich können über die Solr-Konfiguration noch Querys hinterlegt werden die entweder beim ersten Starten des Servers oder bei jedem neuen Searcher ausgeführt werden sollen. Besonderst das Ausführen von Querys beim ersten Start des Servers ist sinnvoll, da zu diesem Zeitpunkt noch keine Querys aus dem Cache des Vorläufer-Searchers geholt werden können. Effizient sind diese Firstsearcher Querys jedoch nur wenn Sie auch Querys ausführen die von den Benutzern später genauso benötigt werden.
Sobald der Searcher2 dann mit dem Aufwärmen seiner Caches fertig ist, übernimmt er die neuen Requests. Die bereits zu diesem Zeitpunkt eingetroffenen Requests werden noch vom Searcher1 beantwortet.
Sobald der letzte Request von Searcher1 beantwortet wurde beendet sich dieser.
Es sollte immer darauf geachtet werden nie mehr als einen Autowarmed Searcher zu erlauben,da dies sonst sehr schnell zu Engpässen bei Speicher oder Performance führen kann.
