Unternehmen jeder Branche halten geschäfts- und entscheidungsrelevante Daten für viele Jahre vor. Gesetzliche Vorgaben wie Basel II und Sarbanes-Oxley tun ein Übriges, um die dabei anfallenden Datenmengen auf Tera- und Petabyte-Größe anschwellen zu lassen. Ein Ende dieses Trends ist noch nicht in Sicht. Welche Techniken und Strategien aber sind am Besten dazu geeignet, solche ultragroßen Datenbanken möglichst nutzbringend einzusetzen?

Datenbankmanagementsystemen kommt in Unternehmen eine hohe strate-gische Bedeutung zu. Ihre Daten bilden die Grundlage für entscheidungs-relevante Analysen, Vorhersagen, Planungen und IT-gestützte Geschäftspro-zesse. Bei der rasanten Geschwindigkeit, mit der Geschäftsentscheidungen mitunter getroffen werden müssen, ist jedoch eine hohe Performance der Datenbanklösung selbst bei Abfragen über sehr große Datenmengen von ent-scheidender Bedeutung. Kriterien wie Antwortzeiten, Verfügbarkeit, Verwaltung und Kosten haben in diesem Zusammenhang unter IT-Verantwortlichen einen hohen Stellenwert. Im Prinzip sind relationale, objektorientierte oder hierarch-ische Systeme gleichermaßen gut für die Verwaltung ultragroßer Datenmengen im kommerziellen Umfeld geeignet. Entscheidend ist vielmehr der Einsatz der richtigen Strategien, welche das Management der Systeme vereinfachen und auch komplexe Suchanfragen und Analysen schnell bedienen. Ultragroße Datenbanken (ULDB – ultra large databases) sind „an einem Stück“ nur schwer handhabbar. Es empfiehlt sich deshalb, zwischen produktionsrelevantenDaten, die in den täglichen Geschäftsabläufen benötigt werden, und service- oder analyserelevanten Daten, die sich selten oder nie verändern, zu unterteilen. Die produktionsrelevanten Daten werden aus Performancegründen etwa auf schnellen Speichermedien mit garantiert kurzen Antwortzeiten abgespeichert und über einen eigenen Datenbankkern verwaltet.

Verwaltungsvorteile durch Partitionierung

Übersteigen die dadurch gebildeten kleineren Datensegmente immer noch eine zeitkritische Größe, kommt eine weitere Partitionierung der Daten in Betracht. Dabei werden Daten so gruppiert, dass Anwender sie möglichst effizient nutzen können. Beim Aufbau eines Dokumentenarchivs etwa liegt es nahe, die aktuel-len Jahrgängen 2004 bis 2007, auf die etwa 80 Prozent aller Nutzeranfragen entfallen, zu einer Datenpartition zusammenzufassen und mit schnellen Storage-Medien, hoher Rechenleistung und eigenem Datenbankkern auszustat-ten. Die weniger nachgefragten älteren Jahrgänge kommen mit leistungs-schwächeren und preisgünstigeren IT-Kapazitäten aus. Hier gilt es, Leistungs-anforderungen, Performance, Verwaltungsaufwand und Kosten gegeneinander abzuwiegen. Partitionierung erhöht die Komplexität, verbessert aber die Hand-habbarkeit der Datenbank etwa bei Backup und Recherche. Unstrukturierte Daten wie große Textdokumente, Bilder oder Videos unterliegen anderen Ver-haltensregeln als strukturierte, in relationalen Tabellen abgelegte Informati-onen. Zwar lassen sich unstrukturierte Daten über Container, die auch über Indizierungsmöglichkeiten verfügen, direkt in relationale Systeme integrieren. Sollen aber beispielsweise umfangreiche Textdokumente gespeichert, verarbei-tet und nachträglich geändert werden, empfiehlt sich der Einsatz einer XML-Datenbank. Der Textspezialist unter den Datenbanken bietet auch weiter gehende Strukturierungsmöglichkeiten etwa über selbst definierte XML-Tags. Manche Hersteller bieten die Möglichkeit beide Systeme über Metadaten und einen performaten Linkmiteinander zu koppeln und stellen den gemeinsamen Datenbestand der jeweiligen Anwendung zur Verfügung. Außerdem erzielt der Lösungsansatz der Koppelung durch seine datengruppenorientierte Verarbei-tung signifikante Geschwindigkeitsvorteile.

Hochverfügbar mit höherem Durchsatz im Cluster

Seit geraumer Zeit bieten Datenbank-Hersteller die Möglichkeit, ihre Systeme auf sogenannten Clustern zu betreiben. Dabei laufen Datenbankkerne auf mehreren, zu einem Netzverbund zusammengeschlossenen Rechnern synchron gegen eine Datenbank. Die Datenbankprozesse auf den Einzelrech-nern arbeiten zwar autonom, müssen sich aber bei Modifikationen der Daten synchronisieren, falls beispielsweise ein Kontobestand von zwei unterschied-lichen Transaktionen verändert wird – Abhebung und Einzahlung. Datenbanksysteme sollten diese Technik beherrschen. Anwender profitieren von Clustern durch höhere Verfügbarkeit und bessere Performance. Denn durch Load Balancing lässt sich Rechenleistung je nach Bedarf flexibel vertei-len. Fällt zudem im Netzverbund ein Rechner aus, übernimmt ein anderer dessen Aufgabe. Aus diesem Grund eignen sich Cluster auch sehr gut für welt-weite 24x7-Supportdienstleistungen mit Hochverfügbarkeitsgarantie. Diese Vorteile werden jedoch durch höhere Kosten und eine komplexere Systemver-waltung erkauft.

 Die Architektur und Komponenten der Datenbank Adabas auf einen Blick. 

Ausfallzeit so kurz wie möglich

Geht es um Datensicherheit und Verfügbarkeit, spielen Backup und Restore eine entscheidende Rolle. Da heute die meisten Datenbanken rund um die Uhr im 24x7-Modus bereit stehen, müssen die Daten im laufenden Betrieb gesich-ert und zurückgeladen werden. Für eine sogenannte „Offline Sicherung“ steht oft nur ein enges Zeitfenster zur Verfügung, welches für ULDBs meist nicht ausreicht. Um die Backup-Zeiten zu minimieren, statten die meisten Hersteller ihre Datenbankenmit einem sogenannten inkrementellen Backup aus, das nach einem vollständigen Backup des gesamten Datenbestandes lediglich die Änderungen sichert. Im Restore-Fall, was für den betroffenen Teil Ausfall bedeutet, ist es wichtig die Daten so schnell wie möglich zurückzu-spielen. Muss man sämtliche Inkremente plus Datenbasis zurückspielen ist das einmal fehleranfällig und kostet mehr Zeit als das Zurückladen eines „abge-mischten“ Sicherungsbestandes. Deshalb sollte Datenbank-Software die Mög-lichkeit bieten, die Einzelinkremente „offline“ abzumischen und zusammen mit der Vollsicherung als konsistentes Backup für den Notfall vorzuhalten, damit die Ausfallzeit so kurz wie möglich ausfällt. Ideal ist es auch, wenn man nur einzelne Tabelllen zurückladen kann. Alle hochverfügbaren Datenbanksysteme sollen im Schadensfall möglichst schnell wieder einsatzbereit sein. Ultragroße Datenmengen stellen dabei hohe Anforderungen. Ein performanter, aber auch teurer Lösungsansatz besteht in der Replizierung des gesamten Datenbestan-des auf Schattendatenbanken, die im „Hot Stand by“-Modus betrieben werden. Für die Synchronisation mit dem Primärsystem sorgen im einfachsten Fall Journal-Dateien, die sämtliche Transaktionen protokollieren. Eine komfortab-lere und sicherere Möglichkeit besteht in der Nutzung sogenannter Extract-Transform-Load-Software (ETL). ETL wird insbesondere beim Aufbau und Betrieb von Data Warehouses eingesetzt. Eine weitere effiziente Lösung ist die so genannte „Realtime Replizierung“. Sie ermöglicht den Transfer der Änder-ungen zu den Zielsystemen direkt nach Ende der Datenbank-Transaktion. Die Replikation dient somit zwei Zielen: einmal dem Aufbau von Data Warehous-es und der Bereitstellung einer Hot-stand-by Datenbank.

Ergebnisse so schnell wie möglich

Bei der Recherche in ultragroßen Datenbanken ist der Anwender auf hochef-fiziente Suchalgorithmen angewiesen. Vorteil bringt eine flexible Indizierung, die bei ad-hoc-Auswertungen schnell Indizes aufbauen und wieder verwerfen kann. Das spart Speicherplatz. Außerdem punkten Datenbanksysteme, die flexibel mit Modifikationen an Schemata und Indizes umgehen können. Bei Änderungen reduziert sich dadurch der Zeit- und Arbeitsaufwand erheblich. Auszahlen wird sich sicher auch eine optimierende Suchstrategie, die dafür sorgt, dass im Recherchelauf möglichst wenige Daten ohne Umwege durch-sucht werden müssen.
Eine leistungsfähige ultragroße Datenbank ist mit einem Pianisten im Orchester vergleichbar. Sie muss in unterschiedlichen Systemumgebungen laufen können, Schnittstellen zu Anwendungen enthalten und Optimierungstechniken etwa bei Backup, Partitionierung oder Recherche zu ihrem Vorteil nutzen können. Erst in der souveränen Beherrschung der gesamten Klaviatur zeigt sich der Meister.

Wolfgang Weiss

Diesen Artikel finden Sie auch in der Ausgabe Januar/Februar 2008 des it management.