Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 13 Min.

Eine eigene Suchmaschine bauen (Teil 5): Suchaktion


Linux Magazin - epaper ⋅ Ausgabe 3/2020 vom 06.02.2020

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


Artikelbild für den Artikel "Eine eigene Suchmaschine bauen (Teil 5): Suchaktion" aus der Ausgabe 3/2020 von Linux Magazin. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: Linux Magazin, Ausgabe 3/2020

© tsstockphoto, 123RF

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 nötigen Komponenten, darunter den vielseitigen Zugriff auf mehrere Datenquellen mithilfe von Apache Manifold CF ...

Weiterlesen
epaper-Einzelheft 5,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Linux Magazin. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 3/2020 von Für und Wider. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Für und Wider
Titelbild der Ausgabe 3/2020 von News. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News
Titelbild der Ausgabe 3/2020 von Zahlen & Trends. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zahlen & Trends
Titelbild der Ausgabe 3/2020 von Weshalb Edge Computing nötig und wie es realisierbar ist: Rechnen im Außendienst. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Weshalb Edge Computing nötig und wie es realisierbar ist: Rechnen im Außendienst
Titelbild der Ausgabe 3/2020 von Edge in der Operational Technology: Leicht hinterher. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Edge in der Operational Technology: Leicht hinterher
Titelbild der Ausgabe 3/2020 von Interview mit „State-of-the-Edge“-Herausgeber Matt Trifiro: „Edge ist ein Ort“. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Interview mit „State-of-the-Edge“-Herausgeber Matt Trifiro: „Edge ist ein Ort“
Vorheriger Artikel
Der Xen-Hypervisor XCP-ng: Der Thronfolger
aus dieser Ausgabe
Nächster Artikel Bundesdatenschutzbeauftragter warnt vor Wettlauf der Sicherheitsb…
aus dieser Ausgabe

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 nötigen Komponenten, darunter den vielseitigen Zugriff auf mehrere Datenquellen mithilfe von Apache Manifold CF (MCF, [2]) und dem Solr-Backend. Ein übersichtliches GUI liefert 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 die Velocity Engine von Apache [4] für XML-Templates ein, eröffnen sich ihm auch die vielen Möglichkeiten einer Skriptsprache. So recycelt er über diverse Direktiven XML-Fragmente, definiert Variablen und steuert den Kontrollfluss mit Schleifen oder bedingungsabhängig.

Crawler

Das Internet hält eine fast unüberschaubare Fülle von Informationen zur mehr als 20-jährigen Historie [5], [6] der Webcrawler parat. Dazu zählen Theorien und Geschichten über ihre Evolution, angefangen beim ehrwürdigen Mercator (Altavista Crawler [7]) über UbiCrawler [8] bis hin zu noch jungen Vertretern 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 die Enterprise-Suche 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 Dateiabla- gen 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).

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 übertrifft die bisher vorgestellten Verfahren der Dokumentenverarbeitung mit Manifold CF in jeder Hinsicht. Zudem lässt die ausgezeichnete Dokumentation [13] keine Wünsche offen. Die beiden Norconex-Kollektoren haben 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 Officeund 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 einmal zum Absturz, nehmen die Kollektoren ihre Arbeit an der vorherigen Position wieder auf. Die besuchten URLs speichern sie in einer der drei Datenablagen: dem Key-Value-Store MV-Store, der NoSQLDatenbank MongoDB sowie der relationalen Datenbank H2 via JDBC.

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


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 Backends, darunter Solr, Elasticsearch, SQL Server, Neo4j, Lucidworks, Idol, Apache Kafka, Amazon Cloudsearch, Google Cloud Search und Microsoft Azure. Das schließt auch 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 HTMLAdmin aber leicht beschaffen kann [15]. Die Dateien schiebt er in das Verzeichnis »lib/« des Norconex-Collectors.

Der Wrapper beendet sich nach einem Durchgang, das macht Hilfsmittel wie Cron für einen automatisierten Ablauf unerlässlich. Immerhin speichert der Kollektor alle dafür nötigen Daten inklusive Linkstruktur und Zeitstempel intern. Doch 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 stoßen aber eine Neuindexierung an.

Unter JEFs Kontrolle

Auf Wunsch kann das Job Execution Framework (JEF, [16]) die Crawler ähnlich wie Manifold CF via API oder als Webapplikation überwachen. Der Funktionsumfang hält aber nicht mit dem von Manifold CF mit, JEF zeigt nur Status und Fortschritt der Crawl-Jobs grafisch an. Das Framework lässt sich als Shell- Skript starten und über einen konfigurierbaren Port via Browser ansprechen, per Default unter [http:// localhost: 8080]. Entwickler erweitern JEF über das JEFAPI um diverse Job-Aktivitäten; Abbildung 2 zeigt JEF in Aktion.

Startpunkt

Wie in den vorherigen Artikeln dieser Serie stellt ein Webserver die Inhalte der zu durchsuchenden Artikeldateien in der Originalstruktur der Mega-Archiv-DVD aus LM 10/ 2019 oder auf den Jahrgangs- DVDs bereit. Die 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 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.

Linkverfolgung

Zum Indexieren einer Webseite muss ein Link auf diese existieren und das Dokument selbst bestimmte Eigenschaften aufweisen (MIME Type, Ablageort, Text). Der HTTP Collector kennt Methoden, um Links zu extrahieren (»linkExtractor«), extrahierte Links vor dem Dokumenten- Download zu filtern (»referenceFilters«) und geladene Dokumente basierend darauf auszusortieren (»documentFilters«). Kennt er die Seiteninterna, muss der Crawler nicht allen gefundenen Links folgen oder alle Dokumente herunterladen, was seine Leistung verbessert.

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).

Die Dokumentenfilter sieben unerwünschte, nur aus organisatorischen Gründen vorhandene 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. Hat der Crawler eine aussichtsreiche Seite gefunden, die alle 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 Inhalte und Metadaten trennt. Doch auch davor und danach lassen sich Dokumente und Metadaten vielfältig modifizieren. Tabelle 1 fasst die einsetzbaren Schlüsselkomponenten zusammen.

Textfilterung

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

Sprache ermitteln

Tika extrahiert nicht nur Texte und erzeugt Metadaten eines Dokuments, sondern identifiziert auch die Sprache des Dokumententexts. Das ist wichtig, weil Datafari die Sprache kennen muss, um Suchanfragen zu bilden. Den Mechanismus beschreibt Teil 1 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 auf Konfigurierbarkeit das Wasser reichen. Die Spracherkennung in Solr leistete sich bei über 7000 Dokumenten nur zwei Schnitzer, Norconex klassifiziert dagegen rund 20 Dokumente falsch.

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

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).

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


Geistreich

Die Dachzeile der Artikel spielt eine zentrale Rolle, denn sie gibt meist ihren eigentlichen Inhalt wieder. Im »title«-Tag warten hingegen eher geistreiche Umschreibungen. Die erste erreicht der Entwickler über CSS-Selektoren (Listing 9), vier DOM-Tagger decken alle Kodierungsvarianten ab und liefern - hoffentlich - das gewollte Resultat.

Beim Auszeichnen der Dachzeile mit Tags tanzen aber immer mal wieder Artikel aus der Reihe und geraten mit Zwischenüberschriften in Konflikt. Um wirklich nur eine Zeile zu holen, schaltet der Entwickler einen singleValueTagger nach, der bis auf die erste gefundene Zeile alle weiteren verwirft.

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 ge- suchte Titel im meist blau dargestellten, anklickbaren Ankertext des Links, der auf den Artikel verweist. Suchmaschinen ziehen den Link-Text traditionell gern heran, 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« [17] hat noch weitere, hier nicht gezeigte Anwendungen für Tagger in der Pipeline.

Solr-Anbindung

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 Suchergebnis kann sich sehen lassen, wie Abbildung 3 belegt - nicht nur wegen der Garnierung mit zusätzlichen Metainformationen (Publikation, Seitenzahlen, Jahrgang, Dachzeile).

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 aus 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.

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


PDF-Dateien

Tika zerlegt als Standard-Parser im Importer auch PDF-Dateien und kam in Teil 3 der Reihe beim Indexieren der PDFs des englischsprachigen Linux Magazine zum Zug. Dabei zeigte sich, dass die Dokumente im Index keinen Titel besaßen; den PDFs der Texte 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 ist eine dem früheren Verfahren in nichts nachstehende Indexierungsmethode. Der Admin ruft den Kollektor mit der Konfigurationsdatei »lmen‑pdf‑config.xml« [17] 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 Linux- Welt erwischt der Norconex-Kollektor [3] hingegen, da sie alle geforderten Metainformationen für das in Teil 3 vorgestellte Verfahren mitbringen.

Nachlese

Tabelle 2 subsumiert die Funktionen zum Filtern von Texten und zur Metadatenbehandlung der 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 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 vielen 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 zudem 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)

Infos

[1] Datafari: [http:// www. datafari. com]

[2] Manifold CF: [https:// manifoldcf. apache. org]

[3] Norconex-Kollektoren: [http:// www. norconex. com/ collectors/]

[4] Apache Velocity: [http:// velocity. apache. org]

[5] „A Brief History of Web Crawlers“: [http:// ssrg. eecs. uottawa. ca/ docs/ CASCON2013. pdf]

[6] Webcrawler-Geschichte: [https:// en. wikipedia. org/ wiki/ Web_ crawler]

[7] Mercator Crawler: [http:// www. cs. cornell. edu/ courses/ cs685/ 2002fa/ mercator. pdf]

[8] UbiCrawler: [http:// vigna. di. unimi. it/ ftp/ papers/ UbiCrawler. pdf]

[9] Bubing Crawler: [http:// law. di. unimi. it/ software. php# bubing]

[10] Norconex: [https:// www. norconex. com]

[11] Norconex HTTP Collector: [https:// github. com/ Norconex/ collector‑http/]

[12] Norconex Filesystem Collector: [https:// github. com/ Norconex/ collector‑filesystem]

[13] HTTP-Collector-Dokumentation: [https:// www. norconex. com/ collectors/ collector‑http]

[14] Tika-Dateiformate: [https:// www. norconex. com/ collectors/ importer/ formats]

[15] Hinweise zum Download: [https:// github. com/ Norconex/ collector‑http/ issues/ 611]

[16] JEF: [https:// www. norconex. com/ jef]

[17] Alle Dateien zum Artikel: [http:// www. linux‑magazin. de/ static/ listings/ magazin/ 2020/ 03/ datafari]

Datafari-Update

Die Datafari-Entwicklung bleibt nicht stehen: Seit dem Erscheinen von Teil 1 gab es bereits ein Datafari-Update. Mit ihm kommen einige Änderungen an der grafischen Oberfläche, die wiederum eine Aktualisierung der Patch-Datei für die Präsentation der Suchergebnisse erfordern. Die neue Version der Patch-Datei wartet ebenfalls auf dem Listing- Server [17]. Wahrscheinlich wird die in Kürze aufgelegte Datafari-Version 4.4 zudem eine angemessene Indexierung deutschsprachiger Inhalte erlauben. Das macht dann die im ersten Teil der Serie unternommenen Anstrengungen zur Lokalisierung überflüssig; Schaden richten sie allerdings auch dann nicht an.

Hoppla, ein Doppla!

Bis zur nächsten Jubiläumsausgabe des Linux- Magazins überbrücken Jahrgangs-DVDs die Zeit. Beim Aktualisieren des Suchindex treten dabei aber Überschneidungen der Inhalte von Archiv- und Jahrgangs-DVDs auf, wenn identische Artikeldateien von verschiedenen Medien stammen, die auf dem Webserver an unterschiedlichen Orten mit unterschiedlichen URLs liegen. Der Admin könnte die Dateien entweder explizit in eine gemeinsame Depotstruktur zwängen oder den überlappenden Bereich der Heftausgaben im Index löschen, bevor weitere Dokumente hinzukommen.

Das Shellskript aus Listing 12 dient als Beispiel für eine Löschanfrage. Sie wirft den (nicht vollständigen) Linux-Magazin-Jahrgang 2019 der Mega-Archiv-DVD aus dem Solr-Index. Im Anschluss daran indexiert der um die Start-URL des Jahres 2019 ergänzte Crawl-Job die Artikel vollständig, ohne Dubletten mit mehreren URLs im Index zu hinterlassen

Als weitaus eleganterer Ausweg entpuppt sich der Einsatz der Dublettenerkennung in der Solr Update Chain. Der bereitstehende Signaturprozessor der Datafari-Chain bildet aus dem Wert vorgegebener Felder mit verschiedenen Algorithmen eine Prüfsumme und überschreibt Dokumente mit identischer Prüfsumme im Index. Hier identifiziert der Text im - Tag - er umfasst Artikeltitel, Magazinnamen, Jahrgang und Heftnummer - zusammen mit dem Dateinamen jeden Artikel eindeutig. Er dient damit als Basis für den Fingerabdruck. Der Dateiname ist nötig, weil der Archivar sonst Artikel verliert, die im selben Heft dieselben Titel besitzen. Das kommt im Zusammenhang mit der Rubrik „News“ gelegentlich vor.

Die Prüfsumme liegt unabhängig vom Ablagepfad auf dem Archivmedium oder dem Webserver, was ein pflegeleichtes Trennen der Quellmedien auf dem Webserver gewährleistet. Mit jeder neuen Jahrgangs-DVD muss der Archivar also nur eine weitere Start-URL konfigurieren (Listing 1). Das Format der Tags stimmt seit dem Jahrgang 2011 mit demjenigen aller bisher erschienenen Archiv-DVDs überein, weshalb sich alle Jahrgangs-DVDs seit 2011 ohne weitere Konfigurationsänderung dazu eignen, das Archiv zu erweitern. Die Konfiguration [16] des Signaturprozessors läuft in der Update Chain unter dem Namen

Erratum

Im dritten Teil dieser Reihe hat sich in der Tabelle 1 („Neue MCF-Jobs für die Indexierung“) ein Fehler eingeschlichen: In der letzten Spalte muss es im Fall der Magazine iX und c’t jeweils SolrCell statt HTML Extractor heißen - Letzterer kommt nicht zum Einsatz, da es sich um PDFs handelt.