Un index devrait-il être optimisé après les index incrémentaux dans Lucene?

Question

Nous effectuons des réindexations complètes tous les 7 jours (c'est-à-dire, création de l'index en partant de zéro) sur notre index Lucene et des index incrémentiels toutes les 2 heures environ. Notre index contient environ 700 000 documents et un index complet prend environ 17 heures (ce qui ne pose pas de problème).

Lorsque nous faisons des index incrémentiels, nous indexons uniquement le contenu qui a changé au cours des deux dernières heures. Cela prend donc beaucoup moins de temps - environ une demi-heure. Cependant, nous avons remarqué que nous passons beaucoup de temps (peut-être 10 minutes) à exécuter la méthode IndexWriter.optimize ().

Le LuceneFAQ le dit bien:

  

La classe IndexWriter prend en charge une méthode optimise () qui compacte la base de données d'index et accélère les requêtes. Vous souhaiterez peut-être utiliser cette méthode après une indexation complète de votre ensemble de documents ou après des mises à jour incrémentielles de l'index. Si votre mise à jour incrémentielle ajoute des documents fréquemment, vous souhaitez effectuer l'optimisation de temps en temps pour éviter la surcharge supplémentaire de l'optimisation.

... mais cela ne semble pas donner de définition pour ce que "fréquemment" veux dire. L’optimisation est très gourmande en ressources processeur et en ressources IO, nous préférerions donc ne pas le faire si nous pouvons nous en sortir. Quel est le résultat de l'exécution de requêtes sur un index non optimisé (je pense en particulier aux performances des requêtes après un réindexage complet par rapport à après 20 index incrémentaux dans lesquels, par exemple, 50 000 documents ont changé)? Devrions-nous optimiser chaque indice incrémentiel ou l’atteinte des performances n’en vaut-elle pas la peine?

Answer 1

Mat, comme vous semblez avoir une bonne idée du temps que prend votre processus actuel, je vous suggère de supprimer optimiser () et de mesurer l'impact.

Est-ce que beaucoup de documents changent dans ces fenêtres de 2 heures? Si seulement une petite fraction (50 000/700 000 équivaut à environ 7%) est réindexée de manière incrémentielle, alors je ne pense pas que vous obtenez beaucoup de valeur d'un optimise () .

Quelques idées:

• Ne faites pas du tout un optimisé () incrémental. Mon expérience montre que vous ne voyez pas une énorme amélioration de la requête de toute façon.
• Effectuez la optimisation () quotidiennement au lieu de deux heures par jour.
• Faites le optimise () pendant les périodes de faible volume (ce qui est ce que le javadoc dit).

Et assurez-vous de prendre des mesures. Ces types de changements peuvent être un coup dans le noir sans eux.

Answer 2

Une opération optimise lit et écrit l'intégralité de l'index, c'est pourquoi il est tellement intensif en IO!

L’idée des opérations d’optimisation est de regrouper tous les différents segments de l’index de Lucene en un seul segment, ce qui peut considérablement réduire les temps de requête, car il n’est pas nécessaire d’ouvrir et de rechercher plusieurs fichiers par requête. Si vous utilisez la structure de fichier d'index Lucene normale (plutôt que la structure combinée), vous obtenez un nouveau segment par opération de validation; le même que vos re-index je suppose?

Je pense que Matt a de bons conseils et que j'appuie tout ce qu'il dit - soyez motivé par les données que vous avez avoir. Je voudrais en fait aller plus loin et n’optmize que a) lorsque vous en avez besoin et b) lorsque vous avez un volume de requêtes faible.

Les performances des requêtes étant intimement liées au nombre de segments de votre index, un simple ls -1 index / segments_ * | count pourrait être un indicateur utile lorsque l'optimisation est vraiment nécessaire.

Vous pouvez également suivre le rendement et le volume des requêtes et lancer une optimisation lorsque vous atteignez des performances inacceptables avec un volume acceptable, constituerait une meilleure solution.

Answer 3

Dans ce courrier , les conseils d'Otis Gospodnetic contre avec optimisation, si votre index affiche des mises à jour constantes. C'est à partir de 2007, mais appeler optimiser () est en réalité une opération très chargée en IO. Vous pouvez envisager une approche plus progressive. MergeScheduler