Comment Lucene indexe les documents?
J'ai lu un document sur Lucene; J'ai aussi lu le document dans ce lien ( http://lucene.sourceforge.net/talks/pisa ).
Je ne comprends pas vraiment comment Lucene indexe les documents et je ne comprends pas les algorithmes que Lucene utilise pour indexer?
Sur le lien ci-dessus, Lucene utilise cet algorithme pour l'indexation:
- algorithme incrémental:
- maintenir une pile d'indices de segment
- créer un index pour chaque document entrant
- Poussez de nouveaux index sur la pile
- soit b = 10 le facteur de fusion; M = 8
for (size = 1; size < M; size *= b) {
if (there are b indexes with size docs on top of the stack) {
pop them off the stack;
merge them into a single index;
Push the merged index onto the stack;
} else {
break;
}
}
Comment cet algorithme fournit-il une indexation optimisée?
Lucene utilise-t-elle l'algorithme B-tree ou tout autre algorithme de ce type pour l'indexation, ou dispose-t-il d'un algorithme particulier?
Il y a un assez bon article ici: https://web.archive.org/web/20130904073403/http://www.ibm.com/developerworks/library/wa-lucene/
Édition 12/2014: mise à jour vers une version archivée en raison de la suppression de l'original. La meilleure alternative plus récente est probablement la suivante: http://lucene.Apache.org/core/3_6_2/fileformats.html
Il existe une version encore plus récente sur http://lucene.Apache.org/core/4_10_2/core/org/Apache/lucene/codecs/lucene410/package-summary.html#package_description , mais semble contenir moins d’informations que l’ancien.
En résumé, lorsque Lucene indexe un document, il se décompose en plusieurs termes. Il stocke ensuite les termes dans un fichier d'index où chaque terme est associé aux documents qui le contiennent. Vous pourriez penser que c'est un peu comme une table de hachage.
Les termes sont générés à l'aide d'un analyseur qui associe chaque mot à sa forme racine. L'algorithme de stemming le plus populaire pour la langue anglaise est l'algorithme de stemming de Porter: http://tartarus.org/~martin/PorterStemmer/
Lorsqu'une requête est émise, elle est traitée via le même analyseur que celui utilisé pour créer l'index, puis pour rechercher le (s) terme (s) correspondant (s) dans l'index. Cela fournit une liste de documents correspondant à la requête.
En résumé, Lucene construit un index inversé en utilisant Skip-Lists sur le disque, puis charge un mappage pour les termes indexés en mémoire en utilisant un transducteur à états finis (FST). Notez cependant que Lucene ne charge pas (nécessairement) tous les termes indexés dans la RAM , comme décrit par Michael McCandless, l'auteur du système d'indexation de Lucene lui-même. Notez qu'en utilisant les Skip-Lists, l'index peut être parcouru d'un hit à l'autre, rendant des choses comme set et, en particulier, requêtes de plage possible (beaucoup comme B-Trees). Et le entrée de Wikipedia sur l'indexation des Skip-Lists explique également pourquoi l'implémentation de Skip-List de Lucene s'appelle un à plusieurs niveaux Skip-List - essentiellement, pour créer O(log n) consultations possibles (encore une fois, un peu comme B-Trees).
Donc, une fois que l'index (terme) inversé - qui est basé sur une structure de données Skip-List - est construit à partir des documents, l'index est stocké sur le disque. Lucene charge ensuite (comme déjà dit: éventuellement, quelques-uns seulement) de ces termes dans un transducteur à états finis , dans une implémentation FST vaguement inspiré par Morfologick =.
Michael McCandless (aussi) fait un travail assez bon et concis de expliquant comment et pourquoi Lucene utilise un FST (acyclique minimal) pour indexer les termes que Lucene enregistre en mémoire, essentiellement comme un SortedMap<ByteSequence,SomeOutput>, et donne une idée de base du fonctionnement des FST (c’est-à-dire comment FST compacte les séquences d’octets [c.-à-d. les termes indexés] pour que l’utilisation de cette mappage en mémoire croisse de manière sub-linéaire). Et il pointe vers le document qui décrit l'algorithme FST particulier que Lucene utilise également.
Pour ceux qui sont curieux de savoir pourquoi Lucene utilise des Skip-Lists, alors que la plupart des bases de données utilisent des arbres (B +) - et/ou (B), regardez the right SO answer concernant cette question (Skip-Lists vs. B-Trees). Cette réponse donne une assez bonne explication détaillée - essentiellement, et non , ce qui rend les mises à jour simultanées de l’index "plus faciles" (parce que vous pouvez décider de ne pas rééquilibrer immédiatement un arbre B, obtenant ainsi à peu près la même performance concurrente qu'une liste sautée), mais plutôt, Les listes sautées vous évitent d'avoir à travailler sur le (retardé ou non ) opération d’équilibrage (finalement) nécessaire aux arbres B (En fait, comme le montre la réponse, il y a probablement très peu de différence de performances entre les arbres B et [à plusieurs niveaux] Skip- Listes, si l'une ou l'autre est "bien faite".
Il semble que votre question porte davantage sur la fusion d'index que sur l'indexation elle-même.
Le processus d'indexation est assez simple si vous ignorez les détails de bas niveau. Lucene forme ce qu'on appelle "index inversé" à partir de documents. Donc, si le document avec le texte "Être ou ne pas être" et id = 1 entre, l'index inversé ressemblerait à ceci:
[to] → 1
[be] → 1
[or] → 1
[not] → 1
En gros, il s’agit de l’index du mot au liste des documents contenant un mot donné. Chaque ligne de cet index (Word) est appelée liste de publication. Cet index est ensuite conservé sur le stockage à long terme.
En réalité, les choses sont plus compliquées:
- Lucene peut sauter des mots en fonction de l'analyseur donné;
- les mots peuvent être prétraités à l'aide d'un algorithme de radicalisation afin de réduire la flexion du langage;
- liste de publication peut contenir non seulement les identifiants des documents, mais aussi le décalage du document Word donné (éventuellement plusieurs instances) et quelques autres informations supplémentaires.
Il y a beaucoup d'autres complications qui ne sont pas si importantes pour la compréhension de base.
Cependant, il est important de comprendre que l'indice de Lucene est ajouter uniquement. À un moment donné, l'application décide de valider (publier) tous les changements apportés à l'index. Lucene termine toutes les opérations de service avec index et le ferme afin qu'il soit disponible pour la recherche. Après commit index essentiellement immuable. Cet index (ou partie d'index) s'appelle segment. Lorsque Lucene exécute la recherche d'une requête, elle recherche dans tous les segments disponibles.
Alors la question se pose - comment pouvons-nous changer le document déjà indexé?
Les nouveaux documents ou les nouvelles versions de documents déjà indexés sont indexés dans les nouveaux segments et les anciennes versions sont invalidées dans les segments précédents à l'aide de ce qu'on appelle liste de mise à mort. La liste de destruction est la seule partie de l'index engagé qui peut changer. Comme vous pouvez le deviner, l'efficacité des index diminue avec le temps, car les anciens index peuvent contenir la plupart des documents supprimés.
C’est là que la fusion entre en jeu. Fusion: processus qui consiste à combiner plusieurs index pour en améliorer l’efficacité globale. Ce qui se passe essentiellement lors de la fusion, ce sont des documents en direct copiés dans le nouveau segment et les anciens segments entièrement supprimés.
En utilisant ce processus simple, Lucene est en mesure de maintenir l'index en bon état en termes de performances de recherche.
J'espère que ça va aider.
C'est index inversé , mais cela ne précise pas quelle structure il utilise. format d'index dans lucene contient des informations complètes.
Commencez par 'Résumé des extensions de fichier'.
Vous remarquerez d’abord qu’il est question de différents index. Autant que je sache, aucun de ceux-ci n'utilise à proprement parler un arbre B , mais il y a des similitudes - les structures ci-dessus ressemblent à des arbres.