Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.10.1995

Datenbanken/Datenbankarchitekturen fuer neue Multiprozessorsysteme

Data-Warehousing, Decision-Support und Online- Transaktionsverarbeitung (OLTP) erfordern haeufig Datenbanken von mehreren hundert Gigabyte bis in den Terabyte-Bereich. Dieser Trend zu Very Large Databases (VLDB) wird dadurch gefoerdert, dass nach Leistung und Kapazitaet kostenguenstige Parallelrechner den traditionellen Mainframes in nichts mehr nachstehen. Diese Hardware laesst sich mit einer neuen Generation paralleler Datenbank-Management-Systeme (DBMS) nutzen, um selbst groesste Datenmengen effizient zu verarbeiten.

Von Barbara Finger*

Noch vor 15 Jahren wurde eine 100-MB-Datenbank als relativ gross erachtet, und es gab nur wenige Modelle im Gigabyte-Bereich. Heute dagegen gelten Datenbanken um die 10 GB als gross, und es gibt vereinzelt Produkte jenseits der 100-GB-Grenze. Tendenz: schnell steigend.

Besondere Anforderungen stellen allerdings Datenbanken, die einzelne Tabellen mit mehreren 100 Millionen Datensaetzen enthalten. Will man eine solche Tabelle durchsuchen oder gar zwei bis drei davon miteinander verknuepfen, reicht dies vollkommen aus, um traditionelle DBMS an ihre Leistungsgrenzen zu fuehren. Erschwerend kommt hinzu, dass viele dieser Databases nicht statisch sind, sondern sehr schnell wachsen.

Ein Beispiel: Bei einem grossen Kreditkarteninstitut mit einem millionenfachen Kundenkreis gilt es, ungewoehnliches Einkaufsverhalten der Kunden auszumachen. Dafuer bedarf es des Zugriffs auf detaillierte Kundendaten, wobei pro Kunde 700 bis 800 Datenfelder vorhanden sind. Die Untersuchung soll einen Zeitraum von fuenf Jahren abdecken, wodurch es um Hunderte wenn nicht Tausende Positionen pro Kunde geht. Die Datenbank duerfte in diesem Fall leicht ueber einem Terabyte liegen. Traditionelle DBMS, die eine Suchgeschwindigkeit von durchschnittlich 10 MB pro Sekunde leisten, braeuchten mehr als 26 Stunden, um nur einmal diese Daten zu lesen. Bei dieser Geschwindigkeit bestuende keine Chance, derartige Auswertungen durchzufuehren.

Bei doppelter Datenmenge halbierte Antwortzeiten?

So sind heute DBMS-Anbieter mit neuen Anforderungen konfrontiert. Einerseits werden Anwendungen weiter ausgebaut (sogenannter Scale- up), was mehr Anwender und groessere Tabellen gestattet, das heisst mehr Daten. Andererseits sollen Anwendungen schneller werden, also kuerzere Antwortzeiten bieten, und das bei gleichbleibender Anwenderzahl beziehungsweise Datenmenge (sogenannter Speed-up).

Optimal waere ein linearer Speed-up und Scale-up, um bei einer Verdopplung der Prozessoren die Antwortzeit zu halbieren oder dieselbe Performance bei einer doppelten Datenmenge zu erreichen. Die Loesung hierfuer liegt in der Parallelverarbeitung.

Neben der Hardware (siehe Kasten) ist die DBMS-Software eine Variable in der VLDB-Gleichung. Durch die Lastanforderungen von VLDBs stossen herkoemmliche DBMS-Anwendungen in zweifacher Hinsicht an ihre Grenzen: Sie koennen die Performance und Skalierbarkeit moderner Hardware nicht voll nutzen, und ihr Verfuegbarkeitsgrad ist fuer unternehmenskritische Anwendungen haeufig nicht akzeptabel. Vereinfacht ausgedrueckt: Lose gekoppelte Cluster und MPP- Architekturen (Massively Parallel Processing) sind fuer viele DBMS eine Nummer zu gross.

Um lose gekoppelte Cluster oder MPP-Architekturen zu einer geeigneten Loesung fuer den kommerziellen Einsatz zu machen, muss ein Datenbank-Server folgende Kriterien erfuellen:

1. Nutzung aller verfuegbaren Hardwareressourcen, um lineare Performance-Verbesserungen und Skalierbarkeit zu ermoeglichen (Parallelisierungsarten, Datenpartitionierung, Datenbankarchitekturen);

2. Sicherstellung staendiger Datenbankverfuegbarkeit in unternehmenskritischen Umgebungen;

3. einheitliche Sicht aller Datenbankobjekte des Systems (Single- System View);

4. Gewaehrleistung von Anwendungskompatibilitaet und -transparenz unabhaengig von der Hardwareplattform sowie

5. Unterstuetzung einer grossen Auswahl preiswerter Open-Systems- Hardware und -Betriebssysteme.

Multithreading - ein erster Schritt zur Parallelitaet

Ein paralleler Datenbank-Server sollte in der Lage sein, die Leistungsstaerke und Skalierbarkeit lose gekoppelter und massiv- paralleler Systeme zu adaptieren, um Vorteile aus der parallelen Hardware ziehen zu koennen. Der erste Schritt in diese Richtung ist die Implementierung einer Multithreading- und Multiserver- Architektur. Sie ermoeglicht es, dass mehrere Datenbankprozesse oder Threads mehrere Benutzeranfragen gleichzeitig bedienen koennen. Diese Form der Parallelverarbeitung ist auch als Inter-Query- Parallelismus bekannt.

Die meisten DBMS-Hersteller haben ihre Architektur heute mehr oder weniger auf diese Anforderungen hin ausgerichtet. Nur wenige aber haben wie Informix mit der Dynamic Scalable Architecture ein komplettes Redesign ihrer Architektur vorgenommen.

Inter-Query-Parallelismus verbessert in erster Linie den Systemdurchsatz, so dass es moeglich ist, mehr Benutzer gleichzeitig zu bedienen. Abfragen sind zwar parallele Vorgaenge, jede Abfrage fuer sich wird aber weiterhin seriell ausgefuehrt. Ein Prozess oder Thread bearbeitet jede Operation der einzelnen Benutzeranfrage sequentiell.

Bei einer Abfrage muss jede Operation beendet sein, bevor die naechste beginnen kann. Also sind zuerst alle Daten einzulesen, bevor die einzelnen Datensaetze miteinander verknuepft werden koennen. Bei komplexen, lang laufenden Abfragen fuehrt dies zur Blockierung aller Ressourcen und zu langen Antwortzeiten fuer alle Benutzer.

Die naechste Stufe der Parallelverarbeitung ist der Inter-Query- Parallelismus. Bei dieser Art der Parallelverarbeitung wird ein SQL-Statement in mehrere Tasks aufgebrochen, die die Prozessoren dann parallel ausfuehren. Damit kann man einer einzelnen Benutzeranfrage zusaetzliche Ressourcen zur Verfuegung stellen und somit die Antwortzeiten erheblich reduzieren.

Zweite Stufe: Aufbrechen von den SQL-Statements

Tasks innerhalb eines SQL-Statements lassen sich auf zwei Arten parallel ausfuehren; horizontal oder vertikal. Parallele DBMS sollten in jedem Fall beide Parallelisierungsarten unterstuetzen.

Bei vertikalem Parallelismus, auch Pipelining genannt, laufen mehrere unterschiedliche Operationen gleichzeitig auf verschiedenen Prozessoren ab. Eine Abfrage, die zwei Tabellen miteinander verknuepft, koennte beispielsweise folgende Operationen umfassen: Scan, Join und Sort.

Bei vertikal-paralleler Ausfuehrung beginnt nach dem Einlesen der ersten Daten bereits eine Join-Operation, diese Daten zu verbinden. Sobald genuegend Informationen verknuepft sind, beginnt eine neue Operation, diese Daten zu sortieren. Sobald auch hier ausreichender Output zur Verfuegung steht, beginnt eine weitere Operation, die bereits sortierten Daten zu schreiben.

Ein Datenbank-Server muss automatisch erkennen, welche Systemressourcen verfuegbar sind, und Tasks bei Bedarf in mehrere Sub-Tasks aufteilen, die dann unabhaengig voneinander und parallel auf den einzelnen Prozessoren ausgefuehrt werden koennen. Dieses Prinzip, das als horizontaler Parallelismus oder auch partitionierter Parallelismus bezeichnet wird, sorgt bei komplexen Abfragen fuer deutlich kuerzere Ausfuehrungszeiten.

Datenpartitionierung erlaubt physische Verteilung

Erst mit Hilfe der Datenpartitionierung lassen sich Datenbankoperationen effektiv parallel ausfuehren. Datenpartitionierung ermoeglicht die physische Aufteilung einer Datenbank, wobei die einzelnen Bestandteile wie eine Gruppe kleinerer Datenbanken behandelt werden. Jede Partition bei SMP- Systemen liegt auf einer separaten Platte oder bei lose gekoppelten und MPP-Systemen auf einem separaten Knoten. Auf diese Weise lassen sich Operationen wie Scans, Joins und Sorts auf mehrere CPUs und Platten verteilen und parallel ausfuehren. Fuer die Datenpartitionierung stehen mehrere Verfahren zur Auswahl: Random, Round-Robin, Hash, Range, Schema oder Expression.

Random- und Round-Robin-Partitionierung

Alle DBMS unterstuetzen die Verteilung einer Tabelle in Form des "Disk-Strippings" ueber mehrere Platten eines Servers. Eine weitere Variante ist die Round-Robin-Partitionierung - die Daten werden sequentiell ueber mehrere Platten verteilt. Damit ist eine gleichmaessige Aufteilung auf alle Platten der Infrastruktur gewaehrleistet.

Da die Datenverteilung jedoch keinem bestimmten Schema unterliegt, hat das DBMS keine Informationen darueber, wo sich welche Daten befinden. Ein Datensatz kann in irgendeiner Partition liegen. Unter Umstaenden sind alle Partitionen zu durchsuchen, um einen bestimmten Datensatz zu finden, was Auswirkungen auf die Performance hat. Aus diesem Grund ist die Random- oder Round- Robin-Partitionierung nicht die effizienteste Partitionierungsmethode.

Bei intelligenter Partitionierung weiss das DBMS, wo sich welcher Datensatz befindet. Der Anwender legt einen Partitionierungsschluessel fuer die Tabelle fest. Das DBMS bestimmt basierend auf dessen Wert, wo der Datensatz zu speichern ist. Intelligente Partitionierungsmethoden sind Hash-, Range-, Expression- und Schema-Partitionierung.

Die Hash-Partitionierung setzt den Schluesselwert eines Datensatzes ueber einen speziellen Algorithmus direkt in eine Speicheradresse um. Wie die Round-Robin-Methode ermoeglicht auch das Hash-Verfahren eine gleichmaessigere Verteilung der Daten. Benoetigt eine Abfrage Zugriff auf einen bestimmten Datensatz, kann das System mit Hilfe des Hash-Schluessels feststellen, in welcher Partition sich die Daten befinden. Ist die Partition ermittelt, kann unter Zuhilfenahme eines Index direkt auf den Datensatz zugegriffen werden.

Die Vorteile der Hash- und Range-Partionierung

Durch Hash-Partitionierung lassen sich auch zusammengehoerige Datensaetze aus zwei verschiedenen Tabellen finden. Wenn beispielsweise in verteilten Umgebungen (Cluster und MPP-Systeme) Kundendatensaetze und die dazugehoerigen Auftragsdaten mit dem Hash- Verfahren dem selben Knoten zugewiesen wurden, besteht die Moeglichkeit, auf lokaler Ebene mit einer Join-Operation die von einem Kunden getaetigten Auftraege zu ermitteln oder eine Transaktion mit beiden Tabellen durchzufuehren. Damit entfaellt die Notwendigkeit kostenaufwendigerer verteilter Transaktionen.

Die Range-Partitionierung teilt die Daten nach Schluesselbereichen auf. Die Partitionierung einer Kundentabelle koennte beispielsweise auf Basis des ersten Buchstabens des Nachnamens erfolgen, so dass Kunden mit den Anfangsbuchstaben A bis C auf Knoten 1, Platte 1 abgelegt werden, D bis F auf Knoten 1, Platte 2, G bis J auf Knoten 2, Platte 1 und so weiter.

Range-Partitionierung ist besonders fuer Bereichsabfragen geeignet, da sie den direkten Zugriff auf die fuer die Abfrage relevante Datenpartition ermoeglicht. Im vorhergenannten Beispiel waere an einer Abfrage, die Zugriff auf alle Kunden mit dem Anfangsbuchstaben D erfordert, also nur Knoten 1 beteiligt, da auf ihm alle benoetigten Daten abgelegt sind.

Einsatz von Expression- und Schemapartitionierung

Die Expression-Partitionierung bieten nur der Online Dynamic Server und der neue Online Extended Parallel Server von Informix. Es handelt sich dabei um eine Erweiterung der Range- Partitionierung, bei der Daten auf Basis eines benutzerdefinierten Ausdrucks partitioniert werden. Der Ausdruck wird in der Where- Klausel der SQL-Anweisung angegeben, zum Beispiel der Wohnort des Kunden.

Anders als bei der Range-Partitionierung, bei der der Benutzer die tatsaechliche Datenverteilung festlegt, erfolgt die Partitionierung von Werten und Bereichen innerhalb des Ausdrucks durch das System. Das heisst, das System sortiert zunaechst die Tabellen auf Basis des Schluessels und versucht dann, auf jeder Platte etwa so viele Zeilen abzulegen, dass die jeweils maximale Partitionsgroesse erreicht wird.

Schemapartitionierung verwendet nur Sybase beim "Navigation Server". Sie bietet die Moeglichkeit, eine Tabelle nicht ueber die Platten beziehungsweise Knoten zu verteilen, sondern diese auf einer speziellen Partition im Ganzen zu plazieren, zum Beispiel Lookup-Tabellen, also solche, die keiner grossen Aenderung unterliegen. Schemapartitionierung kann allerdings bei nicht optimalem Vorgehen zu ungleichmaessiger Lastverteilung fuehren.

Intelligente Partitionierung verbessert die Performance und erhoeht die Verfuegbarkeit. Dadurch laesst sich vermeiden, dass Partitionen eingelesen werden, die keine den Abfragekriterien entsprechenden Daten enthalten.

Intelligentes Datensplit bei verschiedenen Herstellern

Das DBMS weiss, wohin Update- und Delete-Statements zu schicken sind, und die Verarbeitung einer Abfrage bleibt von nicht verfuegbaren Partitionen unberuehrt. Ein weiterer Vorteil ist die Moeglichkeit, einen Backup oder Restore einzelner Partitionen vorzunehmen, wobei die anderen Partitionen "online" bleiben. Erst mit diesen Moeglichkeiten lassen sich VLDBs effizient verwalten.

Ein anderer wichtiger Aspekt ist, inwieweit man den Grad der Partitionierung einer Tabelle ueber Platten und Knoten festlegen kann. Hersteller wie Informix, IBM und Sybase bieten die Moeglicheit, die Anzahl der Platten und Knoten zu spezifizieren, ueber die eine Tabelle zu verteilen ist. Damit stehen weitere flexible Tuning-Moeglichkeiten zur Verfuegung.

Um den Aufwand beim Entwerfen von Partitionierungsstrategien zu minimieren, bieten die Hersteller Tools an. Diese erstellen Partitionierungs- und Indexierungsschemata und sind im Fall ungleichmaessiger Lastverteilung bei der Repartitionierung "online" und parallel behilflich.

Alle Datenbankprodukte bis auf Oracle unterstuetzen wenigstens eine intelligente Partitionierungsmethode. Je mehr davon zur Verfuegung stehen, um so mehr Moeglichkeiten hat der Datenbankadministrator, jene Partitionierungsmethode auszuwaehlen, die am besten zu der Methode passt, mit der auf die Daten zugegriffen wird.

Eine weitere Schluesselkomponente ist die Datenbankarchitektur. Sie bestimmt letztlich, inwieweit ein System skalierbar ist. Das aber haengt davon ab, inwieweit die Hersteller die Hardwaretechnik auf ihre Software-Architektur abbilden koennen. (wird fortgesetzt)

*Barbara Finger ist Produkt-Managerin Datenbank-Server bei der Informix Software GmbH in Ismaning.