Datenbanken und Repositorien Teil 1: JCR-Repositorien und NoSQL-Datenbanken

Daniel Burckhardt: Content Repositories und Relationale Datenbanken für das Historische Forschungnetz.

Teil 1: JCR-Repositorien und NoSQL-Datenbanken.

Die langfristig wichtigste Entscheidung für den Aufbau eines Redaktionssystems, wie auch sonst bei jeder datenbankbasierten Software, ist die Frage nach der Datenhaltung. Im Projekt Historisches Forschungsnetz wurden verschiedene Möglichkeiten der Datenhaltung in relationalen Datenbank und sogenannten Content Repositories evaluiert. Grundsätzlich kommen beide Datenspeicher in Kombinationen mit einem Dateisystem für das Ablegen von Binärdaten (Bild, Ton, Film) in Frage. Aber auch dokumentorientierte NoSQL-Datenbanken können in Betracht gezogen werden.[1]

Die bisherigen Lösungen für die Fachinformationsdienste Clio-online und H-Soz-u-Kult basieren auf relationalen Datenbanken. Diese haben bis heute eine sehr breite Verbreitung gefunden, auch auf einfachen shared Web-Host Accounts kommerzieller Hostingprovider; zudem existieren zahlreiche Konnektoren zwischen Datenbanken und Programmiersprachen. Hauptnachteil ist die ad-hoc Modellierung von Dateisystemstruktur sowie Funktionen zur Versionierung der Datenbankinhalte, für die sich keine allgemeinen Konventionen etablieren konnten. Damit wird jede Implementation in einem gewissen Sinn zu einer Insellösung.[2]

Relationale Datenbankmanagementsysteme

Hier stehen die bekannten proprietären (Microsoft SQL, Oracle) bzw. Open Source Datenbanken (MySQL, Postgresql) im Vordergrund. Alle diese Systeme haben sich über die letzten beiden Jahrzehnte in vielen Anwendungsbereichen mit großen Datenbeständen und einer hohen Zahl paralleler Anfragen bewährt. Alle Produkte unterstützen sowohl Replikation als auch Hot-Backups und bieten Treiber für alle gängigen Programmiersprachen, so dass die Entscheidung primär gemäß den Lizenzbedingungen sowie individuellen Präferenzen und weniger aufgrund der spezifischen Eignung für die konkreten Projektanforderungen gefällt werden kann. Hauptnachteil von SQL-Datenbanken sind die Funktionen zur Modellierung und Versionierung der Datenbankinhalte, für die sich bislang keine allgemeinen Konventionen etablieren konnten.[3] Damit wird jede konkrete Implementation unabhängig von der Wahl des konkreten RDMS in einem gewissen Sinn zu einer Insellösung.

Content Repository

Die Definition eines Content Repository ist unschärfer.[4] Zusätzlich zur Speicherung und Abfrage von strukturierten und unstrukturierten Dokumenten bieten viele Content Repositories ein Zugriffsmanagement (Access Control) sowie zur Versionierung der Inhalte; Funktionen, die beim Einsatz eines RDMS typischerweise im Data Access Layer erfolgen.

Bei den Content Repository haben neben der einzig in Python-Umgebungen verbreiteten Zope Object Database[5] vor allem Java-Lösungen Verbreitung gefunden. Einerseits gibt es eine Reihe von Systemen, die die Content Repository API for Java (JCR) umsetzen.[6] Der Anwendungsbereich wird in der Einleitung zum JSR-283[7] folgendermaßen beschrieben:

The JCR specification defines an abstract model and a Java API for data storage and related services commonly used by content-oriented applications. The target domain encompasses not only traditional content management systems but, more broadly, any application that must handle both unstructured digital assets and structured or semi-structured information.

The repository model enables efficient access to both large binary objects and finely-structured hierarchical data through a simple, generic API and a robust and extensible object typing system. Additionally, many features that are traditionally custom-built on top of RDBMSs and file systems have been incorporated into the repository itself. These include support for query, access control, versioning, locking and observation. Standardized support for these services further enables applications that might not normally have access to such advanced features to take advantage of them, since they are built-in at the infrastructure level.

In den letzten beiden Jahren sind eine Reihe von System dazugekommen, die entweder in Ergänzung zu JCR oder als primäre Schnittstelle als CMIS-Server fungieren.[8] Aufgrund der quelloffenen Community Edition stand für uns das Alfresco 4.x CMIS Content Repository im Vordergrund; kommerzielle Implementierungen umfassen u.a. Microsoft Sharepoint sowie EMC Opentext. Neben den JCR bzw. CMIS-basierten Systemen hat im akademischen Bereich Fedora Commons in verschiedenen e-Library und e-Science Projekten wie Ambra[9] und eSciDoc[10] Verbreitung gefunden.

Im Projekt Historisches Forschungnetz wurde ein Teil der genannten Datenbanken und Repositorien hinsichtlich verschiedener Eigenschaften evaluiert und getestet. Zu Beginn der Evaluation sprachen eine Reihe von Argumenten für den Zugriff über die JCR-Schnittstelle gegenüber einer direkten Anbindung von Fedora Commons, da parallel zu den JCR-Repositories Jackrabbit und ModeShape getestet wurde:

• Standardisierte Schnittstelle: JCR ist durch zwei im Rahmen des Java Community Prozess entstandene Spezifikationen festgelegt.[11] Fedora Repository bietet Web-Service Schnittstellen, die sich aber zwischen den verschiedenen Versionen ändern können.[12]
• Mehrere frei verfügbare und kommerzielle Implementationen.[13] Dadurch schien die dauerhafte Pflege und Weiterentwicklung von JCR Repository besser abgesichert, als bei Fedora Commons, dessen Weiterentwicklung im Rahmen der Duraspace Foundation primär von Projektförderungen abhängig ist und sich auf eine relativ kleine Kerngruppe von Programmierern stützt.[14]
• Über das im Rahmen des Apache Chemistry Projektes entwickelte OpenCMIS JCR Repository[15] sollte demnächst jedes JCR-kompatible-Repository den CMIS-Standard unterstützen.[16]

Bei der ersten Umsetzung einer Migration der Clio-online Suchmaschine Historische Rezensionen Online mit mehr als 87.000 Rezensionen zu knapp 70.000 Publikationen zeigte sich, dass weder Jackrabbit (in der Version 2.3.x) noch ModeShape (in der Version 2.6.x) mit einer großen Zahl flach strukturierter Knoten umgehen können. Ab ungefähr 1000 Knoten auf einer Hierarchie-Stufe werden die schreibenden Zugriffe sehr langsam. Diese Beschränkungen beim Einfügen lassen sich durch eine „Pseudo-Hierarchie“ (z.B. Gruppierung von Publikationen gemäß ihres ISBN-Prefixes oder einem Hash-Key) zwar teilweise umgehen.[17] Aber auch dann haben einfache Abfragen wie „Gib mir die Zahl der gespeicherten Publikationen“ mit Antwortzeiten im Minutenbereich bei über 50.000 Publikationen die Systemwahl grundsätzlich in Frage gestellt. Bei der Suche nach passenden Lösungen für diese Probleme zeigte sich, dass auch andere Projekte daran letztendlich gescheitert sind.[18] So wurde für das Content Management System Nuxeo unter anderem der Wechsel von einem Content Repository zurück zu einer relationalen Datenbank vorgenommen.[19]

Dass die schlechte Performance bei flachen Strukturen keine inhärente Beschränkung des JCR-Standards, sondern der konkreten Implementierungen ist, will die nächste Version von ModeShape zeigen.[20] Diese liegt zur Zeit aber erst als alpha-Version vor, so dass das Risiko, ob die stabile Release mit diesen Änderungen rechtzeitig erscheint und sowohl bei Speicheropration als auch Abfragen schnell genug für unsere Anforderung ist, sehr hoch ist.

Dokumentorientierte NoSQL-Datenbanken

Eine Zwischenstufe zwischen RDMS und Content Repository bieten Dokument-orientierte Datenbanken  wie MongoDB oder CouchDB. Diese unterstützen teilweise ähnliche Funktionen wie die beiden erwähnten Content-Repositories:

Quelle: http://contentcurmudgeon.wordpress.com/2010/07/12/nosql-and-cms-comparing-nosql-with-cps-requirements/

Einem System wie MongoDB fehlt in der aktuellen Version eingebaute Versionierung und hierarchische Zugriffsrechte. Es bietet aber eine Schema-freie Datenhaltung, d.h. zusätzliche Felder können zu einem Dokumenttyp hinzugefügt werden, ohne dass das Datenbankschema angepasst werden muss bzw. alle Zusatz-Attribute über eine Relation in eine separate Tabelle ausgelagert werden müssen, was zu komplizierten, entsprechend fehlerträchtigen und unter Umständen Performance-kritischen Abfragen führt. Da einzelne Felder nicht wie in einem RDMS skalar sein müssen, sondern wiederum hierarchische Inhalte haben können, kann auch die Versionierung über das Hinzufügen aller früherer Versionen zum aktuellen Datensatz relativ einfach abgebildet werden.[21]

Ob eine NoSQL-Datenbank wie MongoDB überhaupt für die dauerhafte Datenhaltung oder bloß als schneller Cache für die temporäre Datenhaltung geeignet ist, war bis zu den jüngsten Versionen auf Grund der offen eingeräumten Möglichkeit von Datenverlusten bei nicht-replizierten Installationen stark umstritten.[22] Zusammenfassend scheint der Einsatz eines Systems wie MongoDB als Datenspeicher für das historische Forschungsnetz zwar technisch möglich, aufgrund der relativ jungen Architektur aber recht riskant.