bannkreis.de

Für eine Handvoll XML mehr (Pt. 2)

Warum sind XML-Datenbanken in ihrer Entwicklung und ihrer Akzeptanz stecken geblieben? Ich denke, es hat damit zu tun dass sie es einem Experten für relationale DBMS schwer machen, sie zu mögen. Ihm müssen sie wie ein ungeordneter Haufen von, in sich selbst bereits desintegrierten, Daten vorkommen, die nicht in der Lage sind selbst für ihre Integrität zu sorgen. Von einem relationalen Datenbanksystem erwartet man starre Formen und Regeln, die Fähigkeit einer Datenbank selbst über ihre Relationen zu wachen und alle Verstöße dagegen zu bestrafen. Und, ach ja, ohne Transaktionen geht schonmal garnichts.


Zudem, dass habe ich im vorherigen Artikel über XML-Datenbanken bereits erwähnt, verfügen RDBMS-Experten über eine weitgehende Immunität gegenüber der Nachteile relationaler Systeme und den daraus notwendigerweise erwachsenden Komplexitäten. Aus ihrer Perspektive gibt es keinen Grund an der Omnipotenz relationaler Systeme zu zweifeln. Die Tatsache, dass die objekt-relationale Brücke zwischen Anwendungen und Datenbanken, bzw. die Problematiken hinter diesem "Medienbruch", heutzutage zur grossen Gretchenfrage über Wohl und Wehe neuer Systeme wird entzieht sich in der Regel ihrer Wahrnehmung.


Schauen sie sich die Masse an Lösungsversuchen an, welche die Uneinigkeit über die Herangehensweise an das Problem dokumentieren, die endlosen Diskussionen auf www.theserverside.com. Die Überbrückung des Paradigmen-Unterschiedes zwischen Programmierung und Datenbank ist der Zankapfel und die Archillesferse der heutigen Software-Entwicklung, gespickt mit Performance-Fallen und architektonischen "Konzessionen".

Man sollte meinen, dass native XML-Datenbanken ein leichtes Spiel haben. Sie bieten viel "natürlichere" Möglichkeiten, strukturreiche Objektdaten so zu speichern, dass diese auch flexibel abfragbar sind. Aber irgendwas ist grundsätzlich schief gelaufen.


Vielleicht fehlt es an einem großen Hersteller, der sich nicht nur mit einem Produkt, sondern auch mit einem Konzept zum Zusammenspiel von Anwendung und XML-Datenbank, idealerweise direkt mit einem "Ready-to-use"-Framework in die Wagschale wirft. Vielleicht fehlt es aber auch nach wie vor an einigen Kernkonzepten, ohne welche ein seriöser Einsatz von XML-Datenbanken nicht möglich ist, wie Transaktionssteuerung, Überwachung von Relationen, etc. Dazu müsste man sich die aktuell Verfügbaren Lösungen einmal näher ansehen.

Wie gut, dass dies der eigentliche Inhalt dieses Artikels sein sollte :-)

Und zwar will ich darstellen, welche nativen XML-Datenbanken meiner Meinung nach eine Rolle auf dem Markt spielen, der zugegeben recht klein, aber vielleicht doch nicht sooo klein wie öffentlich wahrgenommen ist. Das ganze ist herzerfrischend subjektiv zu bewerten und dürfte für manche Ansprüche technisch zu oberflächlich sein. Ich gebe lediglich meine Eindrücke wieder. Wer darüber hinaus einen wirklich exhaustiven (gibt's das Wort in Deutsch?) Überblick wünscht, dem kann ich dieses Webseite wärmstens empfehlen. Sozusagen als Appetizer zunächst einmal mein Rundflug:

Tamino (Software-AG)

Wenn jemand sich als Platzhirsch auf dem Markt nativer XML-Datenbanken dann die Software-AG mit ihrem Tamino-Produkt. Sie waren die ersten welche mit einer derartigen Datenbank an die große Masse traten und haben damit wertvolle Grundarbeit geleistet. Ich denke auf ihr Konto gehen auch die meisten existierenden Installationen (wobei mir für eine wirklich seriöse Einschätzung die Daten fehlen). Allein, vom Produkt selbst war ich nicht allzu begeistert. Seinerzeit, als wir Tamino in Augenschein nahmen konnten wir uns unter XML-Datenbanken nichts genaueres vorstellen. Insbesondere was die Architektur der Datenspeicherung angeht waren wir gespannt, wie ein echtes Produkt an die Materie herangeht. Ich schätze, wir erwarteten etwas adäquates zum relationalen Modell, eine feste Struktur in welcher die XML-Daten organisiert waren.

All das bot Tamino nicht. Im Gegenteil wirkte es eher wie ein recht naiver Ansatz nach dem Motto ?jetzt machen wir mal eine XML-Datenbank?. Die Dokumente waren schlicht in Ordnern und Unterordern organisiert. Den Ordnern konnte man DOCTYPEs zuweisen, die natürlich eine gewisse Datenintegrität gewährleisteten. Indizes konnte man quasi ?über die Datenbank? werfen und sie dann durchsuchen. Xquery als Abfrage-Sprache wird, zumindest inzwischen, auch unterstützt. Man kann nicht sagen, dass Tamino unseren Anforderungen nicht genügt hätte, das Konzept kam uns damals nur zu unkoordiniert vor, sah ?zu wenig nach Datenbank? aus.

Besonders krude: Zu dem Zeitpunkt als wir Tamino evaluierten war das einzige programmatische Interface zum Server HTTP-basiert. Auf unsere Frage, ob das nicht reichlich ineffektiv sei, hiess es natürlich nein, Performance ist gut und ausserdem wäre HTTP ja sowieso das native Protokoll um XML zu transportieren. Hm, native XML-Protokolle, gibt's die? War das nicht ein unerlaubter Rückschluss aus der syntaktischen Verwandtschaft zwischen XML und HTML? Und ausserdem, was war mit all den Sachen die HTTP von sich aus nicht kann, die aber in der Datenbank-Kommunikation durchaus erwünscht sind, z.B. Entprellen der Requests, halten von Stati etc. (und kommt mir nicht mit Cookies...)? Auf unsere Nachfragen gestand man dann doch, das eine "direktere" Datenbank-API in Arbeit war, die wohl inzwischen vollendet sein dürfte. Nach dem Motto: Nein, HTTP ist gut genug, aber wir machen jetzt trotzdem noch was anderes, besseres.

Vielleicht aber erwarteten wir auch zu viel. Im Grunde fiel unser Unbehagen auf die oben genannten Gründe zurück, die XML-Datenbanken krude erscheinen lassen wenn man relationale Systeme gewohnt ist. Vielleicht, wenn sie ihre Ordner Tabellen genannt hätten, uns ein E/R-Diagramm mit enforcierten Relationen gezeigt hätten, wer weiss. Vielleicht wären wir begeistert gewesen.

X-Hive

Die nächste Plattform mit der ich mich beschäftigte. X-Hive basiert auf Objektivity, der berühmten objektorientierten Datenbank die zumindest laut Pressematerial die wahrscheinlich größte Datenbank der Welt betreiben darf (das "Babar" System im Stanford Linear Acceleration Center, Palo Alto: 2000 CPUs, 100 Server, 800 Terabyte Kapazität, 1 Terabyte Durchsatz pro Tag).

Die erste (positive) Überraschung bezüglich X-Hive ist sein API-zentrischer Aufbau. Es gibt eine sehr umfangreiche Java-API mit der man eigentlich alles direkt ansteuern kann wozu das Datenbanksystem in der Lage ist. Wir hatten kurzzeitig einen Konsultant im Haus der uns in das System einführen sollte. Aber auf jede Frage die wir ihm stellen konnten musste er in derselben Form antworten:

Ja, dann ruft man halt diese Methode auf, gibt diese Parameter mit....und ist fertig.


...und es  war ihm offensichtlich peinlich, wie überflüssig seine Erklärungen waren.  In einem Satz:  Das System war sehr straight-forward bedienbar. Natürlich gab es eine Administrationskonsole, der Datenbank-Server ist in andere Softwares einbettbar (was für uns eine Grundvoraussetzung war). Als Abfragesprachen wurden XQuery und XPath-Abfragen unterstützt. Zusätzlich konnten Indizes über die Datenbanken geworfen werden, um Abfragen anhand der indizierten Werte zu beschleunigen. Machte alles in allem einen sehr guten Eindruck.  Daher erachte ich X-Hive für das  aktuell beste kommerzielle XML-Datenbanksystem.


Xindice

Dies ist eine Open-Source-Datenbank aus dem allseits bekannten Haus Apache, das uns mit so grossartiger und krude zu konfigurierender Software wie dem Apache HTTP Server versorgt. Für wie so viele ist auch für mich die Website dieses Projektes die erste Anlaufstelle wenn "freie" Software gesucht wird, und so stößt man halt zunächst auf Xindice. Merkwürdigerweise findet man Xindice nicht im DB-Subprojekt der Apache Foundation, sondern im XML-Subprojekt. Ok, war auch ne haarige Entscheidung...

Xindice ist komplett in Java implementiert und bietet Java-Programmen zugriff über die XML:DB-Api. XML:DB ist eine aus heutiger Sicht kurzlebige Initiative, um eine einheitliche Java-API für XML-Datenbanken zu forcieren, ähnlich wie es JDBC für relationale Datenbanken ist. Die API bot ein paar interessante Ansätze, wie z.B. eine Schnittstelle über welche optionale Services die nicht von allen Datenbanken geboten werden ermittelt werden können. Dennoch ist das Projekt heute als tot zu betrachten. Die Website wurde seit 2003 nicht mehr aktualisiert, und die dahinter betriebene "Referenz-Implementierung" dbXML ist offiziell gecancelt.

Die FAQs von Xindice warnen uns so ziemlich als erstes davor, Dokumente in der schier obzönen Größe von 5 Megabyte in die Datenbank zu stecken. Xindice sei dafür entwickelt worden, Kollektionen von kleinen bis mittelgroßen Dokumenten zu beinhalten. Umm.....ich weiss nicht wie ihr es seht. Wahrscheinlich wird man im Hausgebrauch recht selten an diese Dokumentgrößen stoßen. Dennoch turnt mich sowas direkt ein bisserl ab und die Erfahrung zeigt das diese "Exotenfälle" oft sehr viel schneller auf der Türmatte stehen als erwartet.

Wäre Xindice der einzige ernstzunehmende Anbieter im Open-Source-Umfeld wäre das denke ich kein großes Manko. Die gibt es aber wie wir im folgenden sehen werden.

eXist

Dies ist, um es vorwegzunehmen, mein Favorit unter den OSS-XML-Datenbanken. Auch eXist implementiert XML:DB, auch eXist ist komplett in Java implementiert, beides genau wie Xindice. Es gibt aber ein paar Fakten dies es davon abheben:

  • Es implementiert die Abfragesprache XQuery (ja damnunherrn, das ist ein 'Oooooh' wert)
  • Es besitzt einen automatischen, natürlich abfragbaren, Volltextindex
  • Es ist so schlau uns mit seinen Limitierungen nicht direkt ins Gesicht zu springen.

Daher habe ich eXist als Zielplattform für mein kleines Projekt ausgewählt, welches ich im nächsten Artikel dieser kleinen Reihe umreissen werde.

IBM DB2 "Viper"

Eingangs hatten ich gemutmaßt, dass der Grund für das bisherige Scheitern von XML-Datenbanken zum Teil darin liegt, dass sich kein großer Hersteller mit seinem Gewicht hinter das Thema geworfen hat. Das könnte bald Vergangenheit sein, da die IBM bald ein neues Produkt am Start hat, welches als "Hybride aus relationaler und XML-Datenbank" beworben wird.

Laut dem bisher vorliegenden Pressematerial haben wir uns das hauptsächlich so vorzustellen, dass es möglich sein wird, in relationalen Tabellen Spalten mit expliziten XML-Datentypen zu definieren. Diese Spalten können dann bei der SQL-Abfrage mit XPath-Ausdrücken abgefragt werden.

Das scheint aber (glücklicherweise) noch nicht alles zu sein. Alle XML-Daten werden wohl in einem separaten Datenbankkern gespeichert, der - zumindest interpretiere ich das Pressematerial so - auch alleine betrieben werden kann. Jedenfalls soll es auch eine XQuery-Abfragemöglichkeit geben. Weitere Details sind dem üblichen IBM-Marketing-Talk nicht zu entnehmen. Als Teilnehmer der mit diesem Produkt verbundenen Beta-Programmes werde ich wohl bald mehr wissen.

Tja, es bleibt spannend. Es wäre nicht das erste Produkt das IBM mit gewissem Aufwand propagiert und das dann in der Senke der Bedeutungslosigkeit verschwindet (nein, ich brauche hier keine Beispiele nennen...). Aber nach Prinzip Hoffnung ist das natürlich nicht das was ich erwarte.

Bitte geben Sie hier Ihren Kommentar ein:

Verwende Markdown Syntax

Autor

About

Last comments

  • Oliver:
    Als Antwort auf "Anonym" vom 27. Dezember 2015 (..
  • anonym:
    Habbo als abzocke zu deklarieren finde ich schon..
  • anonym:
    Wenn du es dir leisten kannst und es dich glückl..
  • Jebote:
    ja sicher kommen alle auf diesen 5 jahre alten a..
  • Micha:
    @Ingo, na klar. Alles legitim und voll ok ;-) Mu..

Really currently consuming

Links

  • Mehr Whisky
  • Ich@last.fm
  • Ich@Twitter
  • Dina
  • Julia
  • Der Meister (nebst Frau Meister)
  • Rockender Webworker
  • Irgendwas mit Fischen