- Dr. Dietmar Haubfleisch – Die aktuellen Empfehlungen der DFG und des WR … – DBV, Sektion IV-Sitzung am 26.10.211

Von Primo zu Elasticsearch

René Sprotte

Der Katalog der UB Paderborn

Projekt-Historie

2010

• HBZ Konsortium: UB FU, TU, HU Berlin, UB Mannheim, ULB Düsseldorf, UB Paderborn (UDK Berlin und UB Trier kamen später noch hinzu)

• Primo Version 2.0 – Für uns nicht benutzbar da keine vollständige Integration mit Aleph möglich war (Benutzerkontofunktionen) => Warten auf Primo 3.0

Anfang 2011 - Sep. 2011

• Primo 3.0

• Workshop/Training in Mannheim und Düsseldorf

• Beginn der Einrichtung und Anpassung von Primo an lokale Anforderungen

• "Lessons Learned"

• => Beginn der Entwicklung einer eigenen Katalogoberfläche für Primo und die Entwicklung eines Werkzeugs für die Datennormalisierung

2

Projekt-Historie

Okt. 2011 - März 2015

• Sep. 2012 - Produktionsstart mit Primo und eigener Katalogoberfläche

• Kontinuierliche Weiterentwicklung und Pflege

• KOBV Konsortium wird Primo-Betrieb Ende 2016 einstellen

• => Alternative für Primo oder bei Primo bleiben (selbst hosten oder Ex Libris Cloud)

März 2015 - heute

• Aufbau einer Elasticsearch Instanz

• Anpassung der Katalogoberfläche und der Daten-Prozesse an Elasticsearch

• Jan. 2016 Produktionsstart mit Elasticsearch

3

4

Warum eine eigene Katalogoberfläche für Primo

entwickeln?

5

Primo 3.0 in einer Konsortialumgebung!

Negativ

• Die Hauptgründe waren zunächst primär die aus unserer Sicht unzureichenden Möglichkeiten Primo anpassen und erweitern zu können sowie fehlende Funktionen

• Man aber kann nur „Kosmetik“ betreiben – Funktionsanpassungen sind nur sehr eingeschränkt möglich (CSS und JS Hacks)

• Eine Versionskontrolle dieser Anpassungen ist kaum möglich

• Unvollständige OPAC Funktionen

• Primo hat kein Responsive UI für Smartphone und Tablets. Potentiell doppelte Arbeit für Anpassungen der "mobilen Seite"

• Viele Funktionen wie Primo sie vorsieht wollten wir so nicht haben, z.B. PDS, Bestandsanzeige, Tabs in der Detailansicht, Magazin-Bestellung, Fernleihe

• Erhebliche Sorge, mit jedem Update große Teile der "gehackten" Anpassungen nacharbeiten zu müssen

• Eingeschränkte Möglichkeiten für Monitoring und Nutzungsstatistiken

6

Positiv

• Sowohl Primo als auch Aleph bieten die Möglichkeit über einfache APIs alle relevanten Funktionen zu Implementieren

• Stellen und Know-How für die Entwicklung und dauerhafte Pflege einer Eigenentwicklung vorhanden

• Eine Eigenentwicklung ermöglicht uns schnell auf Nutzeranforderungen reagieren zu können

• Zudem haben wir volle Kontrolle über alle für die Nutzer relevanten Darstellungen, Bezeichnungen und Funktionen und können diese ohne Kompromisse umsetzen

• Ein funktionierender Prototyp (Suche, Facetten, Benutzerkonto) war innerhalb weniger Wochen erstellt. Dies gab uns die Zuversicht mittels der APIs ein voll funktionsfähiges Frontend entwickeln zu können

• => und dies haben wir dann gemacht ;-)

7

Architektur

8

9

Warum ein Werkzeug für die Datennormalisierung entwickeln?

Datennormalisierung

• Um Titel in einem Discovery System suchen zu können müssen die Quelldaten (z.B. MAB Daten aus Aleph) in ein Format gebracht werden, welches die Suchmaschine verstehen kann

• Diesen Schritt nennt man Transformation oder Normalisierung

• Das Schema ist entweder fest vorgegeben (Primo) oder kann selbst definiert werden wenn man z.B. mit Elasticsearch oder Solr arbeitet

• Die Transformationsregeln können je nach MAB Feld recht kompliziert werden

• Der Browser-basierte Regel-Editor von Primo ist dafür aus unserer Sicht nicht geeignet

• => Wir haben dafür metacrunch entwickelt

10

11

12

WTF?

metacrunch

• „data processing toolkit for Ruby"

• Einfaches ETL Framework - Extract, Transform, Load (http://de.wikipedia.org/wiki/ETL-Prozess)

• Vergleichbar mit Catmandu (http://librecat.org/Catmandu/) aber in Ruby anstatt Perl

• Erweiterbarer Werkzeugkasten um große Mengen an Daten zu bearbeiten

• Feedback und Nachnutzung erwünscht

• Github: https://github.com/ubpb/metacrunch

Beispiel-Workflow

• Extract: Lese Aleph MAB-XML tar.gz Dateien aus dem Dateisystem

• Transform: Transformiere die Daten in ein normalisiertes Zwischenformat

• Load: Schicke die normalisierten Daten an Elasticsearch / Primo

13

metacrunch Beispiel

14

$ metacrunch mab2-demo.metacrunch @@ /tmp/aleph.PRIMO.20160726.115330.31.tar.gz

15

Elasticsearch

Elasticsearch

• Ende 2014 / Anfang 2015 zeichnete sich ab, dass der KOBV den Primo Betrieb nicht dauerhaft weiterführen wird, da die Berliner Bibliotheken auf ALMA umsteigen werden und damit auch ihre Primo Instanzen in die Ex Libris Cloud umziehen werden

• Ein Umzug in die Ex Libris Cloud hätte unserer Kosten für Primo deutlich gesteigert ohne einen direkten Mehrwert

• Da wir Frontend und Werkzeuge für die Datennormalisierung ja bereits hatten, hätten wir durch einen Umstieg auf eine mögliche "Full-Stack Alternative" wie VUFind auch keinen Vorteil gezogen

• Nach kurzer Evaluation von Solr und Elasticsearch haben wir uns entschieden den verbleibenden Teil, den wir von Primo nutzen, durch Elasticsearch zu ersetzen

16

Primo => Elasticsearch

• Unser Frontend nutzt intern ein modulares Adapter-Konzept

• Es gibt ein Adapter für die Funktionen zur Suchmaschine (z.B. search, get_record, etc.) und einen Adapter für die Funktionen zum Bibliothekssystem (z.B. authenticate_user, get_user_info, get_user_loans, etc.)

• Um Primo durch Elasticsearch abzulösen mussten wir nur einen neuen "ElasticSearch"-Adapter schreiben, der gegen den "Primo"-Adapter "ausgetauscht" wurde

• Änderungen am Frontend waren dadurch nicht erforderlich**

• Das gleiche Konzept werden wir verwenden, sollten wir später von Aleph zu Alma umsteigen

17

** wir haben in der Zeit das Frontend zusätzlich auch funktional überarbeitet

Architektur

18

http://katalog.ub.uni-paderborn.de

Vorteile von Elasticsearch gegenüber (KOBV) Primo

• Reduzierung der Betriebskosten: Keine Primo Wartungsentgelte mehr, keine Hostingkosten mehr

• Antwortzeiten für Suchanfragen wesentlich schneller (~100ms vs. ~400ms) trotz kleinerer Hardware

• Betrieb ist in der Praxis wesentlich stabiler als im KOBV Hosting

• Elasticsearch wird schnell und kontinuierlich weiterentwickelt und setzt intern das neuste Lucene ein (Primo verwendet ein viele Jahre altes Lucene**)

• "Full-Load" (1.6 M Titel) ~2.5 Stunden vs. 6 Stunden bei Primo (+ Index Hot Swapping)

• "Updates" alle 30 Minuten vs. ein Mal in 24 Stunden

• Große und aktive Community und kommerzieller Support verfügbar

• Wesentlich größerer Funktionsumfang bzgl. der Möglichkeiten von Ranking, Boosting, Aggregations (Facetten), Tokenizing etc.

19

** Stand KOBV Installation Ende 2015

Aufwände

• An dem Projekt arbeiten zwei Personen (eine Person 100%, die zweite ~50%)

• Temporär unterstützt durch Personen aus den Bereichen Katalogisierung (Mono und Zeitschriften) und Benutzung (Beratend ohne relevante Aufwände)

• Der Hauptteil der Aufwände fließt in neue Funktionen und die Datennormalisierung und nicht primär in das "Basis-System"

• Unabhängig bzgl. "Make or Buy", da es sich meistens um lokal spezifische Funktionen handelt die i.d.R. in Standardsoftware ebenfalls nachgerüstet bzw. integriert werden müssten

• In diesen Fällen spielt die Eigenentwicklung ihren Vorteil aus, da man keinen Beschränkungen unterliegt

• Beispiele: Kalenderintegration für Rückgabefristen, Darstellung von Zeitschriftenbeständen, "Zeige nur verknüpfte Titel an, zu denen auch Bestand existiert", "Zeige den Link zur Überordnung nur dann an, wenn Bestand existiert", spezielle Magazinbestellung, Regalfinder, etc.

• Die Aufwände für Betrieb und Administration von Elasticsearch sind zu vernachlässigen. Super einfaches Setup selbst für Cluster (wir betreiben einen Cluster mit drei Knoten)

20

Fazit

• Make or Buy? It depends!

• Für uns funktioniert "Make" sehr gut

• Permanente Stelle(n) mit entsprechendem Know How für Entwicklung und Pflege

• Wahl der "richtigen" Werkzeuge

• Flexibilität vs. "Out of the box": Was ist uns wichtig?

• Würden wir heute bei null Anfangen: Ich würde einen Blick auf VUFind werfen, würde aber trotzdem genau schauen inwieweit meine Anforderungen umgesetzt sind bzw. in welchem Umfang Änderungen erforderlich sind, wie sie technisch realisiert werden können und wie sie dauerhaft wartbar bleiben

• Open Source: https://github.com/ubpb/

21

22

Vielen Dank!

Fragen?