Simon Willnauer, Column Stride Fields oder DocValues, und die Verbesserung von FieldCache
Ich bin ein Entwickler von Webanwendungen. Ich werde nicht so tun, als hätte ich alles verstanden, was Simon Willnauer in seinem Vortrag über Column Stride Fields oder DocValues an Tag 1 der Lucene Revolution gesagt hat. Das liegt daran, dass ich in der Regel kein Bedürfnis habe, in die Eingeweide von Lucene zu steigen, um gute Ergebnisse zu erzielen. Und genau das ist es, was ich daran mag. Wenn Sie mir sagen: „Definieren Sie Ihr Feld unter diesen Umständen als ‚feldfähig‘, um die beste Leistung zu erhalten“, dann ist das gut genug für mich.
Folien für diese Sitzung:
Aber für viele Menschen – vor allem für diejenigen, die an der Lucene Revolution teilnehmen – sind die Eingeweide von Lucene das, worum es geht. Und dieser Vortrag war definitiv für sie. Glücklicherweise wurde Simons Vortrag auf Video aufgezeichnet, so dass Sie die uninterpretierten Details von ihm bekommen können, sobald diese verfügbar sind, aber selbst mit meinem begrenzten Verständnis konnte ich sagen, dass dies eine gute Sache war.
Im Grunde genommen läuft es so ab, wie ich es verstehe. Lucene erstellt einen invertierten Index, der im Grunde nur einen Begriff mit einem Dokument verknüpft. Aber sobald Sie die Begriffe haben, müssen Sie diese Dokumente nach ihrer Relevanz bewerten, und dazu benötigen Sie Zugriff auf die Daten, die Teil des Dokuments sind.
Es gibt zwei Möglichkeiten, auf die indizierten Daten von Lucene zuzugreifen. Ein Weg ist über gespeicherte Felder und der andere über den FieldCache. Gespeicherte Felder können langsam sein, weil Sie im Grunde zwei Suchvorgänge durchführen müssen: einen, um herauszufinden, in welcher Datei Sie danach suchen müssen, und einen weiteren, um das Feld tatsächlich zu finden. Der FieldCache ist schneller, da es sich um einen invertierten Index handelt, der im Speicher liegt. Er muss jedoch geladen werden und kann viel Speicherplatz beanspruchen – mehr, als Ihnen vielleicht zur Verfügung steht, insbesondere wenn Sie ein mobiles Gerät verwenden oder auf einen Heap von 2 GB beschränkt sind – sobald er einmal geladen ist.
DocValues (in diesem Fall nicht, wie Simon betont hat, die bestehende Klasse DocValues – diese Funktion wird wahrscheinlich umbenannt, bevor sie veröffentlicht wird) sind im Grunde ein Array, ähnlich wie FieldCache. Dieses Array kann in den Arbeitsspeicher geladen oder für den sequentiellen Zugriff auf der Festplatte gespeichert werden, was im Grunde keine Anforderungen an den Heap stellt. (Er empfiehlt jedoch, es in einem MemoryMapped-Puffer zu speichern, um die beste Leistung zu erzielen.) Da jedoch jedes Feld eine eigene Datei benötigt, sollten Sie auf die Fehlermeldung „zu viele Dateien geöffnet“ achten.
Die von ihm gezeigten Leistungsbenchmarks waren beeindruckend; dies ist eindeutig ein großer Schritt nach vorn.
Als Nächstes möchte Simon DocValues aktualisierbar machen, was für die Bewertung auf der Grundlage sich ändernder Werte, für die verteilte Suche und natürlich für die Suche in Echtzeit von großem Nutzen sein wird.
Hört sich gut an.
Cross-posted mit Lucene Revolution Blog; Nicholas Chase ist ein Gastblogger. Dies ist eine von mehreren Zusammenfassungen von Präsentationen der Konferenz.