Uwe Schindler SD Data-Solutions GmbH

Für alle, die mit Lucene arbeiten wollen, aber auch für diejenigen, die bereits Apache Solr oder Elasticsearch einsetzen, empfiehlt es sich, das aktuelle Release von Apache Lucene herunterzuladen und einmal ein einfaches Projekt zu starten. Seit Version 8.1 ist nämlich auch das früher als separates Projekt auf GitHub erreichbare Tool Luke im Release enthalten. Damit lassen sich die Inhalte von Lucene-Indizes (auch aus Solr/Elasticsearch) anzeigen, testen und Dinge wie Term Dictionary und Textanalyse visualisieren.

Apache Lucene ist inzwischen nicht mehr jedem in der Softwarebranche ein Begriff. Heutzutage benutzen viele Leute einfach Apache Solr oder Elasticsearch, um im Unternehmen die Recherche über die Datenbestände anzubieten, also etwa Produkte in Shops, Firmendokumente im Enterprise CMS oder auch Aggregationen des Datenbestands nach Kategorien (Facetting). Hinter den beiden Suchservern Apache Solr und Elasticsearch steckt jedoch dieselbe Technik: Apache Lucene. Bevor wir daher im zweiten Artikel dieses Schwerpunkts den Einsatz dieser Systeme im Enterprise-Umfeld durchleuchten und die Vor- und Nachteile beider Systeme darlegen, geht dieser Artikel auf die Bibliothek Apache Lucene und die dahinterstehenden Konzepte ein.

Viele Entwickler, die sich zum ersten Mal mit Volltextsuche beschäftigen, haben zuvor mit relationalen Datenbanken und Indizes gearbeitet und wissen, warum diese wichtig sind. In relationalen Datenbanken werden Daten in Tabellen gespeichert, zu deren Spalten sich Indizes hinzufügen lassen. Diese ermöglichen die Suche nach Werten oder helfen, Joins (Verknüpfungen) zwischen Tabellen durchzuführen. Schließlich wird bei relationalen Datenbanken viel Wert darauf gelegt, die Daten zu normalisieren: Es geht darum, möglichst wenige Redundanzen in Tabellenspalten zu haben und daher Attribute der Haupttabelle in beigeordnete Tabellen zu verlagern, wo diese unique sind.

Volltextsuche – was passiert da eigentlich?

Im Gegensatz dazu wird bei Volltextsuchmaschinen ein ganz anderer Ansatz gewählt: Man betrachtet nur einen Typ von Entität (Dokumente) und packt alle Attribute in diese Dokumente hinein. Diese wiederum bestehen aus teilweise strukturierten, oftmals aber auch aus unstrukturierten Textschnipseln, die in Felder gesteckt werden. Vereinfacht gesagt ist ein solches Dokument vergleichbar mit einem JSON-Dokument: Felder sind in diesem Vergleich die Keys, die Values der JSON-Dokumente sind die zu durchsuchenden Inhalte. Letztere sind dabei überhaupt nicht normalisiert, oftmals wird sogar der gesamte Volltext zusätzlich ebenfalls in ein Extrafeld gesteckt, sodass er schneller durchsuchbar ist.

Man stelle sich also eine Datenbank in Apache Lucene als eine Sammlung von Dateien im JSON-Format vor. Das Schema dieser Dateien ist ähnlich, aber nicht zwangsläufig identisch. Felder wie Titel, Autor oder Zusammenfassung gibt es bei allen Dokumenten. Manche können optional noch über weitere durchsuchbare Eigenschaften wie beispielweise Kategorien, Preise bei Produkten oder eben Veröffentlichungsjahr, Hersteller oder Kontaktmailadressen verfügen. Im Gegensatz zu relationalen Datenbanken ist bei Volltextsuchmaschinen auch die Möglichkeit wichtig, mehrere Werte pro Feldnamen abzulegen. So könnte das Feld Kategorien im fiktiven Dokumenten-JSON durchaus auch aus einem Array aus Kategorienamenelementen bestehen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 7.19 - "Lucene, Solr, Elasticsearch"

Alle Infos zum Heft
579894250Grundfunktionen der Apache-Lucene-Bibliothek
X
- Gib Deinen Standort ein -
- or -