Lucene’s Indizierungscode erforschen: Teil 2

Zurück: Lucene’s Indizierungscode erforschen: Teil 1 Eine Spur von addDocument ist ziemlich intensiv, also müssen wir auf einer noch höheren…

Zurück: Lucene’s Indizierungscode erforschen: Teil 1

Eine Spur von addDocument ist ziemlich intensiv, also müssen wir auf einer noch höheren Ebene beginnen, denke ich.

Mit Hilfe einiger grundlegender IR-Kenntnisse wissen wir, dass addDocument unseren Analyzer verwenden wird, um jedes Feld des gegebenen Dokuments aufzuschlüsseln und die daraus resultierenden Begriffe zu verwenden, um einen invertierten Index zu erstellen. Im einfachsten Fall ist ein invertierter Index einfach eine Liste von Buchungen, die jeden Begriff einer Liste von Dokumentennummern zuordnet.

Eine echte Implementierung benötigt mehr Informationen als nur, in welchen Dokumenten ein Begriff zu finden ist – Lucene speichert optional auch die Dokumenthäufigkeit für jeden Begriff sowie die Positionen für jedes Dokument. Sie können sich vorstellen, dass Sie diese Art von Daten in die obige einfache Buchungsliste quetschen müssen. Anstelle von Lucene – > <docnum> + könnten Sie Lucene -> <docFreq> (<docnum> <Vorkommen> <Position>^(Vorkommen) ) +. Lucene kann auch andere Informationen speichern – Termvektoren, gespeicherte (nicht invertierte) Felder, einen Score-Normalisierungsfaktor, Payloads usw.

Zurück zur freundlichen Ebene: addDocument nimmt unser Dokument mit Feldern (Zuordnung von Feldnamen zu Werten und gegebenen Attributen) und zerlegt den Text aus jedem Feld in Terme. Dies ist der Beginn des Invertierungsprozesses – wir nehmen dokumentenzentrierte Daten und kehren sie um, damit sie begriffszentriert sind. Eine bestimmte Anzahl von Dokumenten wird in einen Subindex eingefügt, der in Lucene als Segment bezeichnet wird. Das gegebene Segment ermöglicht es uns, schnell von einem beliebigen Begriff in den Dokumenten in diesem Segment zur Gesamthäufigkeit der Dokumente für diesen Begriff (nur für dieses Segment) zu gelangen, in welchen Dokumenten der Begriff vorkommt und an welchen Positionen in diesen Dokumenten. Der IndexWriter kann mehrere Dokumente im Arbeitsspeicher sammeln und diese Dokumente dann zu bestimmten Zeitpunkten als ein neues Segment ausgeben, entweder durch Konfiguration oder durch Benutzerinteraktion. Zu diesem Zeitpunkt bleibt das n-Dokumentensegment unverändert, bis Lucene es in größere Segmente zusammenführt (es gibt eine kleine Ausnahme bei Löschungen und Normänderungen – diese werden on the fly maskiert, bis sie in die Indexstruktur zusammengeführt/geschrieben werden). Eine MergePolicy steuert, wie Lucene die Segmente im Laufe der Zeit zusammenführt.

Wir wissen also, dass der IndexWriter Listen von Dokumenten im Arbeitsspeicher sammelt und dann schließlich ein Segment für eine bestimmte Anzahl von Dokumenten schreibt. Wir können auf der Seite Dateiformate von Lucene nachsehen, wie das geschriebene Segment aussehen wird.

Vorerst ignorieren wir die einfachen Komprimierungstechniken, die Lucene verwendet (wenn Sie daran interessiert sind, sehen Sie sich die Informationen auf der Seite Lucene Index File Formats an), sowie das optionale Compound File Format. Auch wenn Sie sich für das zusammengesetzte Dateiformat entscheiden, bleiben die zugrunde liegenden Datenstrukturen dieselben.

Lucene Index Dateiformate

Um uns einen Überblick zu verschaffen, sehen wir uns die Dateien, aus denen ein Lucene-Index besteht, einmal genauer an. Einige der Informationen sind zur Veranschaulichung vereinfacht dargestellt.

Pro Index Dateien

Segmente Datei(segments_N, segments.gen)

Die Segmente-Datei verweist auf die aktiven Segmente im Index. Lucene verwendet ein einmaliges Schreibschema für Indexdateien (im Allgemeinen werden die Dateien nicht geändert). Wenn Segmente zusammengeführt oder hinzugefügt werden, wird eine neue Generation erstellt. Eine Generation ist einfach eine Sammlung von Segmenten – einige können zu einer früheren Generation gehört haben und einige können neu erstellte Segmente sein. Das _N im Dateinamen der Segmente bezieht sich auf die Generation, die diese bestimmte segment_N-Datei verfolgt. Es weist Sie auf die Segmente hin, die Sie verwenden müssen, wenn Sie diese bestimmte Generation lesen möchten. Die Segmentdatei mit dem höchsten _N ist die neueste Generation. Standardmäßig entfernt Lucene ältere Generationen, wenn es dazu in der Lage ist, aber Sie können eine anpassbare IndexDeletionPolicy verwenden, um ältere Generationen zu behalten.

segments.gen speichert die letzte Generation, _N, und wird als Ausweichlösung verwendet, falls die aktuelle Generation nicht genau bestimmt werden kann, indem Sie einfach das Verzeichnis auflisten und die Datei segments_N mit dem größten _N auswählen.

Datei sperren

Je nach verwendeter LockFactory kann es eine Index-Lock-Datei geben. Standardmäßig befindet sich diese im Lucene-Indexverzeichnis, aber der Ort ist konfigurierbar.

Pro Segment Dateien

Die Feldinfo-Datei (*.fnm)

In dieser Datei werden die Indexzeitattribute für jedes Feld gespeichert.

Begriffswörterbuch (*.tis, *.tii)

Im Begriffslexikon ist gespeichert, wie Sie in den verschiedenen anderen Dateien zu jedem Begriff navigieren können. Auf einer einfachen, hohen Ebene sagt Ihnen das Begriffslexikon, wo Sie in den frq- und prx-Dateien nach weiteren Informationen zu diesem Begriff suchen müssen. Die Begriffe werden in alphabetischer Reihenfolge gespeichert, damit Sie schnell nachschlagen können. Eine weitere Datenstruktur, der Term Info Index, ist so konzipiert, dass er vollständig in den Speicher eingelesen werden kann und einen wahlfreien Zugriff auf die Datei „tis“ ermöglicht. Andere Buchhaltungsdaten (Sprunglisten, Indexintervalle) werden ebenfalls mit dem Term Dictionary verfolgt.

Begriffshäufigkeiten (*.frq)

Die .frq-Datei enthält die IDs der Dokumente, die jeden Begriff enthalten, sowie die Häufigkeit des Begriffs in diesem Dokument (es sei denn, Sie verwenden omitTf für dieses Feld). Die Daten der Verzweigungslisten werden ebenfalls in dieser Datei gespeichert. Siehe Überspringungslisten.

Terminpositionen (*.prx)

Die .prx-Datei enthält die Listen der Positionen, an denen jeder Begriff in den Dokumenten vorkommt. Wenn alle Felder omitTf verwenden, gibt es keine Term-Positionen-Datenstruktur.

Gespeicherte Felder (*.fdx *.fdt)

Gespeicherte Felder sind die ursprünglichen Rohtextwerte, die an Lucene übergeben wurden. Dies ist nicht wirklich Teil der invertierten Indexstruktur – es ist einfach eine Zuordnung von Dokument-IDs zu gespeicherten Felddaten. Die Feldindexdatei (*.fdx) wird verwendet, um von der Dokument-ID zu der Position in der Felddatendatei (*.fdt) zu gelangen, an der sich die gespeicherten Felddaten befinden.

Term-Vektoren (*.tvx, *.tvd, *.tvf)

TermVectors sind optionale Datenstrukturen, die zusätzliche Informationen und Daten über das aktuelle Segment speichern. Die Unterstützung wird in drei Dateien geliefert – die erste (Document Index *.tvx) indiziert die anderen beiden nach Dokument-ID.

Die Dokumentdatei (*.tvf) listet auf, welche Felder über Termvektoren verfügen und verweist auf die TermVector-Felddatei (*.tvf).

Die TermVector-Felddatei (*.tvf) enthält für jedes Feld, für das ein TermVector gespeichert ist, eine Liste der Terme, ihrer Häufigkeiten und optional Informationen zu Position und Offset.

Normen (*.nrm)

Normen sind ein Indexzeit-Normalisierungsfaktor, der in die Bewertung einfließen kann. Dokument- und Feld-Boosts sowie die Längennormalisierung werden mit Normen angewendet. Im Speicher belegen die Normen ein Byte pro Dokument für jedes Feld mit aktivierten Normen, selbst wenn nur ein Dokument für dieses Feld aktivierte Normen aufweist. Die Normendatei führt ein wenig Buch und speichert das Byte für jedes Dokument. Wenn Sie Normen ändern, werden die Änderungen in einer neuen Normdatei, seg_prefix_X.sN ,gespeichert, wobei N die Feldnummer und X die Generation der Normen ist.

Gelöschte Dokumente (*.del)

Verfolgt, welche Dokumente aus dem Index gelöscht wurden, aber noch nicht zusammengeführt wurden. Diese Datei existiert nur, wenn der Index noch nicht zusammengefasste Löschungen enthält.

Fortsetzung folgt…

Mit diesem Wissen können wir sehen, wie Lucene den invertierten Index einrichtet. Das Term Dictionary weist uns schnell auf verschiedene Informationen zu einem Abfragebegriff hin – wir können seinem Zeiger auf Dokument-IDs, Begriffspositionen, gespeicherte Felder und Begriffsvektorinformationen folgen. Jetzt können wir sehen, wohin wir mit IndexWriter.addDocument() kommen. Er muss unser Dokument nehmen, den Text in Begriffe aufteilen und dann die oben genannten Strukturen aufbauen.

Als nächstes untersuchen wir die Lucene-Indizierungskette, die mit addDocument… gestartet wird.