Un indice dovrebbe essere ottimizzato dopo gli indici incrementali in Lucene?

Question

Eseguiamo reindici completi ogni 7 giorni (ovvero creando l'indice da zero) sul nostro indice Lucene e su indici incrementali ogni 2 ore circa. Il nostro indice ha circa 700.000 documenti e un indice completo richiede circa 17 ore (il che non è un problema).

Quando eseguiamo indici incrementali, indicizziamo solo il contenuto che è cambiato nelle ultime due ore, quindi ci vuole molto meno tempo - circa mezz'ora. Tuttavia, abbiamo notato che molto tempo (forse 10 minuti) viene impiegato per eseguire il metodo IndexWriter.optimize ().

Il LuceneFAQ menziona che:

  

La classe IndexWriter supporta un metodo optimize () che compatta il database dell'indice e accelera le query. È possibile che si desideri utilizzare questo metodo dopo aver eseguito un'indicizzazione completa del set di documenti o dopo aggiornamenti incrementali dell'indice. Se l'aggiornamento incrementale aggiunge documenti frequentemente, si desidera eseguire l'ottimizzazione solo una volta ogni tanto per evitare il sovraccarico aggiuntivo dell'ottimizzazione.

... ma questo non sembra dare alcuna definizione per ciò che " frequentemente " si intende. L'ottimizzazione è intensiva per CPU e MOLTO intensiva per IO, quindi preferiremmo non farlo se riusciamo a cavarcela. Quanto costa il risultato dell'esecuzione di query su un indice non ottimizzato (sto pensando in particolare in termini di prestazioni della query dopo un reindicizzazione completa rispetto a dopo 20 indici incrementali in cui, ad esempio, sono cambiati 50.000 documenti)? Dovremmo ottimizzare dopo ogni indice incrementale o non ne vale la pena il colpo alla performance?

Answer 1

Mat, poiché sembra che tu abbia una buona idea di quanto tempo impiega il tuo processo attuale, ti suggerisco di rimuovere optimise () e misurare l'impatto.

Molti dei documenti cambiano in quelle finestre di 2 ore? Se solo una piccola parte (50.000 / 700.000 è circa il 7%) viene reindicizzata in modo incrementale, non penso che stai ottenendo molto valore da un optimize () .

Alcune idee:

• Non eseguire affatto un optimize () incrementale. La mia esperienza dice che non stai vedendo comunque un enorme miglioramento delle query.
• Esegui optimize () ogni giorno anziché 2 ore.
• Esegui optimize () durante i periodi di basso volume (che è ciò che javadoc dice).

E assicurati di prendere le misure. Questo tipo di modifiche può essere sparato al buio senza di esse.

Answer 2

Un'operazione ottimizza legge e scrive l'intero indice, motivo per cui è così intensivo per l'IO!

L'idea alla base delle operazioni di ottimizzazione è quella di ricomporre tutti i vari segmenti dell'indice Lucene in un singolo segmento, il che può ridurre notevolmente i tempi di query in quanto non è necessario aprire e cercare più file per query. Se si utilizza la normale struttura del file di indice Lucene (anziché la struttura combinata), si ottiene un nuovo segmento per operazione di commit; lo stesso dei tuoi reindici suppongo?

Penso che Matt abbia un ottimo consiglio e secondo me tutto ciò che dice - essere guidato dai dati che tu avere. Vorrei davvero fare un ulteriore passo avanti e optare solo per a) quando è necessario eb) quando il volume delle query è basso.

Dato che le prestazioni della query sono intimamente legate al numero di segmenti nel tuo indice, un semplice ls -1 indice / segmenti_ * | count potrebbe essere un indicatore utile per quando è davvero necessaria l'ottimizzazione.

In alternativa, tracciare le prestazioni e il volume della query e dare il via a un'ottimizzazione quando si raggiungono prestazioni inaccettabili basse con un volume accettabilmente basso sarebbe una soluzione migliore.

Answer 3

In questa mail , i consigli di Otis Gospodnetic contro utilizzando il comando di ottimizzazione, se l'indice visualizza aggiornamenti costanti. È del 2007, ma chiamare optimise () è per sua natura un'operazione pesante per l'IO. Si potrebbe prendere in considerazione l'utilizzo di un approccio più graduale; a MergeScheduler