Est-il possible de recréer l'index Lucene en arrière-plan?

Question

Il est parfois nécessaire de générer de nouveau un index lucene, par ex. quand quelque chose change dans le mapping de Compass ou dans la façon dont les boosts sont appliqués, ou si quelque chose a été corrompu pour une raison quelconque. Dans mon cas, la génération de l'index prend environ 5 à 6 heures, effaçant l'index avant que les données ne soient incomplètes pour cet intervalle. C'est à dire. faire une recherche dans ce temps renvoie un résultat incomplet.

Existe-t-il un moyen standard pour que Lucene génère l'index en arrière-plan? Par exemple. écrire l'index dans un répertoire temporaire et (lorsque l'indexation est terminée sans exceptions, etc.) remplacer l'index existant par le nouveau?

Bien sûr, on pourrait implémenter cela "manuellement", mais faut-il le faire? Cela ressemble à un cas d'utilisation commun pour moi.

Cordialement + Merci pour votre avis,

Peter :)

Answer 1

J'ai eu une expérience similaire; il y avait certains paramètres à l'analyseur qui seraient changés de temps en temps; Évidemment, si c'était le cas, tout l'indice doit être reconstruit. (Je ne vais pas entrer dans les détails, il suffit de dire que j'avais la même exigence!)

J'ai fait ce que vous avez suggéré dans votre question. Il y avait trois répertoires, "ancien", "courant" et "nouveau". Les requêtes du site en direct vont toujours contre "courant". Le processus de loisirs d'index était:

1. récursive supprimer le répertoire « anciens » et « nouveaux » répertoires
2. Créer le nouvel indice dans la « nouvelle » (dans mon cas prend environ 6 heures)
3. Renommer "courant" à "vieux"; et « nouveau » à « courant »
4. récursive supprimer le « vieux » répertoire

Une analyse de ce qui se passe lorsque le processus se bloque - si elle se bloque dans la 1ère étape, la prochaine fois qu'il sera simplement continuer . Si elle se bloque dans la deuxième étape, le "nouveau" répertoire sera supprimé lors de la prochaine exécution. La 3ème étape est très rapide - renommer un répertoire est rapide et atomique. Crashing dans la 4ème étape n'a pas d'importance, il va juste être nettoyé la prochaine fois. L'observateur attentif remarquera qu'à l'étape 3, le système pourrait s'écraser entre renommer le répertoire actuel et déplacer le nouveau répertoire. Ceci est peu probable car le changement de nom du répertoire est si rapide. Le système est en production depuis quelques années et cela n'est jamais arrivé (encore?).

Answer 2

Je pense que la manière habituelle de le faire est d'utiliser la fonctionnalité de réplication de solr. Dans votre cas, le maître et l'esclave seraient sur la même machine, mais pointaient simplement sur des répertoires différents.

Answer 3

Nous avons un problème similaire. Nos données sont indexées dans Lucene, mais la source d'origine est DB et le repo de contenu. Par conséquent, si un index est désynchronisé (ou des changements de type de données, etc.), il suffit de parcourir toutes les entrées existantes dans l'index et de générer à nouveau les données de sorte que chaque document soit mis à jour. Ce n'est pas vraiment une chose complexe à faire.