© tsstockphoto, 123RF

Im letzten Teil der Serie zur Volltextsuche steht der Webcrawler im Mittelpunkt. Das vorgestellte Collector-Framework von Norconex bringt gegenüber dem bisher verwendeten Manifold CF einige Vorteile mit sich.

Die Artikelserie beschrieb bisher, wie ein Archivar ein im Volltext durchsuchbares Archiv von Fachzeitschriften nicht nur zum Thema Linux aufbaut. Als Suchserver kam in den zurückliegenden Teilen dieser Serie die Open-Source-Engine Datafari [1] zum Einsatz. Sie bündelt alle benötigten Komponenten, insbesondere den vielseitigen Zugriff auf verschiedene Datenquellen mithilfe von Apache Manifold CF (MCF, [2]) und dem Solr-Backend. Eine übersichtliche Oberfläche liefert obendrein eine attraktive Schnittstelle für die Suchenden.

Um die Dokumente zu verarbeiten, standen bislang zwei Verfahren zur Auswahl: MCF Transformer und die Update-Prozessoren der Solr Update Chain. Beide Varianten erfüllten die gestellten Anforderungen in Sachen Textfilterung und Behandlung der Metadaten mehr oder weniger gut. Allerdings gab es bei der Dokumentenverarbeitung in Solr einen gravierenden Nachteil: Die XML-basierte Konfiguration der Document Processing Pipeline entpuppte sich mangels einer geeigneten Modularisierung schnell als unübersichtlich und redselig.

Dass es auch anders geht, zeigen die Norconex-Kollektoren [3]. Deren gut strukturierte XML-Konfigurationsdateien beschreiben nicht nur die Pipeline kurz und prägnant: Setzt der Entwickler Apaches Velocity Engine [4] für XML-Templates ein, eröffnen sich ihm auch die zahllosen Möglichkeiten einer Skriptsprache. So kann er mithilfe diverser Direktiven XML-Fragmente wiederverwenden, Variablen definieren und den Kontrollfluss mit Schleifen oder bedingungsabhängig steuern.

Crawler

Das Internet hält eine fast unüberschaubare Fülle von Informationen zur mehr als 20-jährigen Historie [5] der Webcrawler parat [6]. Dazu zählen Theorien und Geschichten über ihre Evolution, angefangen beim altehrwürdigen Mercator (Altavista Crawler [7]) über UbiCrawler [8] bis hin zu noch jungen Vertretern der Gattung wie Bubing [9]. Allein Github verfügt über fast 5400 Repositories, die sich mit dem Thema Webcrawler beschäftigen.

Als Komponente eines Suchservers gehören das Extrahieren und Verfolgen von Links zu den Basisfunktionen gängiger Crawler. Daneben bieten sie mehr oder weniger ausgeprägte Hilfestellung beim Zerlegen der gefundenen Dokumente in Text und Metadaten. Das zählt allerdings nicht unbedingt zu ihren Kernfunktionen. Zur Gruppe der Crawler, die das beherrschen, gehören die nachfolgend beschriebenen Kollektoren der in Ottawa beheimateten Firma Norconex [10].

Norconex-Kollektoren

Neben kommerziellen Produkten für den Bereich der Enterprise-Suchtechnologie entwickelt Norconex seit 2013 auch beachtenswerte quelloffene Komponenten unter der Apache-2.0-Lizenz. Auf Github stehen die Quellen von HTTP Collector [11] und Filesystem Collector [12] bereit, die den Dokumentenzugriff auf lokale Dateiablagen und Dateiserver mit vielen Standardprotokollen erlauben (HTTP, SMB, FTP, WebDAV und andere). Beim Download greift der Entwickler zur jüngsten Freigabeversion der Einzelkomponenten, um alle nötigen Funktionen zu erhalten.

Sämtliche Kollektoren bestehen dabei aus drei Funktionsgruppen: dem Crawler, dem Importer und dem Committer. Der Crawler grast die Datenquelle ab und liefert die aufgespürten Dokumente an die Document Processing Pipeline im Importer. Der kümmert sich um das Extrahieren von Text und generiert Metadaten, die er während der Analyse der Dokumente aus deren Eigenschaften und Inhalt ableitet. Anschließend liefert der Committer die (auf Wunsch gefilterten) Daten an einen Suchserver oder verstaut sie in einer anderen Datenablage, dem Target Repository (Abbildung 1).

Abbildung 1: Die Systemarchitektur mit dem Norconex Collector und Solr.

Die Kollektoren skalieren in gewissen Grenzen: So lassen sich mehrere parallel ausgeführte Crawler mit jeweils einem Importer und Committer betreiben. Der Importer greift auf konfigurierbare Module zurück, um die extrahierten Texte zu bearbeiten und die Metadaten im Nachhinein zu verändern. Dieser Funktionsumfang ersetzt und übertrifft die bisher vorgestellten Verfahren der Dokumentenverarbeitung innerhalb von Manifold CF in jeder Hinsicht. Zudem lässt die ausgezeichnete Dokumentation [13] keine Wünsche offen.

Die beiden Norconex-Kollektoren besitzen wegen des weitgehend identischen Designs viele gemeinsame Eigenschaften. Die integrierte Tika-Bibliothek extrahiert Text und Metadaten, bestimmt die Dokumentensprache und stellt eine OCR-Funktion bereit. Wie schon in einem vorherigen Artikel erörtert, verarbeitet Tika dabei eine Vielzahl von Dokumentenformaten. Dazu zählen Office- und Multimedia-Dateien, PDFs und Webseiten [14]. Bei Bedarf bindet der Entwickler auch externe Parser ein.

Den Funktionsumfang ergänzen zudem verschiedene Authentifizierungsmethoden, mit Javascript gerenderte Webseiten, Sitemaps, der Robots-Exclusion-Standard und Cookies. Kommt es zum Absturz, nehmen die Kollektoren ihre Arbeit an der vorherigen Position wieder auf. Die besuchten URLs speichern sie in einer der drei verschiedenen Datenablagen: dem Key-Value-Store MV-Store, der NoSQL-Datenbank MongoDB sowie der relationalen Datenbank H2 via JDBC.

Entwickler finden viele Optionen, um die Implementierung mit externen Skripten und Programmen fast beliebig zu ergänzen. Als zusätzliches Schmankerl gestattet es ein Event-Listener-Interface, Programme abzuspulen, sobald der Crawler bestimmte Ereignisse erkennt.

Importer

Die Document Processing Pipeline ermöglicht es, die Daten zu filtern und zu modifizieren. Sie verarbeitet auch Dokumente, die in Containern vorliegen (ZIP- und Office-Dateien). Sie übersetzt Dokumente mit gängigen Translation-APIs in andere Sprachen, splittet sie nach bestimmten Kriterien oder schließt sie aufgrund des Inhalts oder wegen bestimmter Dokumenteneigenschaften von der Verarbeitung ganz aus.

Der Importer stellt eine Fülle von Funktionen zum Extrahieren, Filtern und Modifizieren von Text und Metadaten bereit. Letztere lassen sich aus den Eigenschaften des Dokuments oder den Informationen im HTML-Header ableiten. Vor und nach der Dokumentenanalyse übernehmen Tagger, Filter, Transformer und Splitter die weitere Verarbeitung (siehe Tabelle 1).

Committer

Der Committer liefert Dokumententext und Metadaten an das Backend. Norconex unterstützt viele wichtige Backends, darunter Solr, Elasticsearch, SQL Server, Neo4j, Lucidworks, Idol, Apache Kafka, Amazon Cloudsearch, Google Cloud Search und Microsoft Azure. Das schließt auch gewöhnliche Dateien im XML- oder JSON-Format ein, die das Dateisystem bereitstellt.

Kommandosache

Um den Kollektor zu starten und zu stoppen, gibt es einen Wrapper namens »collector.sh« (oder notfalls »collector.bat«), dem der Admin eine Konfigurationsdatei mit auf den Weg gibt. Ein Beispiel:

$ collector.sh -a start -c lmde-config.xml

Nach dem Start verwirren zunächst ein paar Fehlermeldungen, denn die Java-VM beschwert sich über nicht aufgelöste Abhängigkeiten. Aus lizenzrechtlichen Gründen fehlen zwei JAR-Archive, die der Admin aber leicht beschaffen kann [15]. Die Dateien verschiebt er in das Verzeichnis »lib/« des Norconex-Collectors.

Der Wrapper beendet sich nach einem Durchgang, weshalb weitere Hilfsmittel wie Cron für einen automatisierten Ablauf unerlässlich sind. Immerhin speichert der Kollektor alle dafür benötigten Daten inklusive Linkstruktur und Zeitstempel intern. Allerdings beherrscht der Committer keine Atomic Updates, weshalb geänderte Feldinhalte (etwa in den Metadaten) aufgrund einer Modifikation der Pipeline nicht im Index landen. Geänderte Seiteninhalte resultieren aber in einer Neuindexierung.

Unter JEFs Kontrolle

Auf Wunsch kann das Job Execution Framework (JEF) die Crawler ähnlich wie Manifold CF via API [16] oder als Webapplikation überwachen. Der Funktionsumfang hält aber nicht mit jenem von Manifold CF mit, sondern beschränkt sich auf die grafische Anzeige von Status und Fortschritt der verschiedenen Crawl-Jobs. JEF lässt sich als Shell-Skript starten und danach über einen konfigurierbaren Port via Browser ansprechen, standardmäßig unter http://localhost:8080. Entwickler erweitern JEF über das JEF-API um diverse Job-Aktivitäten; Abbildung 2 zeigt JEF in Aktion.

Abbildung 2: Der Job-Monitor JEF visualisiert, in welchem Stadium sich die verschiedenen Arbeitsaufträge befinden.

Startpunkt

Wie in den vorherigen Artikeln der Serie stehen die Inhalte der zu durchsuchenden Artikeldateien in der Originalstruktur der Mega-Archiv-DVD aus LM 10/2019 oder auf der Jahrgangs-DVDs auf dem Webserver bereit. Alle nötigen Konfigurationsdateien warten wieder auf dem Listing-Server [17].

Ausgehend von mindestens einer Start-URL wühlt sich der Crawler durch das Archiv der Linux-Magazin-Ausgaben. Die Startadresse (Listing 1) muss zur Ablage auf dem Webserver passen, wie es Listing 1 für die Jubiläums- und die Jahrgangs-DVD zeigt. Der Crawler verdaut an dieser Stelle auch Dateien mit URL-Listen, Sitemaps und dynamisch generierte URLs. Mehrere URL-Angaben auch gemischten Typs sind erlaubt, sämtliche Details liefert die Doku [10].

<startURLs stayOnDomain="true" stayOnPort="true" stayOnProtocol="true">
  <!-- Archiv-DVD 25 Jahre LM -->
  <url>http://host1:Port1/Pfad1/html/index.html</url>
  <!-- Jahrgang 2019 -->
  <url>http://host2:Port2/Pfad2/2019/html/index.html</url>
</startURLs>

Linkverfolgung

Das Indexieren einer Webseite setzt voraus, dass ein Link auf die Seite existiert und das Dokument selbst bestimmte Eigenschaften aufweist (MIME Type, Ablageort, Text). Der HTTP Collector kennt umfangreiche Methoden, um Links zu extrahieren (»linkExtractor«), extrahierte Links vor dem Dokumenten-Download zu filtern (»referenceFilters«) und geladene Dokumente basierend darauf auszusortieren (»documentFilters«). Die Kenntnis der Seiteninterna erlaubt eine beträchtliche Leistungsoptimierung, da der Crawler nicht allen gefundenen Links folgen oder sämtliche Dokumente herunterladen muss.

Die Artikeldateien der DVDs liegen ausschließlich im HTML-Pfad des Stammverzeichnisses. Alle weiteren Unterverzeichnisse haben zwar ihre Daseinsberechtigung, enthalten aber für die Linkverfolgung und Volltextindexierung irrelevante Listings, Bilder und anderes Beiwerk (Listing 2 und Listing 3).

<linkExtractors>
  <extractor class="$linkExtractor"
    ignoreExternalLinks="true" charset="UTF-8">
    <contentTypes>text/html</contentTypes>
    <noExtractSelector>header</noExtractSelector>
    <noExtractSelector>footer</noExtractSelector>
    <noExtractSelector>script</noExtractSelector>
    <noExtractSelector>a.url</noExtractSelector>
    <extractSelector>li</extractSelector>
    <extractSelector>td</extractSelector>
    <extractSelector>p</extractSelector>
    <tags><tag name="a" attribute="href"/></tags>
  </extractor>
</linkExtractors>

<referenceFilters>
  <filter class="$filterRegexRef" onMatch="include">
    .*/html/.*\.html$
  </filter>
  <filter class="$filterRegexRef" onMatch="exclude">
    (?!.*/html/.*\.html$)
  </filter>
  <filter class="$filterExtension onMatch="exclude">
    pdf,jpg,jpeg,tif,tiff,gif,png,ico,css,js,php
  </filter>
  <!-- Jahrgangsfilter bei Bedarf -->
  <!--
  <filter class="$filterRegexRef" onMatch="exclude">
    .*/2019/.*
  </filter>
  -->
</referenceFilters>

Die Dokumentenfilter sieben die unerwünschten, nur aus organisatorischen Gründen vorhandenen Webseiten (»index«-Dateien) aus. Zudem erlauben sie den Zugriff auf Artikeldateien abhängig von der Ablagestruktur von Archiv- und Jahrgangs-DVDs (Listing 4). Die überflüssigen Indexdateien befinden sich in der Ablagestruktur auf Heft-, Monats- und Jahrgangsebene. Bei Jahrgangs-DVDs existiert der Jahrgangsindex nicht.

<documentFilters>
  <!--Archiv-DVDs -->
  <filter class="$filterRegexRef" onMatch="exclude">
    .*/html/(?:\d{4}/(?:\d{2}/)?)?index\.html$
  </filter>
  <!--Jahrgangs-DVDs -->
  <filter class="$filterRegexRef" onMatch="exclude">
    .*/\d{4}/html/(?:\d{2}/)?index\.html$
  </filter>
</documentFilters>

Hat der Crawler schließlich eine aussichtsreiche Seite gefunden, die alle bisherigen Anforderungen an die URL erfüllt, schleust er den Seiteninhalt in die Verarbeitungskette ein, die aus Importer und Committer besteht. Ersterer implementiert die Document Processing Pipeline. Die zentrale Rolle spielt der auf Tika basierende Dokumenten-Parser, der Dokumenteninhalte und Metadaten trennt. Doch auch vor und nach diesem Prozess lassen sich Dokumente und Metadaten noch vielfältig modifizieren. Tabelle 1 fasst die dabei einsetzbaren Schlüsselkomponenten zusammen.

Textfilterung

Bevor Tika die HTML-Datei in die Finger bekommt, entfernt der Entwickler überflüssige Passagen, indem er auf die HTML-Struktur zurückgreift oder Zeichenketten angibt, was die Textextraktion in vielen Fällen verbessert. Das blendet unter anderem die Navigationselemente am Anfang der Artikeldateien sowie andere Elemente elegant aus (Listing 5), die im ersten Teil der Serie die Qualität der Textextraktion stark reduziert und eine vernünftige Spracherkennung verhindert haben.

<transformer class="$stripBetweenTransformer" inclusive="false">
  <stripBetween>
    <start><![CDATA[<header id="main_head">]]></start>
    <end><![CDATA[</nav></header>]]></end>
  </stripBetween>
  <stripBetween>
    <start><![CDATA[<footer>]]></start>
    <end><![CDATA[</footer>]]></end>
  </stripBetween>
  <stripBetween>
    <start><![CDATA[<script>]]></start>
    <end><![CDATA[</script>]]></end>
  </stripBetween>
</transformer>

Sprache ermitteln

Tika kann nicht nur Texte extrahieren und Metadaten eines Dokuments generieren, sondern auch die Sprache des Dokumententexts identifizieren. Das ist von besonderer Bedeutung, weil Datafari die Sprache kennen muss, um Suchanfragen zu bilden. Den grundlegenden Mechanismus beschreibt der erste Teil der Serie im Detail, der die Sprachenerkennung innerhalb der Solr Update Chain umsetzte.

Der fast unerschöpfliche Tagger-Fundus bietet ein eigenes, ebenfalls auf Tika basierendes Modul mit identischer Funktion. Es kann aber der in Solr als Update Processor implementierten Lösung weder in Bezug auf Funktionalität noch hinsichtlich der Konfigurierbarkeit das Wasser reichen. Die Sprachenerkennung in Solr leistete sich bei über 7000 Dokumenten nur zwei Schnitzer, Norconex klassifiziert dagegen rund 20 Dokumente falsch.

Hier bietet sich also die Solr-Lösung auch weiterhin an. Der Entwickler perfektioniert sie, indem er die korrekte Sprache der Norconex-Pipeline für beide Ausnahmen einfach auf »de« einstellt. Dabei hilft ein »constantTagger«, der auf die URLs der Sonderfälle lauscht und passend reagiert (Listing 6).

<tagger class="$constantTagger">
  <restrictTo field="document.reference">
    .*/html/2002/12/award/nominees.html$
  </restrictTo>
  <restrictTo field="document.reference">
    .*/html/2000/07/MPorty/mporty.html$
  </restrictTo>
  <constant name="language">de</constant>
</tagger>

Zahlreich

Listing 7 definiert eine Tagger-Kaskade, um Heftnummer und Jahrgang zu bestimmen. Sie extrahiert die gewünschten Daten aus dem Titel (»title«-Tag) und kürzt anschließend das Titelfeld, weil die Information sonst redundant ist. Aus dem Dateinamen leitet der Entwickler die Seitenzahlen ab, bei denen der Artikel beginnt und endet (Listing 8).

<tagger class="$replaceTagger">
  <replace fromField="title" toField="issue" regex="true">
    <fromValue>^.*-\sLinux-Magazin\s(\d{2})/\d{4}$</fromValue>
    <toValue>$1</toValue>
  </replace>
  <replace fromField="title" toField="year" regex="true">
    <fromValue>^.*-\sLinux-Magazin\s\d{2}/(\d{4})$</fromValue>
    <toValue>$1</toValue>
  </replace>
  <replace fromField="title" regex="true">
    <fromValue>\s-\sLinux-Magazin\s\d{2}/\d{4}</fromValue>
    <toValue></toValue>
  </replace>
</tagger>

<tagger class="$replaceTagger">
  <restrictTo field="resourcename">^\d{3}.*</restrictTo>
  <replace fromField="resourcename" toField="pageno" regex="true">
    <fromValue>^(\d{3})(?:_|-)(?:.*)</fromValue>
    <toValue>$1</toValue>
  </replace>
</tagger>
<tagger class="$replaceTagger">
  <restrictTo field="resourcename">^\d{3}-\d{3}.*</restrictTo>
  <replace fromField="resourcename" toField="pagend" regex="true">
    <fromValue>^(?:\d{3})-(\d{3})_(?:.*)</fromValue>
    <toValue>$1</toValue>
  </replace>
</tagger>

Geistreich

Die Dachzeile eines Artikels spielt eine wesentliche Rolle, denn sie gibt in der Regel dessen tatsächlichen Inhalt wieder. Im »title«-Tag wartet hingegen eher eine geistreiche Umschreibung. Die Dachzeile erreicht der Entwickler geschmeidig mit CSS-Selektoren (Listing 9). Vier DOM-Tagger decken alle Kodierungsvarianten ab und liefern am Ende – hoffentlich – das gewünschte Ergebnis.

Beim Auszeichnen der Dachzeile mit »<h>«-Tags tanzen allerdings immer mal wieder einige Artikel aus der Reihe und geraten mit Zwischenüberschriften in Konflikt. Um wirklich nur eine Zeile zu erbeuten, schaltet der Entwickler deshalb einen »singleValueTagger« nach, der bis auf die erste gefundene Zeile alle weiteren verwirft.

<tagger class="$domTagger">
  <dom overwrite="true" selector="tr td h4" toField="headline"/>
  <dom overwrite="true" selector="table.old_article_header h4" toField="headline"/>
  <dom overwrite="true" selector="article section h4" toField="headline"/>
  <dom overwrite="true" selector="header
 section h2" toField="headline"/>
</tagger>
<tagger class="$singleValueTagger">
  <singleValue field="headline" action="keepFirst"/>
</tagger>

Die meisten Verarbeitungsmodule der Pipeline handeln bei Bedarf in Abhängigkeit vom Inhalt bestimmter Metadaten; die jeweilige Bedingung beschreibt ein regulärer Ausdruck. Text und Metadaten in Abhängigkeit von Bedingungen zu modifizieren, ist eine segensreiche Konstruktion, die der Datafari-User in der Solr Update Chain vergeblich sucht.

Entwickler nutzen diesen Mechanismus, um einen Ersatztitel zu finden, falls die Artikeldatei selbst keinen anbietet. Freundlicherweise versteckt sich der gesuchte Titel im meist blau dargestellten, anklickbaren Ankertext des Links, der auf den Artikel referenziert. Suchmaschinen haben den Link-Text schon immer gern herangezogen, um die Relevanz des Links und der referenzierten Seite zu bestimmen.

Die Tagger-Definition in Listing 10 fällt selbsterklärend aus. Sie ersetzt die bisher herangezogene Krücke, den Dateinamen als Titelersatz zu wählen und daraus einen Artikeltitel abzuleiten. Die Collector-Konfiguration »lmde-config.xml« [13] hält noch ein paar andere, hier nicht gezeigte Anwendungen für Tagger in der Pipeline.

<tagger class="$copyTagger">
  <restrictTo field="title">^$</restrictTo>
  <copy fromField="collector.referrer-link-text" toField="title" overwrite="true"/>
</tagger>

Solr-Anbindung

Der Solr-Committer verwendet mit dem Update Request Handler das Standard-Interface von Solr. Daher fungiert hier, wie in den vorigen Teilen dieser Serie, Datafari [1] mit der bekannten GUI als Suchserver.

Der Committer benötigt die Adresse des Solr-Endpunkts einschließlich des Namens der Kollektion (hier »FileShare«). Zum Einsatz kommt eine bis auf die wesentlichen Bestandteile abgespeckte Variante der ursprünglichen Datafari-Update-Chain, um den hochfrequenten Änderungen im Datafari-Update-Prozessor aus dem Weg zu gehen.

Auf dem Listing-Server [17] liegt eine Solr-Konfigurationsdatei »norconex-updchain.xml« mit einer passenden Update Chain, die der Admin an den Inhalt der angepassten Konfiguration »custom_request_handlers.inc« anhängt und über das Admin-UI von Manifold CF und Zookeeper lädt. Details dazu verrät Teil 1 der Serie.

Die URL-Parameterliste im Solr Committer erhält einfach den Namen der Update Chain (Listing 11), sodass Datafaris Standard-Update-Handler (»/update«) auch mit dem Norconex-Collector funktioniert. Das Sucherlebnis kann sich sehen lassen, wie Abbildung 3 belegt – nicht nur wegen der Garnierung mit zusätzlichen Metainformationen (Publikation, Seitenzahlen, Jahrgang, Dachzeile).

<committer class="$solrCommitter">
  <solrURL>http://localhost:8983/solr/FileShare/</solrURL>
  <solrUpdateURLParams>
    <param name="update.chain">norconex</param>
  </solrUpdateURLParams>
  <sourceReferenceField>document.reference</sourceReferenceField>
  <targetReferenceField>id</targetReferenceField>
  <queueSize>100</queueSize>
  <commitBatchSize>50</commitBatchSize>
</committer>

Abbildung 3: Datafari garniert die Suchergebnisse mit Metadaten und einer Textvorschau.

Schattenseiten

Ärgerlicherweise kann der Norconex-Collector nicht mehrere Datenquellen verknüpfen, um ein zusammengeführtes Dokument zu erzeugen. Deshalb lassen sich die Metadaten nicht zusätzlich um Thema und Schlagwort erweitern, die aus einer übergeordneten Indexdatei stammen. Zwei Lösungsansätze kamen bereits im dritten und vierten Teil dieser Serie zur Sprache.

Es bietet sich an, entweder den Index nachträglich über einen zweiten Durchlauf anzureichern oder zum Data Import Handler (DIH) zu greifen, der Metadaten aus der übergeordneten Indexdatei und der Artikeldatei in einem Rutsch auswertet. Die so generierten Facetten für Thema und Schlagwort helfen dabei, die Suchresultate einzuschränken. Allerdings beschränken sich beide Verfahren auf Jahrgangs-DVDs, da nur diese zusätzliche Informationen zu Thema und Schlagwort bereitstellen.

PDF-Dateien

Tika ist der Standard-Parser im Importer und zerlegt auch PDF-Dateien. In dieser Rolle kam die Software bereits in Teil 3 der Reihe beim Indexieren der PDFs des englischsprachigen Linux Magazine zum Einsatz. Dabei zeigte sich, dass die Dokumente im Index nicht einmal einen Titel besaßen; den PDFs der Artikel fehlen die Metainformationen. Das bügelte ein Atomic Update des Index aus, das diesen um die in einem zusätzlichen Indexierungslauf gewonnenen Metadaten ergänzte.

Der Norconex HTTP Collector hingegen zieht den Text aus dem Link der Indexdatei heran, die auf den Artikel verweist, und stellt ihn in den Metadaten als Ersatztitel bereit. Das erlaubt es, eine dem früheren Verfahren in nichts nachstehende Indexierungsmethode einzusetzen. Der Admin ruft den Kollektor mit der vorbereiteten Konfigurationsdatei »lmen-pdf-config.xml« [13] auf und freut sich, dass der zweite Indexierungslauf entfällt.

Dummerweise klappt eine Indexierung der ähnlich Metadaten-freien PDFs des LinuxUser nicht auf diese Weise. Die Links auf die Artikeldateien enthalten nicht den gesuchten Titel, sondern schlicht und einfach »PDF«. Da hilft auch die blaue Farbe nicht weiter. Die gesplitteten PDFs von c’t, iX und LinuxWelt erwischt der Norconex-Kollektor [3] hingegen, da sie alle geforderten Metainformationen für das in Teil 3 vorgestellte Verfahren mitbringen.

#!/bin/bash
curl http://localhost:8983/solr/FileShare/update?commit=true \
  -H "Content-Type: text/xml" --data-binary \
  '<delete><query>
    publication:Linux-Magazin AND year:2019
  </query></delete>'

Nachlese

Tabelle 2 subsumiert noch einmal die Funktionen zum Filtern von Texten und zur Metadatenbehandlung der in dieser Serie vorgestellten Varianten zur Indexierung. Alle in der Tabelle aufgeführten Varianten unterstützen die Solr Update Chain. Fehlende Funktionen lassen sich im Rahmen ihrer Mittel nachrüsten. Insbesondere gehört hierzu die vielseitig parametrisierbare Spracherkennung.

Der Data Import Handler erlaubt es als einzige Methode, mehrere Datenquellen zu bündeln. Die Transformer und Tagger von Norconex decken einen wesentlich größeren Funktionsumfang ab als die Solr-Prozessoren. Manifold CF benötigt ohne Tuning gegenüber seinen Konkurrenten die fünfzehnfache Ausführungszeit.

Während eine Fülle von Verfahren bereitsteht, um HTML-Dokumente zu indexieren, ist das Bearbeiten unstrukturierten Materials nicht nur im PDF-Format naturgemäß eingeschränkt.

Fazit

Als Standalone-Tool sollten Entwickler die Norconex-Kollektoren immer dann der schwerfälligen, auf MCF basierenden Lösung vorziehen, wenn sie auf die umfangreichen Zusatzangebote von MCF verzichten können und JEF zur Jobüberwachung genügt. Die Document Processing Pipeline der Kollektoren ist schlüssig modularisiert und besitzt ein konsequentes Design. Sie schlägt hinsichtlich des Funktionsumfangs, der Qualität der Textfilterung und den Möglichkeiten zur Gewinnung von Metadaten alles, was bisher zum Einsatz kam. Programmierer bringen außerdem an praktisch jeder Stelle eigenen Code in die Verarbeitungskette ein.

Insgesamt verfügen die Norconex-Crawler über wesentliche Standardtugenden wie Robustheit, Skalierbarkeit, Höflichkeit gegenüber Webservern sowie Performance. Sie befinden sich damit in bester Gesellschaft mit Nutch, Heritrix, Storm Crawler, Crawler4j und Scrapy, um nur einige zu nennen. Viele Open-Source-Implementierungen erweisen sich für diesen Anwendungsfall und ähnliche Szenarien entweder als Overkill oder lassen sich, da es sie nur als Framework gibt, nicht sofort ohne Programmierung einsetzen. Manche entpuppen sich auch schlicht als Eintagsfliegen ohne fortlaufende Weiterentwicklung. (kki)