Sollte ein Index nach inkrementeller Indizes in Lucene optimiert werden?

Question

Wir führen vollständige Re-Indizes alle 7 Tage (das heißt den Index von Grund auf neu erstellen) auf unserer Lucene Index und inkrementelle Indizes alle 2 Stunden oder so. Unser Index hat rund 700.000 Dokumente und ein vollständiger Index dauert etwa 17 Stunden (das ist kein Problem).

Wenn wir inkrementelle Indizes tun wir nur Index Inhalte, die in den letzten zwei Stunden geändert hat, so dauert es viel weniger Zeit - um eine halbe Stunde. Aber wir haben festgestellt, dass viele dieser Zeit (vielleicht 10 Minuten) aufgewendet wird, um die IndexWriter.optimize () -Methode ausgeführt wird.

Die LuceneFAQ erwähnt, dass:

  

Die Indexwriter-Klasse unterstützt eine optimize () -Methode, die die Index-Datenbank komprimiert und Abfragen beschleunigt. Sie können diese Methode verwenden mögen, nachdem eine vollständige Indizierung Ihres Dokumentensatzes oder nach inkrementellen Aktualisierungen des Index durchgeführt wird. Wenn Ihre inkrementellen Update Dokumente häufig ergänzt, möchten Sie die Optimierung nur hin und wieder auszuführen, um den zusätzlichen Aufwand der Optimierung zu vermeiden.

... aber das scheint keine Definition zu geben für das, was „häufig“ bedeutet. Optimizing ist CPU-intensiv und sehr IO intensiv, so dass wir lieber nicht tun es, wenn wir damit durchkommen kann. Wie groß ist der Hit von Anfragen auf einem nicht optimierten Index läuft (ich denke vor allem in Bezug auf der Abfrageleistung nach einem vollständigen Wieder Index im Vergleich zu nach 20 inkrementeller Indizes, wo etwa 50.000 Dokumente geändert haben)? Sollten wir nach jedem inkrementellen Index werden die Optimierung oder die Performance-Einbußen es nicht wert?

Answer 1

Mat, da Sie scheinen eine gute Idee zu haben, wie lange die aktuelle Prozess dauert, schlage ich vor, dass Sie die optimize() entfernen und die Auswirkungen messen.

Haben viele der Dokumente in diesen 2 Stunden Fenster ändern? Wenn nur ein kleiner Bruchteil (50.000 / 700.000 beträgt ca. 7%) werden schrittweise neu indiziert, dann denke ich nicht, dass Sie vielen Wert aus einem optimize() bekommen.

Einige Ideen:

• Sie eine inkrementelle optimize() überhaupt nicht. Meine Erfahrung sagt, Sie sind nicht eine große Abfrage Verbesserung sehen trotzdem.
• Haben die optimize() täglich anstelle von 2-stündlich.
• Haben die optimize() während Low-Volume-mal (was die javadoc sagt).

Und stellen Sie sicher, dass Sie Messungen vornehmen. Diese Arten von Änderungen können ohne sie ein Schuss im Dunkeln sein.

Answer 2

Eine optimize Operation liest und schreibt den gesamten Index, weshalb es so IO intensiv ist!

Die Idee hinter Operationen zu optimieren ist, um alle verschiedenen Segmente in den Lucene-Index in einem einzigen Segment neu zu kombinieren, die Abfragezeiten erheblich reduzieren können, wie Sie müssen mehrere Dateien pro Abfrage nicht öffnen und durchsuchen. Wenn Sie die normale Lucene Index Dateistruktur verwenden (anstatt die kombinierte Struktur), erhalten Sie ein neues Segment pro Festschreibungsoperation; die gleich wie Ihr Re-Indizes Ich gehe davon aus?

Ich denke, Matt gute Ratschläge hat und ich würde zweiten alles, was er sagt - durch die Daten, die Sie gefahren werden haben. Ich würde tatsächlich einen Schritt weiter und nur optimieren können a), wenn Sie müssen und b) wenn Sie einen niedrigen Abfragevolumen haben.

Als Abfrageleistung eng mit der Anzahl der Segmente in Ihrem Index gebunden ist, eine einfache ls -1 index/segments_* | count ein nützlicher Indikator für die bei der Optimierung könnte wirklich benötigt wird.

Alternativ die Abfrageleistung und Lautstärke-Tracking und eine optimize tritt aus, wenn Sie mit akzeptablen niedrigen Volumen inakzeptabel niedrige Leistung erreichen wäre eine schönere Lösung.

Answer 3

dieser Mail , Otis Gospodnetic Ratschläge wenn Ihr Index ständiges Updates gegen mit optimize, ist zu sehen. Es ist aus dem Jahr 2007, aber Aufruf optimize() ist darin eine IO-schwere Operation Natur ist. Sie könnten mit einem mehr schrittweisen Ansatz prüfen; ein MergeScheduler