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.