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.

02.06.1989 - 

DB-Durchsatzoptimierung beginnt nicht erst bei der Implementierung:

Die Performance hängt auch von der Architektur ab

Entscheidend für die Performance ist die konzeptionelle Ausgewogenheit in einem Datenbank-Management-System. Bleibt nur an einer Stelle der Architektur ein Engpaß zurück, behindert dies den Durchsatz des Gesamtsystems. "Deshalb", so konstatiert Helmut Wilke*, "ist es besonders wichtig, die Performance bereits bei der architektonischen Gestaltung im Auge zu haben.

Bei der SW-Entwicklung gibt es eine klassische Aufteilung: Die Funktionalität wird durch die Architektur festgelegt, die Performance durch die Implementierung erreicht. Im Bereich relationaler Datenbank-Management-Systeme gibt es jedoch eine Reihe wichtiger architektonischer Aspekte, die sich unmittelbar auf die Performance auswirken. Hier muß die Durchsatzoptimierung folglich bereits bei der Festschreibung der DBMS-Architektur beginnen, nicht erst bei der Implementierung.

Man unterscheidet bei Datenbank-Management-Systemen zwischen Datenbankservern (Backend, DBMS-Engine) und Datenbankapplikationen (Frontend, Client). Die Art und Weise des Zusammenspiels dieser beiden Komponenten hat erhebliche Auswirkungen auf die Performance eines datenbankorientierten Gesamtsystems. Im folgenden werden die unterschiedlichen Möglichkeiten aufgezeigt.

Herkömmlicherweise wird bei Datenbankmanagementsystemen, die aus dem Minicomputerbereich kommen, für jeden Frontend-Prozeß, also für jeden Datenbankbenutzer, ein eigener Backend-Prozeß im Rechner eingerichtet. Man nennt dies auch eine 1:1-Architektur. Für zum Beispiel 100 Benutzer sind somit exakt 200 Prozesse notwendig (100 Frontends und 100 Backends).

Eine Überlastung ist praktisch ausgeschlossen

Dieses Konzept - manchmal auch "einfache Multiserver-Architektur" genannt - zeichnet sich durch eine relativ hohe Performance aus, da jeder Benutzer einen Server-Prozeß für sich allein zur Verfügung gestellt bekommt. Die Überlastung eines Backends etwa durch zu viele Frontend-Prozesse ist praktisch ausgeschlossen.

Allerdings besteht bei diesem Konzept die große Gefahr einer Überlastung des Rechners beziehungsweise der Speicherkapazität durch zu viele Server-Prozesse, die gleichzeitig eingerichtet werden. Zudem erlaubt die starre Zuordnung von Frontend und Backend nicht die Ausnutzung von Hardwareumgebungen mit mehreren CPUs, sei es in Multiprozessorrechnern oder in Clustern. Das bedeutet, daß diese Architektur in komplexeren Hardwarekonfigurationen hinsichtlich der Performance nicht optimal ist. Hier wäre es wünschenswert, wenn sich die Backend-Prozesse flexibel auf die einzelnen Prozessoren verteilen ließen.

DBMS aus der PC-Welt, die für PC-LAN-Umgebungen konzipiert sind, funktionieren üblicherweise nach dem Singleserver-Prinzip. Hier wird nur ein einziger Backend-Prozeß eingerichtet, der (theoretisch) beliebig viele Frontend-Prozesse (Benutzer) bedienen kann. Man spricht daher auch von einer n:1-Architektur (für n Frontends steht genau ein Backend zur Verfügung). Für 100 Benutzer werden hierbei insgesamt 101 Prozesse benötigt (100 Frontends und ein Backend).

Dieses Konzept ist wesentlich effizienter als das der 1:1-Architektur. Es schont insbesondere die Hauptspeicherkapazität des Server-Rechners, die nicht durch hunderte von Backends verbraucht wird.

Freie Zuordnung erlaubt Optimierung

Der schwerwiegende Nachteil liegt darin, daß der eine Server-Prozeß, der alle Benutzer bedient, in der Praxis bei umfangreichen Datenbankapplikationen zum Engpaß werden kann. Selbst wenn hardwareseitig mehrere CPUs zur Verfügung stehen, sind sie mit einem Singleserver-Datenbanksystem nicht optimal nutzbar. Zwar läßt sich unter Umständen auf jeder CPU ein einzelner Singleserver einrichten, so daß auch eine "Multiserver-Situation" entsteht, jedoch können diese Server nicht auf ein- und dieselbe Datenbank zugreifen. In einem Singleserver-Konzept ist daher bestenfalls möglich, daß mehrere Backend-Prozesse isoliert voneinander laufen.

Bei einer flexiblen Multiserver-Architektur kann der Anwender die Zuordnung zwischen Frontend- und Backend-Prozessen frei wählen. Man nennt dies auch eine n:m-Architektur (beliebig vielen Backends stehen beliebig viele Frontends gegenüber). Zur Unterstützung von 100 Benutzern sind 101 oder mehr Prozesse nötig (100 Frontend-Prozesse und mindestens ein Backend).

Die freie Zuordnung erlaubt die Optimierung der Front-/Backend-Konfiguration unter Aspekten wie Performance, Benutzergruppenprioritäten oder Hardwaregegebenheiten (mehrere CPUs). Wichtig hierbei ist, daß alle Backend-Prozesse auf ein- und dieselbe Datenbank zugreifen können (aber nicht müssen).

Für jede CPU ein Backend-Prozessor

Für den Anwender ergeben sich damit drei wesentliche Vorteile: Auf einer einzelnen CPU lassen sich mehrere Backends einrichten, die Benutzergruppen mit unterschiedlichen Prioritäten bedienen (beispielsweise mit höchster Priorität für Transaktionsapplikationen und niedrigerer Priorität für Abfrageoperationen). Multiprozessorrechner sind optimal nutzbar, indem für jede CPU ein Backend-Prozeß eingerichtet wird. In vernetzten DV-Umgebungen lassen sich Datenbankserver gemäß den jeweiligen Erfordernissen flexibel auf mehreren Rechnern installieren, um die verteilte Verarbeitung zu optimieren. Die Server arbeiten dabei im Idealfall integrierend zusammen.

Neben der Frontend-/Backend-Zuordnung gibt es noch eine Reihe weiterer architektonischer Aspekte, die für die Performance eines Datenbanksystems von ausschlaggebender Bedeutung sind. Sie werden im folgenden vorgestellt.

Durch DB-Prozeduren Performance erhöhen

Es bietet sich an, Datenbankprozeduren im Backend abzulegen. Einmal kompiliert, lassen sie sich durch Frontend-Prozesse beliebig oft aufrufen. Die Prozeduren sollten sowohl SQL- als auch 4GL-Code enthalten können. Wünschenswert ist dabei, daß der Programmierer die Prozeduren in exakt denselben Sprachen (SQL oder 4GL) verfassen kann, mit denen er auch im Frontend arbeitet. Damit läßt sich zugleich eine eigene Programmiersprache für DB-Prozeduren einsparen. Die Funktionen der im Backend abgelegten Prozeduren sollten im Bedarfsfall allen Frontend-Prozessen (Benutzern) zur Verfügung stehen.

Der Einsatz von DB-Prozeduren erlaubt es, die Anzahl der benötigten Ein- und Ausgabeoperationen zwischen Frontend- und Backend-Prozessoren zu reduzieren und somit die Performance zu erhöhen. Beispielsweise läßt sich eine TP1 -Transaktion über DB-Prozeduren mit nur zwei E/A-Operationen zwischen Front- und Backend abwickeln, während ansonsten zwölf Operationen nötig wären.

Bei der Arbeitsweise des Group Commit wird ebenfalls die Anzahl der Ein-/Ausgabeoperationen zwischen Frontend- und Backend-Prozessen verringert. Der Server schreibt hierbei nicht jede ankommende Frontend-Anfrage einzeln in das Log-File auf Platte. Vielmehr sammelt er die Frontend-Anfragen (Updates), die innerhalb eines festgelegten Zeitrahmens ankommen, um sie mit einer einzigen E/A-Operation gemeinsam auf der Platte zu speichern. Damit werden beispielsweise für eine standardisierte Debit-Credit-Transaktion nur noch 2,2 E/A-Operationen benötigt, während es herkömmlicherweise acht derartige Operationen sind.

Datenbanktabelle auf mehreren Platten

Fast Commit bedeutet, daß Transaktionen für den Frontend-Prozeß (Benutzer, Anwenderprogramm) abgeschlossen werden, bevor sie in der Datenbank gespeichert sind, ohne daß die Datensicherheit darunter leidet. Sobald das DBMS von Frontends kommende Daten in das Log-File auf der Platte abgelegt hat, sind diese gesichert, so daß die Commit-Rückmeldung zu diesem Zeitpunkt ohne Sicherheitseinbußen erfolgen kann. Das Backend steht für die nächste Transaktion des Frontends zur Verfügung. Die Übernahme der im Log-File gespeicherten Daten in die Datenbank erledigt der Backend-Prozeß selbständig und somit unabhängig vom Benutzer oder Anwendungsprogramm.

Eine weitere nützliche Eigenschaft von DBMS, die sich unmittelbar auf die Performance auswirkt, ist der "Multivolume Table Support". Dies bedeutet, daß eine Datenbanktabelle nicht vollständig auf einer Festplatte gehalten werden muß, sondern sich über mehrere Platten verteilen läßt. Hieraus ergeben sich im wesentlichen zwei Vorteile: Der Umfang einer Tabelle wird nicht durch die physikalische Speicherkapazität einer Platte begrenzt. Durch die Fragmentierung von Tabellen auf verschiedene Platten können mehrere Plattenzugriffe gleichzeitig erfolgen.

Sind ohne Fragmentierungsmöglichkeiten zum Beispiel höchstens 15 Update-Operationen in der Sekunde pro Tabelle möglich, erhöht sich dies bei Verteilung der Tabelle auf drei derartige Platten auf dreimal 15 Updates pro Sekunde. Allgemein gesagt: Durch den Einsatz von n Platten kann die Anzahl der E/A-Operationen in einer gegebenen Zeitspanne maximal auf das n-fache gesteigert werden. Hierdurch kommt es auch zu einer gewissen Abkopplung zwischen (schnellen) CPUs und (langsamen) Plattenlaufwerken, so daß beispielsweise neue Hardwaretechnologien wie Multiprozessorrechner ohne Behinderung durch die Peripherie besser nutzbar sind.

Nichts gegen eine gute Implementierung

Entscheidend für die Performance ist die ausgewogene Kombination der genannten Konzepte in einem Datenbank-Management-System. Wenn nur an einer Stelle innerhalb der DBMS-Architektur ein Engpaß zurückbleibt, behindert dies den Durchsatz des Gesamtsystems. Aus diesem Grund ist es bei einem Datenbanksystem besonders wichtig, die Performance bereits bei der architektonischen Gestaltung im Auge zu haben - womit nichts gegen gute Implementierung gesagt sein soll.