SOLR Leistungsoptimierung

Question

SOLR Leistungsoptimierung

8

Ich habe Folgendes gelesen:

Ссылка

Und ich habe Fragen zu einigen Dingen:

Wenn ich die JVM-Option -XX:+UseCompressedStrings verwende, welche Art von Speicherersparnis kann ich erreichen? Um ein einfaches Beispiel zu behalten: Wenn ich 1 indiziertes Feld (string) und 1 gespeichertes Feld (string) mit omitNorms = true und omitTf = true habe, welche Art von Einsparungen im Index und im Dokumenten-Cache kann ich erwarten? Ich schätze ungefähr 50%, aber vielleicht ist das zu optimistisch.
Wann genau macht der Solr-Filter-Cache? Wenn ich nur eine einfache Abfrage mit AND und ein paar ORs mache und nach Punkten sortiere, brauche ich das überhaupt?
Wenn ich alle Dokumente im Dokumenten-Cache zwischenspeichern möchte, wie würde ich den benötigten Speicherplatz berechnen? Wenn ich 20M Dokumente verwende, verwende komprimierte Strings, und die durchschnittliche Länge des gespeicherten Felds beträgt 25 Zeichen, ist der benötigte Speicherplatz im Grunde (25 Bytes + small_admin_overhead) * 20M?
Wenn alle Dokumente im Dokumentencache sind, wie wichtig ist der Abfragecache?
Wenn ich jedes Dokument automatisch in den Doc-Cache umleiten möchte, wird die Abfrage für den Autowarm von *:* ausgeführt?
Der Artikel "scaling-lucene-and-solr" sagt, dass FuzzyQuery langsam ist. Wenn ich die Rechtschreibprüfung von solr verwende, dann benutze ich im Grunde die Fuzzy-Abfrage richtig (weil die Rechtschreibprüfung dieselbe Entfernungsberechnung durchführt)? Vermutlich sind also Rechtschreibprüfung und Fuzzy-Abfrage gleichermaßen "langsam"?
Der Abschnitt, der den lucene-Feld-Cache für Strings beschreibt, ist etwas verwirrend. Liest ich es richtig, dass der erforderliche Speicherplatz im Grunde genommen die Größe des indizierten Zeichenkettenfelds + eine Ganzzahl arry gleich der Anzahl der eindeutigen Begriffe in diesem Feld ist?
Schließlich gibt es unter Maximierung des Durchsatzes eine Aussage darüber, genügend Platz für den Betriebssystem-Plattencache zu lassen. Es heißt: "Alles in allem ist es für einen großen Index am besten, wenn Sie mindestens ein paar Gigabyte RAM haben, die über das hinausgehen, was Sie der JVM geben." Also, wenn ich eine 12GB Speichermaschine (als Beispiel) habe, sollte ich mindestens 2-3GB dem Betriebssystem geben? Kann ich den Speicherplatz auf dem Festplatten-Cache abschätzen, der vom Betriebssystem benötigt wird, indem ich die Indexgröße auf der Festplatte betrachte?

java solr lucene

Kevin 25.12.2011, 00:14

quelle

2 Antworten

5

Caches

Im Allgemeinen scheint Caching eine gute Idee zu sein, um die Leistung zu verbessern, aber das hat auch viele Probleme:

Cached-Objekte gehen wahrscheinlich in die alte Generation des Garbage Collectors ein, der teurer zu sammeln ist,
die Verwaltung von Einfügungen und Räumungen bringt zusätzlichen Aufwand.

Darüber hinaus verbessert Caching die Suchlatenz kaum, es sei denn, es gibt Muster in Ihren Abfragen. Wenn im Gegensatz dazu 20% des Datenverkehrs auf einige wenige Abfragen zurückzuführen sind, kann der Cache für Abfrageergebnisse interessant sein. Das Konfigurieren von Caches erfordert, dass Sie Ihre Abfragen und Ihre Dokumente sehr gut kennen. Wenn Sie dies nicht tun, sollten Sie wahrscheinlich das Caching deaktivieren.

Selbst wenn Sie alle Caches deaktivieren, kann die Leistung dank des OS-I / O-Caches immer noch ziemlich gut sein. Praktisch bedeutet dies, dass wenn Sie den gleichen Teil einer Datei immer wieder lesen, ist es wahrscheinlich, dass es nur beim ersten Mal vom Datenträger und dann vom E / A-Cache gelesen wird. Wenn Sie alle Caches deaktivieren, können Sie der JVM weniger Speicher zur Verfügung stellen, sodass mehr Speicher für den E / A-Cache zur Verfügung steht. Wenn Ihr System über 12 GB Arbeitsspeicher verfügt und Sie der JVM 2 GB zur Verfügung stellen, kann der E / A-Cache möglicherweise bis zu 10 GB Ihres Indexes zwischenspeichern (abhängig von anderen Anwendungen, die ebenfalls Arbeitsspeicher benötigen).

Ich empfehle Ihnen, dies zu lesen, um weitere Informationen zu Cache auf Anwendungsebene und zu E / A-Cache zu erhalten:

Ссылка

Feldcache

Die Größe des Feldcaches für eine Zeichenfolge ist (ein Array von ganzen Zahlen der Länge maxDoc) + (ein Array für alle eindeutigen Zeichenfolgeninstanzen). Wenn Sie also einen Index mit einem Zeichenfolgenfeld haben, das durchschnittlich N Instanzen der Größe S hat, und wenn Ihr Index M Dokumente hat, dann ist die Größe des Feldcache für dieses Feld ungefähr M * 4 + N * S .

Der Feldcache wird hauptsächlich für Facetten und Sortierung verwendet. Selbst sehr kurze Strings (weniger als 10 Zeichen) sind mehr als 40 Bytes , Das bedeutet, dass Sie erwarten sollten, dass Solr viel Speicher benötigt, wenn Sie ein String-Feld mit einer hohen Anzahl eindeutiger Werte sortieren oder in ein Facettenfeld einfügen.

Fuzzy-Abfrage

FuzzyQuery ist langsam in Lucene 3.x, aber viel schneller in Lucene 4.x.

Es kommt auf die von Ihnen gewählte Rechtschreibprüfung an, aber ich denke, dass die Rechtschreibprüfung von Solr 3.x N-Grams verwendet, um Kandidaten zu finden (deshalb benötigt sie einen dedizierten Index) und berechnet dann nur Abstände auf dieser Menge. Die Leistung ist also immer noch einigermaßen gut.

jpountz 26.12.2011 13:01

quelle

Tags und Links java solr lucene

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Java: Wie man einzelne int Werte aus int herausholt [] []

score 7 · Accepted Answer

Nur um sicher zu sein ist es, es auszuprobieren. Allerdings würde ich sehr wenig Einsparungen im Index erwarten, da der Index nur die tatsächliche Zeichenfolge einmal jedes Mal enthalten würde, der Rest sind Daten für Positionen dieser Zeichenfolge in Dokumenten. Sie sind kein großer Teil des Index.
Der Filtercache speichert nur Filterabfragen zwischen. Es ist möglicherweise nicht für Ihren genauen Anwendungsfall nützlich, aber viele finden sie nützlich. Beispielsweise können Sie die Ergebnisse nach Land, Sprache, Produkttyp usw. einschränken. Solr kann die Abfrageergebnisse für solche Dinge nicht neu berechnen, wenn Sie sie häufig verwenden.
Realistisch gesehen müssen Sie es nur ausprobieren und mit einem Profiler messen. Ohne genaue Kenntnis der verwendeten Datenstruktur ist alles andere reine SWAG. Ihre Berechnung ist genauso gut wie die anderer ohne Profiling.
Der Dokumentencache spart nur dann Zeit, wenn die Ergebnisse NACH der Berechnung der Abfrage erstellt werden. Wenn Sie die meiste Zeit damit verbringen, Abfragen zu berechnen, wird Ihnen der Dokumenten-Cache wenig nützen. Der Abfrage-Cache ist nur für wiederverwendbare Abfragen nützlich. Wenn keine Ihrer Abfragen wiederholt wird, ist der Query-Cache nutzlos
Ja, vorausgesetzt, Ihr Dokumenten-Cache ist groß genug, um alle zu speichern.

6-8 Nicht positiv.

Aus eigener Erfahrung mit Solr Performance Tuning sollten Sie Solr verlassen, um mit Abfragen, nicht Dokumentspeicher umzugehen. Die meisten Ihrer Fragen konzentrieren sich darauf, wie Dokumente Speicherplatz belegen. Solr ist eine Suchmaschine, kein Dokumentenspeicher. Wenn Sie möchten, dass Solr SCHNELL ist und nur wenig Speicher belegt, sollten Sie nur Indexinformationen für Suchzwecke verwenden. Die Dokumente selbst sollten gespeichert, abgerufen und an anderer Stelle gerendert werden. Vorzugsweise im System, das speziell für diesen Job optimiert ist. Das einzige Feld, das Sie in Ihrem Solr-Dokument speichern sollten, ist eine ID zum Abrufen aus dem Dokumentenspeichersystem.