Überblick

Allgemeiner Aufbau

Mit der Recherche-Infrastruktur können verschiedene Datenquellen vereinheitlicht verwaltet, importiert und daraus beliebige Recherche-Portale bereitgestellt werden.

Die generelle Strategie für das Management sehr vieler verschiedener Datenquellen ist deren Separierung in der Infrastruktur. Eine Datenquelle wird genau einem Katalog bzw. (Daten)Pool in der Infrastruktur zugeordnet. Durch diese Separierung kann individuell auf die Besonderheiten einer jeden Datenquelle eingegangen werden, z.B. verschiedene Quell-Formate, Umwandlungen und nachträgliche Manipulationen der Daten in der Import-Pipeline.

Ein Katalog/Pool in der Infrastruktur besteht aus einer eigenständigen PostgreSQL-Datenbank sowie einem eigenständigen Suchindex in einer oder mehreren unterstützten Suchmaschinen - derzeit Xapian und Elasticsearch. Recherchen erfolgen in der Regel in dem Suchindex, Einzeltreffer, Register usw. werden aus der PostgreSQL-Datenbank geholt. Gerade die kategorieweise Ablage der Daten in der PostgreSQL-Datenbank ermöglicht weitere datenbasierte Dienste, die mit nur einem Suchindex so nicht möglich wären.

Die Recherche-Infrastruktur mit OpenBib besteht aus folgenden Komponenten, die verschiedene Aufgabenbereiche abdecken. Es sind dies

  • Die Zentrale Konfigurationsdatei portal.yml für Portale und Infrastruktur
  • Diverse PostgreSQL-Datenbanken
  • Suchmaschinenindizes
  • Die OpenBib Perl-Library
  • Die Webanwendung
  • Eine vereinheitlichte Import-Pipeline mit Konvertierungsprogrammen für die Datenformate der verschiedenen Datenquellen
  • Hilfsprogramme

Die Komponenten

Zentrale Konfigurationsdatei

Alle zentralen Einstellungen für die gesamte Infrastruktur werden in der Datei /opt/openbib/conf/portal.yml vorgenommen.

https://github.com/oflimm/openbib/blob/master/portal/perl/conf/portal.yml-dist

Dazu gehören u.a.

  • die Verbindungsparameter zu den verschiedenen PostgreSQL-Datenbanken der Infrastruktur
  • die Parameter für die Nutzung von Memcached (welche Information soll wie lange gecacht werden)
  • Verbindungsparameter für verschiedene Authentifizierungsmethoden (LDAP)
  • Parameter zum Zugriff auf verschiedene Suchmaschinen
  • …

Diverse PostgreSQL-Datenbanken

Katalogdatenbanken

Die Definition der Tabellen und Indizes für einen Katalog in dessen PostgreSQL-Datenbank befindet sich in folgenden Dateien

https://github.com/oflimm/openbib/blob/master/db/postgresql/pool.sql https://github.com/oflimm/openbib/blob/master/db/postgresql/pool_create_index.sql

Systemdatenbank

Für ein Portal (View) wird definiert, welche Kataloge/Pools dazugehören und gleichzeitig durchsucht werden sollen. Deren separate Suchindizes werden dann für die Recherche entweder dynamisch oder statisch zusammengeschlossen.

Derartige Konfigurationen, aktive Nutzer-Session uvm. werden in einer zentralen Systemdatenbank abgelegt und können dort über eine Web-Administration erstellt, geändert oder gelöscht werden.

Diese Systemdatenbank ist definiert in

https://github.com/oflimm/openbib/blob/master/db/postgresql/system.sql https://github.com/oflimm/openbib/blob/master/db/postgresql/system_create_index.sql

und initial gefüllt mit

https://github.com/oflimm/openbib/blob/master/db/postgresql/system_defaultinit.sql

Statistikdatenbank

Neben der zentralen Systemdatenbank gibt es noch eine Statistikdatenbank

https://github.com/oflimm/openbib/blob/master/db/postgresql/statistics.sql https://github.com/oflimm/openbib/blob/master/db/postgresql/statistics_create_index.sql

in der u.a. Daten aus Nutzer-Sessions anonymisiert archiviert werden.

Anreicherungsdatenbank

Eine Anreicherungdatenbank

https://github.com/oflimm/openbib/blob/master/db/postgresql/enrichmnt.sql https://github.com/oflimm/openbib/blob/master/db/postgresql/enrichmnt_create_index.sql

in der die Infrastruktur sammelt Anreicherungs- und Analysedaten, mit denen Kataloge und deren Suchindizes angereichert werden können. Das Matching erfolgt mit ISBN, ISSN oder BibKey.

Suchmaschinenindizes

Für schnelle Recherchierbarkeit wird für jeden Katalog auch ein Suchindex in einer Suchmaschine verwendet. Aktuell werden die Suchmaschinen Xapian und Elasticsearch unterstützt, weil gerade diese sehr geeignet sind für den Betrieb einer komplexen Infrastruktur.

Aufbauend auf der generelle Definition von Suchfeldern in der zentralen Konfigurationsdatei portal.yml unter dem Eintrag searchfield erfolgt die Indexierungs-Parametisierung für die verschiedenen Suchmaschinen in folgenden Einträgen

Xapian

  • xapian_index_base_path
  • xapian_search
  • xapian_facet_value
  • xapian_sorttype_value
  • xapian_collapse_value

Elasticsearch

  • elasticsearch
  • elasticsearch_index_mappings
  • elasticsearch_filter_field
  • elasticsearch_sorttype_value

OpenBib Perl-Library

Der Kern der Infrastruktur ist die OpenBib Perl-Library, in der Klassen und Module für alle Funktionsbereiche gesammelt werden:

https://github.com/oflimm/openbib/tree/master/portal/perl/modules/OpenBib

Diese wird normalerweise aus dem ausgecheckten git-Tree /opt/git/openbib-current/portal/perl/modules/OpenBib in die Standardpfade von Perl verlinkt.

Darin enthalten sind Module,

  • die die Webanwendung bilden
  • die vereinheitlichte JSON-Metadaten in die SQL-Datenbank und verschiedene Suchmaschinen importieren
  • die über API-Objekte auf entfernte Datenquellen zugreifen

und vieles mehr.

Webanwendung

Module

Die Webanwendung basiert auf dem PSGI-Standard (ungleich CGI) sowie REST und trennt Resourcen-URLs (Basis-Pfad) von den tatsächlich zurückgelieferten Repräsentationen (HTML, JSON, XML, ICAL, …) in deren eigenen URL’s. Als Webserver kommt der zu PSGI kompatible Server starman und das Micro-Framework CGI::Application zum Einsatz. Grundsätzlich können jedoch alle PSGI-konformen Webserver verwendet werden.

Im Mittelpunkt der Webanwendung steht ein Dispatcher, um für aufgerufenen URLs die entsprechenden Module und Methoden aufzurufen.

https://github.com/oflimm/openbib/blob/master/portal/perl/modules/OpenBib/Handler/PSGI/Dispatch.pm

Das Mapping zwischen URLs und Methoden in den Modulen geschieht über die Mapping-Datei /opt/openbib/conf/dispatch_rules.yml

https://github.com/oflimm/openbib/blob/master/portal/perl/conf/dispatch_rules.yml-dist

Darin sind die einzelnen Regeln in einer Liste aufgeführt. Konkret wird dort definiert bei welchem Pfad (rule) welche Methode (runmode) in welchem Module (module) für die Bearbeitung der Anfrage ausgeführt werden soll. Ggf. sind weitere Parameter enthalten, z.B. welche Repräsentationen von der Methode zurückgeliefert werden können/sollen.

Die verwendeten Methoden sind in den Modulen von OpenBib::Handler::PSGI::* gekapselt.

https://github.com/oflimm/openbib/tree/master/portal/perl/modules/OpenBib/Handler/PSGI

Zentrale Methoden, die für alle Module in dieser Unter-Hierarchie genutzt werden, werden in

https://github.com/oflimm/openbib/blob/master/portal/perl/modules/OpenBib/Handler/PSGI.pm

gesammelt. Dort sind auch die für CGI::Application relevanten Methoden cgiapp_init und cgiapp_prerun enthalten, die beide im Ablauf der Bearbeitung eines Request immer vor den eigentlich zuständigen Methoden in den Modulen ausgeführt werden.

Templates

Für die Ausgabe der Inhalte wird das Templating-System Template Toolkit verwendet. Die Templates liegen unter /opt/openbib/templates die in den lokalen git-Tree /opt/git/openbib-current/portal/perl/templates verlinkt sind

https://github.com/oflimm/openbib/tree/master/portal/perl/templates

Die Basis-Templates können objektorientiert nach drei verschiedenen Kriterien spezialisiert werden:

  • für einen speziellen Katalog in einem Unterverzeichnis mit dem Namen des Katalog in _database
  • für ein spezielles Portal (View) in einem Unterverzeichnis mit dem Namen des Views in _view
  • für eine Klasse von Portalen (Katalogprofil) in einem Unterverzeichnis mit dem Namen des Katalogprofils in _profile. Innerhalb eines Katalogprofiles kann nochmals nach Katalogen und Portalen abstrahiert werden.

Für die Ausgabe wird das jeweils spezifischste Template verwendet. Effektiv ergibt sich daraus die Reihenfolge von spezifisch zu allgemein:

  1. …/templates/_profile/PROFILENAME/_view/VIEWNAME/_database/DBNAME/TEMPLATENAME
  2. …/templates/_profile/PROFILENAME/_database/DBNAME/TEMPLATENAME
  3. …/templates/_profile/PROFILENAME/_view/VIEWNAME/TEMPLATENAME
  4. …/templates/_profile/PROFILENAME/TEMPLATENAME
  5. …/templates/_view/VIEWNAME/_database/DBNAME/TEMLATENAME
  6. …/templates/_database/DBNAME/TEMPLATENAME
  7. …/templates/_view/VIEWNAME/TEMPLATENAME
  8. …/templates/TEMPLATENAME

Mit diesem objektorientierten Templating lassen sich ausgehend von einem Basis-Satz an Templates individuelle Änderungen davon sehr fein granuliert spezialisieren - einfach indem man das entsprechende Template in das jeweilige Untervereichnis kopiert und anpasst. Der Aufwand für den Betrieb einer Infrastruktur mit einer Vielzahl an bereitgestellten Portelen sinkt dadurch substanziell. Ebenso ist sofort ersichtlich in welchen Templates Sonderanpassungen gemacht wurden.

Sprachdateien

Texte können für verschiedene Sprachen in eigenen Message-Katalogen abgelegt werden. Genutzt wird hierfür der gettext-Standard über Maketext. Die Kataloge liegen unter /opt/openbib/locales bzw. sind verlinkt nach /opt/git/openbib-current/portal/perl/locales

https://github.com/oflimm/openbib/tree/master/portal/perl/locales

Bilder, CSS und JavaScript

Bilder, CSS und JavaScript-Dateien werden direkt aus den jeweiligen Git-Trees in das Document-Root bzw. das Standard-Bildverzeichnis der Server verlinkt:

/opt/git/openbib-current/portal/htdocs/images/openbib -> /usr/share/images/openbib

/opt/git/openbib-current/portal/htdocs/css -> /var/www/html/css

/opt/git/openbib-current/portal/htdocs/js -> /var/www/html/js

Die jeweiligen Inhalte in github sind

https://github.com/oflimm/openbib/tree/master/portal/htdocs/images/openbib

https://github.com/oflimm/openbib/tree/master/portal/htdocs/css

https://github.com/oflimm/openbib/tree/master/portal/htdocs/js

Konvertierung und Import-Pipeline

In der Infrastruktur wird für jede Normdaten-Art (Titel, Personen, Körperschaften etc.) eine eigene JSON-Datei in einem vereinheitlichten internen Metadatenformat (aktuell basierend auf dem Kategorienschema von MAB2) verwendet.

Diese Dateien werden als meta.title.gz, meta.person.gz usw. im Verzeichnis der Datenquelle DATENBANKNAME

/opt/openbib/autoconv/pools/DATENBANKNAME

gesammelt.

Diese Dateien werden mit dem Programm /opt/openbib/autoconv/bin/autoconv.pl

https://github.com/oflimm/openbib/blob/master/conv/auto/autoconv.pl

in verschiedenen Phasen abgearbeit. Diese Phasen beginnen mit dem Einsammeln der Importdaten, dem Auspacken in einem temporären Verzeichnis, der Standard-Umwandlung in SQL und einem JSON-Format für den Import in PostgreSQL und die Suchmaschinensoftware uvm.

Die Standard-Umwandlung und Indexierung wird in der Konfigurationsdatei /opt/openbib/conf/convert.yml festgelegt.

https://github.com/oflimm/openbib/blob/master/portal/perl/conf/convert.yml-dist

Neben der Standardkonfiguration im Element default können alle Teilkonfigurationen auch für einzelne Kataloge DBNAME im gleichnamigen Element DBNAME geändert werden, z.B. für den Katalog provenienzen

https://github.com/oflimm/openbib/blob/master/portal/perl/conf/convert.yml-dist#L1252

So können individuelle Besonderheiten eines jeden Katalogs berücksichtigt werden.

Um weitere Besonderheiten berücksichtigen zu können, wie z.B. die vielen verschiedenen Exportformate oder besonderen Anforderungen für nachträgliche Manipulationen der Daten, kann in diese Verarbeitungsphasen eingegriffen werden. So können vor und nach jeder diese Phasen Skripte ausgeführt werden (pre_PHASENNAME.pl, post_PHASENNAME.pl) oder eine Phase komplett durch Direktiven in einem eigenen Skript ersetzt werden (alt_PHASENNAME.pl).

Diese Skripte sind jeweils in einem Verzeichnis mit dem DATENBANKNAME unter /opt/openbib/autoconv/filter/ gesammelt.

https://github.com/oflimm/openbib/tree/master/conv/auto/filter

So lassen sich beliebige Eingriffe in die Verarbeitungs-Pipeline umsetzen.

Anwendungsfall: Andere Export-Formate der Quellsysteme

In der Regel liegen die Export-Daten aus den verschiedenen Quellsystemen nicht in diesem interene Format von OpenBib vor. Daher müssen sie zunächst dorthin umgewandelt werden. Die dazu verwendeten Programme liegen unter /opt/openbib/conv bzw. sind aus den Programmdateien jenseits des Basispfads /opt/git/openbib-current/conv/* dorthin verlinkt.

https://github.com/oflimm/openbib/tree/master/conv

Wenn nun z.B. die Quelldaten im nativen MAB2-Format vorliegen kann in einem Skript alt_remote.pl ein Kommando platziert werden, dass in der Verarbeitungs-Pipeline zunächst die MAB2-Daten in das interne JSON-Metadatenformat umwandelt, dass die Grundlage für die nächsten Verarbeitungsphasen ist:

https://github.com/oflimm/openbib/blob/master/conv/auto/filter/uzkzeitschriften/alt_remote.pl

Anwendungsfall: Setzen von zusätzlichen Standort-Markierungen in den Daten

Manchmal sollen durch Analyse eines Datensatzes zusätzliche Inhalte in die Daten eingebracht werden, z.B. einheitliche Standort-Markierungen, um eine Facettierung nach Standorten über verschiedene Kataloge/Datenbanken zu erreichen.

Hierzu müssen dann zusätzliche Skripte geschrieben werden, z.B.

https://github.com/oflimm/openbib/blob/master/conv/auto/filter/inst001/add-locationid.pl

und diese dann über das zuständige Filter-Skript, z.B. post_unpack.pl, in die Verarbeitungs-Pipeline eingehängt werden

https://github.com/oflimm/openbib/blob/master/conv/auto/filter/inst001/post_unpack.pl

Es hat sich bewährt bei solchen Bearbeitungsskripten wie add-locationid.pl jeweils von Standardeingabe zu lesen und nach Standardausgabe zu schreiben. Dadurch lassen sich durch Pipes Verknüpfungen von vielen verschiedenen Bearbeitungsskripten elegant kombinieren.

Hilfsprogramme

Hilfsprogramme werden in der Regel unter /opt/openbib/bin abgelegt

https://github.com/oflimm/openbib/tree/master/tools

Darunter fallen z.B. die Skripte zum initialen Erzeugen der System-, Statistik-, Anreicherungs- sowie Katalog-Datenbanken,

https://github.com/oflimm/openbib/blob/master/tools/createsystem.pl

https://github.com/oflimm/openbib/blob/master/tools/createstatistics.pl

https://github.com/oflimm/openbib/blob/master/tools/createenrichmnt.pl

https://github.com/oflimm/openbib/blob/master/tools/createpool.pl

aber auch solche, um Metriken des Bestandsaufbaus zu generieren

https://github.com/oflimm/openbib/blob/master/tools/gen_metrics.pl

oder offene Nutzer-Sitzungen abzuräumen

https://github.com/oflimm/openbib/blob/master/tools/session-cleanup.pl

Use Case: Setup an der Universitäts- und Stadtbibliothek Köln

Aktuell betreibt die USB Köln zwei Cluster mit jeweils 2 dedizierten Servern. Jeweils ein Cluster beantwortet Anfragen, das andere pausiert bis dort Daten aktualisiert werden. Ist die Aktualisierung fertig tauschen die Cluster die Funktion. Eine Erweiterung der Cluster um zusätzliche Server ist jederzeit möglich.

Anfragen an die Recherche-Infrastruktur erfolgen nacheinander in verschiedenen Stufen

HAProxy -> lighttpd -> starman

HAProxy verteilt die Anfragen an die für Anfragen zuständigen Server in den Clustern. Die jeweils pausierenden Server erhalten keine Anfragen. HAProxy ist dafür mit der Infrastruktur gekoppelt und holt sich dort die benötigten Informationen.

Auf den Servern landet die Anfrage dann an einem lokalen Webserver, in der USB ist das derzeit lighttpd. Seine Aufgabe ist die leichtgewichtige Auslieferung statischer Inhalte, wie Bilder, CSS, JavaScript-Dateien, ohne dafür den Applikations-Server starman unnötig zu belasten.

Anfragen an die Infrastruktur werden an dem Path-Prefix /portal erkannt und von lighttpd an den Applikations-Server starman transparent weitergeleitet. Starman ist ein performanter Applikations-Server, der das PSGI-Verfahren unterstützt und in dem die Infrastruktur effektiv läuft.