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.


[1] Vgl. http://de.wikipedia.org/w/index.php?title=Dokumentenorientierte_Datenbank&oldid=100304113

[2] Einen umfassenden Vergleich der beiden Herangehensweisen bietet die Studie von Bertil Chapuis, JCR or RDMS, why, when, how?, http://dev.day.com/content/ddc/blog/2009/01/jcrrdbmsreport/_jcr_content/images/jcrrdbmsreport/jcr_rdbms_report_chapuis.pdf

[3] Object-relational Mapper (ORM) wie Hybernate (Java) oder Doctrine (PHP) unterstützen eine Daten-Versionierung auf der Ebene des Data Access Layers.

[4] Vgl. etwa den entsprechenden Wikipedia-Artikel: „A content repository is a store of digital content with an associated set of data management, search and access methods allowing application-independent access to the content, rather like a digital library, but with the ability to store and modify content in addition to searching and retrieving.” http://en.wikipedia.org/w/index.php?title=Content_repository&oldid=444422508

[5] http://en.wikipedia.org/wiki/Zope_Object_Database

[7] http://www.day.com/specs/jcr/2.0/2_Introduction.html

[8] http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services

[9] Ambra publishing system ist die technische Plattform der PLoS-Zeitschriften bildet: „Ambra is written in Java. It uses Spring, Struts, and the FreeMarker templating system to construct HTML which is served by Tomcat. It uses the Dojo JavaScript toolkit to create an advanced user interface. The Fedora Digital Repository is used to store digital objects. … All content is parsed and metadata is stored as triples in the Mulgara semantic repository. “ http://www.ambraproject.org/

[10] https://www.escidoc.org/

[11] JSR-170 (http://www.day.com/specs/jcr/1.0/) und JSR-283 (http://jcp.org/en/jsr/detail?id=283)

[12] https://wiki.duraspace.org/display/FCR30/Web+Service+Interfaces

[13] Im Vordergrund stehen die drei freien Implementationen Apache Jackrabbit (http://jackrabbit.apache.org/ ), JBoss ModeShape (http://www.jboss.org/modeshape) und eXo JCR (http://wiki.exoplatform.com/xwiki/bin/view/JCR/eXo%20JCR%20Implementation, download über http://forge.ow2.org/project/showfiles.php?group_id=151) und evtl. auch von Alfresco http://wiki.alfresco.com/wiki/Introducing_the_Alfresco_Java_Content_Repository_API.

[14] „Fedora 3.4 was released in June 2010. The community-based development team is international, currently consists of 12 open source committers, and many contributors. „ http://www.duraspace.org/fedora/repository/duraspace:74/OBJ/Fall_2010_Quarterly_Report.pdf

[15] http://chemistry.apache.org/java/developing/repositories/dev-repositories-jcr.html

[16] Die Implementierung eines Beispiel-Servers zeigt http://www.heise.de/developer/artikel/CMIS-mit-Apache-Chemistry-ein-Praxisbeispiel-1212217.html?view=print

[17] “A more sophisticated approach would be to hash user IDs and chunk the hash to form an ad-hoc hierarchy. For example, „Joe Smith“ might give a hash of ab12cd34. The user data for Joe Smith can be stored at users/ab/12/cd/34. When the time comes to look up data for Joe Smith, you would first hash the name (to obtain ab12cd34), then create the necessary path from the hash, and look up the data. As it turns out, the Jackrabbit API (which of course is built into CRX) offers yet another alternative for efficient hierarchical storage of arbitrary data, in the form of the BTreeManager. This class provides B+ tree-like behavior in allocating subtrees of nodes that are always balanced, with a fixed limit on how many siblings any given node can have. (You provide the limit as an argument in the constructor.)” http://dev.day.com/content/ddc/blog/2011/05/efficient_management.html

[18] So hat Sakai 3 von Jackrabbit zu SparseMap gewechselt: „Hierarchy is fundamental to the Java Content Repository specification, fundamental to Jackrabbits implementation and to some extents a natural part of the http specification. Attempting to layer a pooled content system over a fundamentally hierarchical storage system is probably a recipe for disaster on two levels. Technically it can be done, we have done it, but as my gut tells me we are beginning to find out, it wasn’t a good idea. All those efficiencies that were core to the content repository model are gone, exposing some potentially quite expensive consequences.” http://blog.tfd.co.uk/2010/10/17/wrong-content-model/

[19] Why Nuxeo Dropped JCR: „Performance. There were also unresolved performance problems with nodes containing a huge number of children, inherent in Jackrabbit’s way of storing children information. I haven’t kept up with the latest Jackrabbit releases but at the time this was killing us, and there was no simple fix available.„ http://blogs.nuxeo.com/fguillaume/2011/01/why-nuxeo-dropped-jcr.html

[20] Next Generation ModeShape: “We want ModeShape to support flatter hierarchies as good and fast as deeper ones.[…] We want ModeShape to scale to massively large repositories and even very large clusters. […] Recently I completed enough of it that I could run some performance comparisons using the JCR API. I was floored by the results, even after spending no time optimizing the system:
Time to create 10K child nodes, perform a save, and persist to disk: 0.8 seconds.
Time to create a subgraph with 1.01M nodes, periodically saving, and persisting to disk: 3.5 seconds
Time to get a node by path from a workspace with 1M nodes: 0.00058 seconds
Running the same operations in ModeShape 2.x takes significantly longer (in some cases multiple orders of magnitude!), so I think this new design shows tremendous promise.” http://community.jboss.org/message/634352#634352

[21] http://stackoverflow.com/questions/4185105/ways-to-implement-data-versioning-in-mongodb

[22] http://blog.mongodb.org/post/381927266/what-about-durability?4a056380

Dieser Beitrag wurde unter Uncategorized veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.