Ideen Goobi Storage API
- 1. Ideen Goobi Storage API GOOBI – Steuerungsgremium, 23.9.2011, Berlin Christian Mahnke, SUB Göttingen
- 2. Bestehende Probleme bzw. Vorgaben • Probleme mir der Anzahl der Unterordner (FS Problem - Dresden) • Storage Anforderungen skalieren schlecht (SAN Kosten - Göttingen) • Archivsystem (LZA - Alle)
- 3. High Level Anforderungen • Trennung zwischen Speicherbereichen (z.B. Produktions- und Archivbereich) – Regelbasierte Zuordnung (z.B Zeit, Präfixe für Master etc.) • Tiefere Hierarchien (z.B. um FS Limitierungen zu umgehen) • Import- / Exportfunktionalität – Bereitstellung im Präsentationssystem – Bereitstellung auf FTP Server eines Kunden • Kein zusätzlicher (oder geringer) Aufwand für Systemadministratoren gewünscht • Integritätsprüfungen und Ausfallsicherheit, sowie Nachvollziehbarkeit notwendig • Projektspezifische Konfigurationen (z.B. für zeitkritische Aufträge) • Implementierungen von Anforderungen sollten kombinierbar sein • Externe Zugriffsverfahren (z.B. via Samba) sollten berücksichtigt werden – Externe Applikationen (über CLI, z.B. Jhove(2)) sollen genutzt werden können.
- 4. Schichten Samba / Statistik/ Metadaten Im- / Anwendungsebene Dateifrei Dokume Suche - editor Export - gabe ntation Storage API Storage Verwaltung Integritäts- Regeln Metadaten Pair Tree prüfung Storage JCR Akubra Merritt Dateisystem
- 5. Anforderungen Anwendungsebene • Transparenter Umgang mit Objekten • Nutzung von URIs für interne Referenzierung • Nutzung von Datenströmen (wo möglich) • Bereitstellung als temporäre Datei für Legacy Code und externe Anwendungen (z.B. Samba) – Berücksichtigung von Berechtigungen • Synchrone vs. asynchrone Bereitstellung für Nutzer
- 6. Anforderungen Storage Verwaltung • Unterschiedliche Strategien (kombinierbar und projektspezifisch) – CDL Pair Tree – Caches bei Ausfall des unterliegenden Storages (schreiben) – Generierung von Prozessmetadaten • Versionierung für Metadaten • Checksummen, ggf. inklusive Integritätsprüfung, Transaktionssicherheit • Unterschiedliche Aktivierungen – Manuelle Zuordnung (z.B. Export) – Schrittgesteuert (z.B. Archivierung) – Erkennung von ungenutzten Daten basierend auf Regeln (wie HSM)
- 7. Anforderungen Storage • Unterschiedliche Abstraktionsebenen (Beispiele) – Dateisystem • Dateien und Verzeichnisse – „Objektspeicher“ – z.B. TextGrid • Objekte und Kollektionen (Beinhalten jeweils auch komplexe Metadaten) • Unterschiedliche Semantiken (Beispiele) – Z.B. Update einer Datei vs. Update eines Objekts (s.o) – Implizite Versionierung (z.B. kein Löschen möglich) – Sichtbarkeit vs. Publizierung
- 8. Bestehende Vorarbeiten • Anforderungsdefinition • Teilweise prototypische Implementierung im Rahmen des MassenDigiMathe Projektes für Abbyy Server Kommunikation (siehe Präsentation OCR)
- 9. Vielen Dank! Fragen? mahnke@sub.uni-goettingen.de 9
Hinweis der Redaktion
- #2: Diese Folien spiegeln Überlegungen aus dem Zeitraum 10/2009 bis 3/2010 wieder, sie werden inzwischen nicht mehr aktiv verfolgt. Es sind allerdings nachnutzbare Anforderungsdefinitionen vorhanden.
- #4: Links: JHove http://hul.harvard.edu/jhove/
- #5: Links: Pair Tree: https://confluence.ucop.edu/display/Curation/PairTree JCR: http://www.jcp.org/en/jsr/detail?id=170 Akubra: https://wiki.duraspace.org/display/AKUBRA/Akubra+Project Merritt
- #6: Berechtigungen und Eigentümerschaft sind in diesem Modell nur spezielle Metadaten eines Dateisystems Asynchrone Dateioperation werden benötigt, um die Applikation beim Umgang mit großen Datenemengen nicht zu blockieren