Klassifikation und Vergleich verteilter Transaktionssysteme

Transkript

1 Prc. GIWrkshp "Verteilte Datenbanksysteme und verteilte Datenverwaltung in Frschung und Praxis" DatenbankRundbrief Nr. 8 der GIFachgruppe Datenbanken, Nv. 1991, S Klassifikatin und Vergleich verteilter Transaktinssysteme Erhard Rahm Universität Kaiserslautern, Fachbereich Infrmatik rahm@infrmatik.unikl.de 1. Einführung Transaktinssysteme [11] befinden sich in weit verbreitetem Einsatz in der kmmerziellen Datenverarbeitung, insbesndere im Rahmen vn Auskunfts und Buchungssystemen swie zur aktenlsen Sachbearbeitung, z.b. bei Behörden der Versicherungen. Kennzeichnende Eigenschaften slcher Systeme sind u.a. die dialgrientierte Verarbeitung vn meist einfachen Transaktinen (Bsp.: Kntenbuchung) swie die Bereitstellung einer hhen (maskenrientierten) EndbenutzerSchnittstelle. Hauptkmpnenten eines Transaktinssystemes sind das Datenbanksystem (DBS), bestehend aus Datenbank und Datenbankverwaltungssystem (DBVS), swie ein DCSystem, bestehend aus einem TPMnitr swie der Menge der Transaktins der Anwendungsprgramme. Der TP Mnitr kntrlliert die Ausführung der Prgramme und realisiert die Kmmunikatin vn Prgrammen mit Terminals swie mit dem DBVS. Insbesndere können s physische Eigenschaften der Terminals swie des Verbindungsnetzwerks für den Prgrammierer transparent gehalten werden. TPMnitr und DBVS führen ein krdiniertes CmmitPrtkll aus, um die AtmaritätsEigenschaft einer Transaktin zu gewährleisten. Traditinellerweiser erflgt die Transaktinsverarbeitung zentralisiert auf einem Grßrechner (Mainframe). Eine Vielzahl vn Gründen führte zu verschiedenen Typen vn verteilten Transaktinssystemen, welche in diesem Aufsatz klassifiziert werden sllen. Hauptgründe für den Einsatz verteilter Transaktinssysteme sind: 1. Leistungsanfrderungen (Abwicklung hher Transaktinsraten, kurze Antwrtzeiten) Für Hchleistungsanwendungen sind die gefrderten Transaktinsraten (mehrere Tausend Transaktinen pr Sekunde) durch einen einzigen Rechner nicht zu bewältigen. Die Antwrtzeit kmplexerer Transaktinen (Anfragen) sll ggf. durch Parallelverarbeitung verringert werden. Vn genereller Wichtigkeit im verteilten Fall ist, daß möglichst wenig Kmmunikatinsverzögerungen und Overhead bei der Abarbeitung einer Transaktin anfallen und daß alle Rechner effektiv genutzt werden können (Lastbalancierung). 2. Hhe Verfügbarkeit 3. Mdulare Wachstumsfähigkeit des Systems 4. Anpassung des Transaktinssystems an die Organisatinsstruktur => gegraphische Verteilung des Systems und der Datenbank(en) 5. Unterstützung vn Kntenautnmie 6. Integrierter Zugriff auf hetergene Datenbanken 7. Verbesserung der Ksteneffektivität durch verstärkten Einsatz vn Mikrprzessren (z.b. in Wrkstatins der dedizierten BackendRechnern) Bei einem Vergleich verschiedener Architekturfrmen verteilter Transaktinssysteme ist zu prüfen, in welchem Ausmaß sie die genannten Anfrderungen erfüllen können. Dabei sind jedch nch weitere Aspekte zu berücksichtigen, z.b. Einfachheit der Realisierung, Prgrammierung (Ortstransparenz!) und Administratin. Bei der Realisierung verteilter Transaktinssysteme sind einige grundsätzliche Allkatinsprbleme zu lösen, insbesndere hinsichtlich der Rechnerzurdnung vn Systemfunktinen (TPMnitr, DBVS), Anwendungsfunktinen (Transaktinsprgrammen), Daten und Lasteinheiten. Bei der Allkatin vn Systemfunktinen unterscheiden wir zwischen zwei generellen Alternativen, welche die Basis unseres Klassifikatinsschema bilden. Bei hrizntal verteilten Transaktinssystemen liegt eine Replikatin vn Systemfunktinen vr, s daß jeder Rechner die gleiche

2 Funktinalität hinsichtlich der Transaktinsbearbeitung aufweist. Dagegen erflgt bei den vertikal verteilten Transaktinssystemen eine Partitinierung der Systemfunktinen auf FrntEnd und BackEndRechner (Server), welche zu einer funktinalen Spezialisierung der Rechner führt. In beiden Fällen kann die Verteilung auf mehreren Ebenen des DCSystems der des DBVS erflgen, ebens lassen sich beide Verteilfrmen kmbinieren. Verteilte Datenbanksysteme zählen zur Klasse der hrizntal verteilten Transaktinssysteme mit Verteilung im DBVS; WrkstatinServerSysteme und Datenbankmaschinen sind Beispiele vertikal verteilter Transaktinssysteme. Verteilte TPMnitre können swhl eine hrizntale als eine vertikale Verteilung unterstützen. Eine genauere Betrachtung der verschiedenen Ausprägungen hrizntal und vertikal verteilter Transaktinssysteme erflgt in Kap. 2 und 3. Bei der Rechnerzurdnung vn Transaktinsprgrammen (TAP) und Daten kann ebenfalls zwischen Partitinierung und (teilweiser der vller) Replikatin unterschieden werden. Dabei liegt im Falle der Partitinierung ein Prgramm/Datum an genau einem Rechner vr, während im Falle der Replikatin mehrere der alle Rechner eine Kpie des Prgrammes/Datums halten. Replikatin erhöht die Möglichkeiten der Lastbalancierung, da dann mehrere Rechner zur Auswahl stehen, um ein bestimmtes Prgramm bzw. einen DBZugriff zu bearbeiten. Auf der anderen Seite entsteht ein erhöhter Speicherplatzbedarf und Änderungsaufwand. Eine weitere Allkatinsfrm ist das sgenannte Sharing, bei dem alle Rechner direkt auf alle Platten zugreifen können und damit auf die drt gespeicherten TAP und Daten. Diese Strategie vermeidet, eine Partitinierung vn Prgrammen und Daten vrnehmen zu müssen, und bietet dasselbe Optimierungsptential zur Lastbalancierung wie bei vller Replikatin. Eine Einschränkung dabei ist, daß die Rechner aufgrund der Plattenanbindung nicht gegraphisch verteilt werden können. Bei der Lastzurdnung sind mehrere Verteileinheiten möglich (Transaktinsaufträge, DBOperatinen,...), welche durch die gewählte Allkatin vn Funktinen und Daten mitbestimmt werden. Generell sllte es möglich sein, den aktuellen Systemzustand (Rechnerauslastung, etc.) bei der Lastzurdnung zu berücksichtigen, um eine effektive Lastbalancierung zu erzielen. 2. Hrizntal verteilte Transaktinssysteme In hrizntal verteilten Transaktinssystemen sind die beteiligten Rechner funktinal äquivalent hinsichtlich der Transaktinsverarbeitung. Es liegt eine Replikatin vn Systemfunktinen vr, s daß in jedem Rechner ein TP Mnitr und ein DBVS laufen und zusammenarbeiten. Allerdings wird keine Hmgenität der Rechner gefrdert; vielmehr können verschiedene TPMnitre und DBVS auf den einzelnen Rechnern laufen und hetergene Betriebssysteme und RechnerHardware vrliegen. Eine weitergehende Unterteilung hrizntal verteilter Transaktinssysteme ist möglich, wenn unterschieden wird, auf welcher Ebene innerhalb des DCSystems der des DBS die Rechner miteinander kperieren, w als die Verteilung sichtbar ist. Hierzu unterteilen wir zwischen Verteilung nur im DCSystem, Verteilung im DBS (MehrrechnerDBS) swie Verteilung im DCSystem und im DBS. Verteilung (nur) im DCSystem In diesem Fall erflgt die Kmmunikatin zwischen den TPMnitren der Rechner, während die DBVS vneinander unabhängig sind. Dies hat den Vrteil einer relativ geringen Systemkmplexität, da bei den DBVS (nahezu) keine Erweiterung im Vergleich zum zentralisierten System erfrderlich ist. Zudem ist es möglich, hetergene DBVS auf verschiedenen Rechnern einzusetzen. Auch wird ein hhes Maß an Kntenautnmie gewährleistet, da jeder Rechner eine unabhängige Datenbank hält, die durch ein eigenes knzeptinelles Schema beschrieben wird. Aufgrund der Unabhängigkeit der DBVS liegt hierbei in der Regel eine Partitinierung der Daten vr (Datenreplikatin müßte ansnsten im DCSystem gewartet werden; analg müßte bei einem Sharing die ntwendige glbale Synchrnisierung der Datenzugriffe im DCSystem erflgen). Die Einheit der Datenverteilung ist sehr grb (ganze Datenbanken). Nachteile ergeben sich auch hinsichtlich Verfügbarkeitsanfrderungen: fällt ein Rechner aus, sind die drt verwalteten Daten nicht mehr erreichbar. (Bei MehrrechnerDBS dagegen kann nach Durchführung bestimmter RecveryAktinen einer der überlebenden Rechner die Daten des ausgefallenen Rechners zeitweilig mitverwalten). Aufgrund der Unabhängigkeit der DBVS können verteilte Deadlcks i.a. nur über einen TimeutMechanismus aufgelöst werden.

3 Nach [10] lassen sich drei Verteilungsfrmen im DCSystem unterscheiden, welche durch verschiedene Verteileinheiten gekennzeichnet sind: (1) Transactin Ruting Hierbei werden ganze Transaktinsaufträge zwischen den Rechnern verteilt. Wird nur diese Verteilfrm unterstützt, d.h. wenn keine weitere Verteilung auf tieferer Ebene (mit feinerem Verteilgranulat) erflgt, muß eine Transaktin vllkmmen auf einem Rechner ausgeführt werden, und es können smit nur die lkal erreichbaren Daten referenziert werden. Diese Verteilfrm setzt daher auch eine Partitinierung der TAP vraus, wbei der TPMnitr die Prgrammzurdnung kennt und smit einen Auftrag an den Rechner weiterleiten kann, w das entsprechende TAP vrliegt. Dennch ist diese Verteilfrm allein nicht ausreichend, da keine echt verteilte Transaktinsausführung erflgt. Transactin Ruting wird u.a. durch die TPMnitre CICS und IMSDC (MSCKmpnente: Multiple Systems Cupling) vn IBM unterstützt. (2) Verteilte Prgrammierung In diesem Fall kann auf entfernte Daten durch Aufruf eines Unter bzw. Teilprgrammes an dem entsprechenden Rechner zugegriffen werden, d.h. die Verteilung erflgt auf Ebene der TAP. Jedes Teilprgramm kann nur lkale Daten eines Rechners referenzieren, wenn keine weitere Verteilung auf tieferer Ebene erflgt, s daß auch hier eine Partitinierung vn (Teil)Prgrammen vrliegt. Ortstransparenz kann i.a. nicht erreicht werden, da für eine verteilte Anwendung die Daten und Prgrammpartitinierung s aufeinander abgestimmt werden müssen, daß die genannte Restriktin erfüllt wird. Zudem werden in existierenden DCSystemen entfernte Unterprgramme (via Remte Prcedure Call) zum Teil anders als lkale aufgerufen. Aufgabe der beteiligten TPMnitre ist die Weiterleitung der entfernten Aufrufe/Antwrten swie die Unterstützung eines verteilten CmmitPrtklles, um die AllesderNichtsEigenschaft der Transaktin zu gewährleisten. Die DBVS sind über die TPMnitre indirekt an einem verteilten Cmmit beteiligt. Verteilte Prgrammierung wird u.a. vn UTM (UTMD) und CICS (Distributed Transactin Prcessing) unterstützt. Sybase bietet im Prinzip auch diese Verteilungsfrm, wenngleich drt die TAP als sgenannte stred prcedures durch das DBVS verwaltet werden. (3) Verteilung vn DMLBefehlen (DBOperatinen) Hierbei werden DMLBefehle vn dem TPMnitr zwischen den Rechnern ausgetauscht, mit der Einschränkung, daß jede DBOperatin nur Daten eines Rechners referenzieren darf (keine Kperatin zwischen den DBVS). Das feinere Verteilgranulat gestattet mehr Flexibilität für externe Datenzugriffe als bei der verteilten Prgrammierung, jedch auf Ksten eines ptentiell höheren Kmmunikatinsaufwandes. Ortstransparenz kann nicht erzielt werden, da bei der Frmulierung der DBOperatinen explizit auf das entsprechende DB Schema Bezug genmmen werden muß (der tatsächliche Ort der Datenbanken kann durch Verwendung lgischer Namen verbrgen werden, nicht jedch die Unterscheidung mehrerer Datenbanken und ihrer Schemata). Operatinen, welche Daten verschiedener Rechner betreffen, müssen explizit ausprgrammiert werden (z.b. JinBerechnung zwischen Relatinen mehrerer Rechner). Wie bei der verteilten Prgrammierung müssen die beteiligten TPMnitre ein verteiltes CmmitPrtkll unterstützen. Die Verteilung vn DMLBefehlen wird u.a. vn CICS (Functin Request Shipping) unterstützt. Verteilung im DBS (hrizntal verteilte MehrrechnerDatenbanksysteme) In diesem Fall erflgt die Kperatin zwischen den DBVS der Rechner. Die DCSysteme der Rechner können unabhängig vneinander arbeiten und verschiedene TPMnitre benutzen. Eine grbe Unterteilung vn MehrrechnerDBS ist in Bild 1 gezeigt. Als primäres Unterscheidungsmerkmale dient dabei die Rechnerzurdnung der Externspeicher (Platten), wbei zwischen Partitinierung ( Shared Nthing, SN) und Sharing ( Shared Disk (SD), DBSharing) unterschieden wird. Im Falle vn SN ist jede Platte nur einem Rechner zugerdnet; die Daten sind entweder ebenfalls partitiniert der repliziert (im Falle der Replikatin bliegt deren Wartung den DBVS). Bei SD kann jeder Rechner und jedes DBVS direkt auf alle Platten und smit die gesamte Datenbank zugreifen. Zwei wei

4 tere Klassifikatinsmerkmale erlauben die Unterscheidung zwischen integrierten und föderativen swie zwischen hmgenen und hetergenen MehrrechnerDBS. MehrrechnerDBS Shared Disk Shared Nthing integriert integriert föderativ hmgen hmgen hmgen hetergen Bild 1: Grbklassifikatin hrizntal verteilter MehrrechnerDatenbanksysteme Integrierte MehrrechnerDBS sind dadurch gekennzeichnet, daß sich alle Rechner eine gemeinsame Datenbank teilen, die durch ein einziges knzeptinelles Schema beschrieben ist. Da dieses gemeinsame Schema vn allen Rechnern unterstützt wird, kann den TAP vlle Ortstransparenz gebten werden; sie können auf die Datenbank wie im lkalen Fall zugreifen. Auf der anderen Seite ist die Autnmie der einzelnen Rechner/DBVS stark eingeschränkt, da Schemaänderungen, Vergabe vn Zugriffsrechten, etc. glbal krdiniert werden müssen. Daneben wird vrausgesetzt, daß jede DBOperatin auf allen Rechnern gleichermaßen gestartet werden kann und daß ptentiell alle DBVS bei der Abarbeitung einer DBOperatin kperieren. Diese Randbedingungen erfrdern i.d.r., daß die DBVS in allen Rechnern identisch (hmgen) sind. Verteilte Datenbanksysteme sind die bekanntesten Vertreter integrierter MehrrechnerDBS; sie gehören zur Kategrie Shared Nthing. Bei ihnen kann die Kperatin innerhalb des DBVS auch auf mehreren Ebenen mit unterschiedlichen Verteilgranulaten erflgen: s können mengenrientierte Teilperatinen, Satz der Seitenanfrderungen zwischen den Rechnern verschickt werden, um auf externe Daten zuzugreifen. Im Gegensatz zu verteilten DCSystemen können bei der Datenzurdnung relativ feine Verteileinheiten gewählt werden (z.b. hrizntale und vertikale Aufteilung vn Relatinen). Die beteiligten Rechner können swhl rtsverteilt als auch lkal verteilt angerdnet sein. Technische Prbleme, die bei diesem Ansatz zu lösen sind, beinhalten die Bestimmung der DBFragmentierung und DBAllkatin, Erstellung verteilter/paralleler Ausführungspläne, verteilte CmmitBehandlung, glbale DeadlckBehandlung swie die Aktualisierung replizierter Datenbanken. Liegt eine Partitinierung der Daten vr, s ergeben sich relativ geringe Freiheitsgrade zur dynamischen Lastbalancierung, da die Datenzurdnung relativ statisch ist und jeder Rechner Zugriffe auf seine Partitin weitgehend selbst bearbeiten muß [13]. DBSharingSysteme [12] ( Shared Disk ) verkörpern eine weitere Klasse integrierter MehrrechnerDBS. Aufgrund der direkten Plattenanbindung aller Rechner ist hierbei keine physische Datenaufteilung unter den Rechnern vrzunehmen. Insbesndere kann eine DBOperatin auch vn jedem Rechner gleichermaßen abgearbeitet werden (keine Erstellung verteilter Ausführungspläne), wdurch eine hhe Flexibilität zur dynamischen Lastbalancierung entsteht. Kmmunikatin zwischen den DBVS wird v.a. zur glbalen Synchrnisatin der DBZugriffe ntwendig. Weitere technische Prbleme betreffen die Behandlung vn Pufferinvalidierungen, Lgging/Recvery swie die Krdinatin vn Lastverteilung und Synchrnisatin [12]. Existierende DBSharingSysteme sind u.a. IMS Data Sharing, DEC s Datenbanksysteme (RDB, VAXDBMS) in der VaxClusterUmgebung swie Oracle V6.2. Föderative MehrrechnerDBS streben nach größerer Kntenautnmie im Vergleich zu den integrierten Systemen, wbei die beteiligten DBS entweder hmgen der hetergen sein können. Aufgrund der häufig gefrderten gegraphischen Verteilung des Systems swie der möglichst weitgehenden Rechnerunabhängigkeit kmmt zur Realisierung dieser Systeme nur eine Partitinierung der Externspeicher in Betracht (Shared Nthing). Kennzeichnende Eigenschaft der föderativen DBS ist, daß (ähnlich wie bei den verteilten DCSystemen) jeder Rechner eine eigene Datenbank verwaltet, die durch ein lkales (privates) knzeptinelles Schema beschrieben ist. Allerdings sll jetzt durch eine begrenzte Kperatin der DBVS es möglich werden, über das DBVS auf bestimmte Daten anderer

5 Rechner zuzugreifen, falls dies vn dem Besitzer der Daten zugelassen wird. Ein Realisierungsansatz hierzu sieht vr, daß jeder Rechner Teile seines knzeptinellen Schemas exprtiert und smit externe Zugriffe auf die betreffenden DBBereiche zuläßt. Im Idealfall kann Ortstransparenz für die Benutzer (TAP) durch Definitin integrierter externer Schemata (Sichten) erreicht werden, wbei das DBVS dann eine autmatische Abbildung auf das lkale knzeptinelle Schema swie die imprtierten Schemafragmente anderer Rechner vrnimmt und für rechnerübergreifende Operatinen (z.b. Jins) eine geeignete Anfragezerlegung ausführt. Allerdings ergeben sich bei der Schemaintegratin bereits im Fall hmgener DBVS (mit gleichem DBMdell und Anfragesprache) vielfach semantische Abbildungsprbleme, welche nicht autmatisch aufgelöst werden können [14]. Aufgrund der Änderungsprblematik auf Sichten wird auch ft nur lesender Zugriff auf externe Daten unterstützt. Weitere technische Prbleme betreffen v.a. die Unterstützung hetergener Datenmdelle und Anfragesprachen swie die Krdinierung unterschiedlicher Methden zur Transaktinsverwaltung in den beteiligten Rechnern. Ingres/Star repräsentiert ein kmmerziell verfügbares föderatives MehrrechnerDBS [2]. Eine weitergehende Klassifizierung integrierter MehrrechnerDBS findet sich in [7]. Unterschiedliche Realisierungsfrmen föderativer DBS werden in [1] gegenübergestellt. Verteilung im DCSystem und im DBS Die angesprchenen Verteilfrmen im DCSystem und im DBS lassen sich zum Teil kmbinieren, wdurch sich i.d.r. größere Freiheitsgrade bezüglich der Last, Prgramm und Datenverteilung ergeben, jedch auf Ksten einer erhöhten Kmplexität. Auch lassen sich einige Nachteile verteilter DCSystem beseitigen, wenn zusätzlich ein MehrrechnerDBS eingesetzt wird (z.b. können durch Verwendung eines Verteilten DBS Ortstransparenz swie feine Verteileinheiten bei der Datenzurdnung unterstützt werden). Bei Einsatz eines MehrrechnerDBS erscheint ein zusätzliches Transactin Ruting zur Lastverteilung generell sinnvll, um damit einen Transaktinsauftrag einem Rechner zuzuweisen, der nicht überlastet ist und bei dem eine effiziente Ausführung erwartet werden kann (und auf dem das zugehörige TAP ausführbar ist). Im Zusammenhang mit DBSharing erscheinen dagegen die Verteilfrmen auf Ebene der Teilprgramme und DMLBefehle nicht sinnvll, da jeder Rechner auf die gesamte Datenbank zugreifen kann. Tandem unterstützt mit dem TPMnitr Pathway swie dem verteilten DBS NnStp SQL eine spezielle Verteilung auf Teilprgrammebene swie eine verteilte und parallele Anfragebearbeitung im DBVS. Vergleichende Bewertung In Bild 2 sind für einige der angesprchenen Architekturfrmen hrizntal verteilter Transaktinssysteme die qualitativen Bewertungen zur Erleichterung des Vergleichs zusammengefaßt. Man erkennt, daß für jede Verteilfrm Vr und Nachteile hinsichtlich der angeführten Bewertungskriterien bestehen, s daß es (wie zu erwarten) keinen idealen Typ eines verteilten Transaktinssystemes gibt. S liegen die Vrteile verteilter DCSysteme in der vergleichsweisen einfachen Realisierbarkeit swie der Unterstützung einer hhen Kntenautnmie und hetergener Datenbanken, die gegraphisch verteilt vrliegen können. Die integrierten MehrrechnerDBS vm Typ SN und SD dagegen erlauben eine einfache Erstellung der Anwendungen (Ortstransparenz) und bieten die größten Freiheitsgrade bezüglich der Last, Prgramm und Datenzurdnung swie der Nutzung vn Parallelität innerhalb einer Transaktin. Diese Ansätze sind daher auch hinsichtlich der Unterstützung hher Leistungsanfrderungen zu bevrzugen, insbesndere bei lkaler Rechneranrdnung (schnelles Kmmunikatinsmedium). Weiterhin können dabei Rechnerausfälle durch geeignete RecveryMaßnahmen der DBVS am ehesten für den Benutzer transparent gehalten werden. Föderative DBS liegen bei der Bewertung zwischen den verteilten DCSystemen und den integrierten MehrrechnerDBS. 3. Vertikal verteilte Transaktinssysteme Vertikal verteilte Transaktinssysteme sind durch eine Partitinierung der Systemfunktinen auf FrntEnd und BackEndRechner gekennzeichnet, welche gemäß einer Client/ServerBeziehung kperieren. Bekannteste Vertreter dieser Systemklasse sind Wrkstatin/ServerSysteme, bei denen gewisse Funktinen zur Transaktinsver

6 Verteilung (nur) im DCSystem Prgrammebene DMLEbene Verteilung im DBS föderative DBS SN SD DBSKmplexität Ortstransparenz Replikatinstransparenz / n.a. Einfachheit d. Prgrammierung Flexibilität bezüglich / Datenallkatin Prgrammzurdnung Lastbalancierung / / n.a. gegraphische Verteilung Kntenautnmie DBSHetergenität Verfügbarkeit der Daten Nutzung vn IntraTAParallelität / Bild 2: Qualitative Bewertung hrizntal verteilter Transaktinssysteme arbeitung auf Wrkstatins vrgelagert werden, swie DBMaschinen, bei denen eine Auslagerung der DBVerarbeitung auf BackEndRechner erflgt. In beiden Fällen sll eine Entlastung der allgemeinen Verarbeitungsrechner swie eine Steigerung der Ksteneffektivität durch verstärkten Einsatz preiswerter (jedch leistungsfähiger) Mikrprzessren erflgen. Für die genannten Systemarchitekturen sprechen daneben weitere Gründe, auf die hier jedch nicht näher eingegangen werden sll. Analg zu den hrizntal verteilten Transaktinssystemen ergeben sich bei der Partitinierung der Funktinen mehrere Verteilmöglichkeiten im DCSystem und DBS, welche unterschiedliche Verteilgranulate mit sich bringen. Im einfachsten Fall liegt eine Kperatin der FrntEnd (FE)Rechner mit nur einem BackEnd (BE)Rechner der Server vr; bei mehreren ServerRechnern können diese entweder unabhängig vneinander arbeiten der kperieren. In letzterem Fall würde das ServerSystem wiederum ein hrizntal verteiltes Transaktinssystem repräsentieren, was die Orthgnalität der beiden Klassifikatinsmerkmale verdeutlicht. S ist z.b. bei DBMaschinen das BackEndSystem in der Regel ein integriertes MehrrechnerDBS (derzeit meist vm Typ SN). Verteilung im DCSystem Bei der Partitinierung im DCSystem werden gewisse Funktinen des TPMnitrs bzw. die Anwendungsprgramme auf FrntEndRechner vrgelagert. Generell ist mit einer Verkmplizierung der Systemadministratin zu rechnen, da nun eine Zurdnung vn Systemfunktinen und TAP auf eine ptentiell sehr grße Anzahl vn Frnt EndStatinen zu verwalten ist (replizierte Speicherung vn Maskendefinitinen, TPMnitrFunktinen und TAP, s daß Änderungen entsprechend prpagiert werden müssen). Ähnlich wie bei den hrizntal verteilten DC Systemen können drei Partitinierungsmöglichkeiten im DCSystem unterschieden werden [6]: (1) Vrlagerung der Nachrichtenaufbereitung Eine erhebliche Entlastung der Server ergibt sich bereits, wenn Benutzereingaben direkt vr Ort analysiert werden (durch intelligente Terminals, PCs der Wrkstatins) und in ein neutrales, geräteunabhängiges Nachrichtenfrmat überführt werden, das vn den TAP auf den Servern verarbeitet werden kann. Umgekehrt sllen Ausgabenachrichten beim Benutzer in das gerätespezifische Frmat überführt werden. Einfache Eingabefehler (z.b. Verletzung vn in der Maskendefinitin spezifizierten Wertebereichsbeschränkungen) können sfrt abgewiesen werden, hne daß eine Übertragung an den Server erflgen muß. Die Ausführung der TAP erflgt bei diesem Ansatz weiterhin auf dem Server, d.h. die Einheit der Verteilung

7 ist der gesamte Transaktinsauftrag (wie beim Transactin Ruting). Erflgt auf den Servern keine weitere (hrizntale der vertikale) Verteilung, s ist die Transaktinsausführung auf Daten eines Rechners beschränkt. (2) Aufruf vn Teilprgrammen auf den Servern (Remte Prcedure Call) Bei dieser Partitinierungsfrm werden TAP zum Teil auf den FERechnern (z.b. PCs, Wrkstatins) ausgeführt, s daß diese weitergehend als unter (1) genutzt werden können. Allerdings können die FETAP nicht unmittelbar mit den ServerDBVS kmmunizieren, sndern müssen Teilprgramme auf den Servern starten, um die drt erreichbaren Daten zu referenzieren. Eine TPMnitrKmpnente auf den FERechnern ist für die Abwicklung der Remte Prcedure Calls zuständig, wbei prinzipiell Funktinen mehrerer unabhängiger und hetergener Server innerhalb eines FETAP und damit innerhalb einer Transaktin aufgerufen werden können. In diesem Fall muß ein verteiltes CmmitPrtkll zwischen dem TPMnitr auf dem FERechner und den TPMnitren der invlvierten ServerRechner erflgen. Da PCs der Wrkstatins als FERechner als unzuverlässig einzustufen sind, sllte jedch die Rlle des CmmitKrdinatrs vm FE auf einen der ServerRechner übertragen werden. Die Bewertung des Ansatzes entspricht im wesentlichen der der verteilten Prgrammierung bei hrizntaler Verteilung. Vn Nachteil ist die relativ geringe Flexibilität für die TAPErstellung auf FESeite, da nur über ServerTAP auf die Datenbanken zugegriffen werden kann. Diese Zugriffsfrm wird u.a. vn Sybase und Camelt unterstützt. (3) Ausführung vn DMLBefehlen auf den Servern Hierbei werden die TAP vllständig auf den FERechnern ausgeführt und DMLBefehle zur Ausführung an die Server verschickt. Gegenüber (2) ergeben sich smit größere Freiheitsgrade für die DBZugriffe, jedch auch ein i.a. weit höherer Kmmunikatinsaufwand, da jede Operatin einzeln verschickt werden muß. Weiterhin muß die Schemainfrmatin der ServerDatenbanken auf den FERechnern bekannt sein, und es ist eine aufwendige Definitin vn Zugriffsrechten erfrderlich (an Schemabjekte und DBOperatinen gebunden). Sll auf Daten mehrerer (unabhängiger) Server zugegriffen werden, sieht der Prgrammierer mehrere Schemata. Wie bei (2) ist in diesem Fall ein verteiltes CmmitPrtkll durch die TPMnitre zu unterstützen. Die einfachste Realisierungsfrm (Kperatin mit einem Server) wird vn vielen relatinalen DBVS unterstützt (Oracle, Ingres, Sybase,...). Einige Systeme (z.b. Ingres) erlauben bereits den Zugriff auf mehrere, hetergene Server/DBVS, wbei derzeit Unterschiede in den Anfragesprachen, Datenmdellen, Zeichendarstellungen, etc. durch Gateways überbrückt werden. Ein Teil des enrmen Knvertierungsaufwandes sll durch standardisierte Prtklle wie RDA (Remte Database Access) [8] eliminiert werden. DBMaschinen fallen auch in diese Verteilkategrie, wbei hier die TAP i.a. auf allgemeinen Verarbeitungsrechnern ( Hsts ) der auf Wrkstatins ablaufen. Innerhalb des BackEndSystems sllen v.a. kmplexere DBOperatinen durch Parallelverarbeitung effizient abgearbeitet werden. Beispiele vn DBMaschinen sind Teradatas DBC/1024 swie Prttypen wie Gamma der EDS. Verteilung im DBS (vertikal verteilte MehrrechnerDBS) Eine weitere Verteilungsmöglichkeit besteht darin, die Anwendungen vllkmmen auf den FERechnern auszuführen und die DBVerarbeitung zwischen FE und BERechnern zu partitinieren. Diese Realisierungsfrm wird derzeit v.a. vn sgenannten NnStandardDBS bzw. bjektrientierten DBS verflgt, wbei durch eine möglichst weitgehende Auslagerung der DBVerarbeitung auf Wrkstatins ein gutes Antwrtzeitverhalten für die kmplexen Anwendungsvrgänge in diesen Bereichen (z.b. CAD) angestrebt wird. Insbesndere sllen DBObjekte nach Bereitstellung durch die Server möglichst im Hauptspeicher der Wrkstatin gepuffert werden (in einem vm WrkstatinDBVS verwalteten Objektpuffer), um durch Ausnutzung vn Lkalität eine hhe Zugriffsgeschwindigkeit zu erzielen. Wie in [3, 4] näher ausgeführt, kmmen für die Kperatin zwischen Wrkstatin und Server DBVS wiederum verschiedene Ebenen mit unterschiedlichen Verteileinheiten in Betracht. Vertikale Verteilung über mehr als zwei Ebenen Eine vertikale Verteilung vn Systemfunktinen ist nicht auf zwei Ebenen beschränkt, sndern kann über mehrere Stufen erflgen. Z.B. ist die DCVerarbeitung auf drei Ebenen aufgeteilt, wenn eine lkale Nachrichtenaufbereitung auf PCs der Wrkstatins erflgt, eine Verteilung der Transaktinsaufträge (Transactin Ruting) auf Kmmunikatinsrechnern durchgeführt wird und die TAPAbarbeitung auf allgemeinen Verarbeitungsrechnern erflgt; die DBVerarbeitung könnte dann auf einer weiteren ServerEbene vrgenmmen werden, z.b. im Rahmen einer DBMaschine. Die DBVerarbeitung könnte auch über mehrere Stufen partitiniert werden (z.b. zwischen WrkstatinDBVS, abteilungsspezifischen DBServern und einem zentralen DBServer eines Unternehmens).

8 Vergleich Für die Transaktinsverarbeitung in knventinellen Anwendungen kmmen v.a. die Verteilfrmen 2 und 3 im DCSystem in Betracht, für die sich eine weitgehend ähnliche Bewertung wie bei den hrizntal verteilten DCSystemen ergibt (Bild 2). Im allgemeinen ist es wünschenswert, beide Zugriffsfrmen zu unterstützen, was auch vn einigen existierenden Systemen getan wird (z.b. Sybase). Vertikale Verteilungsebene zentraler DBServer (bzw. islierte Server) Mehrrechner DBS 4 Architekturen 3 2 verteilte TPMnitre DBMaschinen FE/BE zentralisierte Transaktinssysteme Hrizntale Verteilungsebene 0 = keine Kperatin 1 = Verteilung auf Transaktinsebene 2 = Aufruf entfernter Teilprgramme (remte prcedure call) 3 = Verschicken vn DBOperatinen 4 = Kperatin zwischen DBVS (Verschicken vn Teilperatinen, Satz/Seitenanfrderungen, Sperranfrderungen,...) Bild 3: Kmbinatin hrizntal und vertikal verteilter Transaktinssysteme hrizntal verteilte Transaktinssysteme Kmbinatin vn hrizntaler und vertikaler Verteilung Wie schn erwähnt, können hrizntale und vertikale Verteilfrmen miteinander kmbiniert werden. Das sich dabei ergebende Spektrum verteilter Transaktinssysteme ist in Bild 3 verdeutlicht. Dabei werden swhl bei hrizntaler als auch vertikaler Verteilung die drei eingeführten Verteilebenen im DCSystem unterschieden (Verteilung ganzer Transaktinsaufträge, vn Teilprgrammen der DMLBefehlen) swie als vierte Möglichkeit die Verteilung im DBVS (MehrrechnerDBS). Bei hrizntaler Verteilung wurde eine zusätzliche Verteilebene 0 vrgesehen, die den Fall abdeckt, wenn nur ein einziger Verarbeitungsrechner (Server) bzw. mehrere unabhängige Server vrliegen. (Analg könnte man eine vertikale Verteilebene 0 einführen, welche impliziert, daß die Transaktinen vllständig auf dem FERechner abgearbeitet werden). Zentralisierte Transaktinssysteme sind daher durch die Verteilkmbinatin (0,1) gekennzeichnet, als vertikale Verteilung vn ganzen Transaktinsaufträgen (Ebene 1) und keine hrizntale Verteilung. Die in Kap. 2 diskutierten Frmen hrizntal verteilter Systeme entsprechen den Kmbinatinen (1,1) bis (4,1), während die Kmbinatinen (0, 1) bis (0,4) den (nur) vertikal verteilten Systemen entsprechen. Die verbleibenden sechs Kmbinatinen repräsentieren die Systemarchitekturen, bei denen swhl eine vertikale als eine hrizntale Verteilung vrliegt. Dabei ist zu berücksichtigen, daß das hrizntale Verteilgranulat stets kleiner der gleich der vertikalen Verteileinheit sein muß. Wenn als etwa vn den FERechnern

9 DMLBefehle auf den Servern aufgerufen werden, s können drt keine gröberen Granulate wie Teilprgramme der ganze Transaktinsaufträge mehr verteilt werden. DBMaschinen werden durch die Kmbinatin (4, 3) repräsentiert, als vertikale Übergabe vn DBOperatinen und hrizntale Aufteilung innerhalb eines Mehrrechner DBS. Die kmplexeste Realisierung eines verteilten Transaktinssystems liegt vr, wenn swhl eine vertikale als eine hrizntale Kperatin zwischen DBVS durchgeführt wird (Kmbinatin (4,4)). Existierende Systeme bieten ft mehrere Frmen einer verteilten Transaktinsverarbeitung an. Sybase unterstützt z.b. die Kmbinatinen (0, 2), (0, 3) und (2, 2). Dies bedeutet, man kann vn Wrkstatins aus entweder Teilprgramme der DMLBefehle auf den Servern starten; zusätzlich können innerhalb eines ServerTeilprgrammes Teilprgramme anderer Server aufgerufen werden. 4. Zusammenfassung Es wurde ein allgemeines Klassifikatinsschema für verteilte Transaktinssysteme vrgestellt, das mächtiger als bisherige Klassifikatinsansätze [5, 6, 7, 9, 10] ist und einen weitergehenden Vergleich verschiedener Systemarchitekturen unterstützt. Es wurde unterschieden zwischen hrizntaler Replikatin und vertikaler Partitinierung vn Systemfunktinen swie verschiedenen Verteilungsebenen innerhalb des DCSystems und des DBVS. Erstmalig wurden auch verschiedenste Kmbinatinsmöglichkeiten der Verteilung systematisiert. Bei der Beurteilung der Architekturfrmen wurde u.a. auf die Implikatinen für die Allkatin vn Transaktinsprgrammen, Daten und Lasteinheiten eingegangen. Das vrgestellte Klassifikatinsschema kann bei Bedarf verfeinert werden. Z.B. sind für einzelne Systemklassen wie föderative DBS, DBMaschinen der Wrkstatin/ServerDBVS weitergehende Unterscheidungen möglich, wie sie in der Literatur bereits diskutiert wurden. Die Betrachtung der verschiedenen Ansätze verdeutlichte, daß keine der Systemarchitekturen alle eingangs genannten Anfrderungen gut erfüllen kann. Deshalb gibt es auch keine ptimale Verteilfrm, wie gelegentlich suggeriert wird, sndern es wird weiterhin eine Kexistenz verschiedener Architekturansätze und Kperatinsfrmen zur verteilten Transaktinsverarbeitung geben. S werden Frderungen nach hher Kntenautnmie, gegraphischer Verteilung und Unterstützung hetergener Datenbanken am besten durch verteilte DCSysteme der föderative DBS erfüllt (s. auch [2]). Integrierte MehrrechnerDBS bieten dagegen Vrteile hinsichtlich Ortstransparenz, einfacher Anwendungsprgrammierung und Datenverfügbarkeit. Frderungen nach hher Leistungsfähigkeit werden am ehesten vn lkal gekppelten MehrrechnerDBS erfüllt, w ein schnelles Kmmunikatinsmedium genutzt werden kann und die besten Möglichkeiten zur Parallelisierung kmplexer Anfragen und einer dynamischen Lastbalancierung bestehen. Die Vrlagerung vn DCFunktinen auf PCs der Wrkstatins wird zunehmend an Bedeutung gewinnen, da sie bessere Benutzerberflächen und eine verbesserte Ksteneffektivität ermöglicht. 5. Literatur [1] Special Issue n Hetergeneus Databases. ACM Cmputing Surveys 22 (3), (1990) [2] Butsch, K., Rahm, E.: Architekturansätze zur Unterstützung hetergener Datenbanken. Univ. Kaiserslautern, FB Infrmatik (1991) [3] Deppisch, U. et al.: Überlegungen zur DatenbankKperatin zwischen Server und Wrkstatins. Prc. 16. GIJahrestagung, InfrmatikFachberichte 126,SpringerVerlag, (1986) [4] DeWitt, D.J., Futtersack, P., Maier, D., Velez, F.: A Study f Three Alternative WrkstatinServer Architectures fr Object Oriented Database Systems. Prc. 16th VLDB cnf., (1990) [5] Effelsberg, W.: Datenbankzugriff in Rechnernetzen. Infrmatinstechnik 29 (3), (1987) [6] Härder, T., MeyerWegener, K.: Transaktinssysteme in Wrkstatin/ServerUmgebungen. Infrmatik Frschung und Entwicklung 5, (1990) [7] Härder, T., Rahm, E.: MehrrechnerDatenbanksysteme für Transaktinssysteme hher Leistungsfähigkeit. Infrmatinstechnik 28 ( 4), (1986) [8] Lamersdrf, W.: Remte Database Access: Kmmunikatinsunterstützung für Fernzugriff auf Datenbanken. InfrmatikSpektrum (Das aktuelle Schlagwrt) 14 (3), , (1991)

10 [9] Leff, A., Pu, C.: A Classificatin f Transactin Prcessing Systems. IEEE Cmputer, 6376 (June 1991) [10] MeyerWegener, K.: Transaktinssysteme verteilte Verarbeitung und verteilte Datenhaltung. Infrmatinstechnik 29 (3), (1987) [11] MeyerWegener, K.: Transaktinssysteme. TeubnerVerlag (1988) [12] Rahm, E.: Der DatabaseSharingAnsatz zur Realisierung vn HchleistungsTransaktinssystemen, InfrmatikSpektrum 12 (2), 6581 (1989) [13] Rahm, E.: A Framewrk fr Wrklad Allcatin in Distributed Transactin Prcessing Systems. ZRIBericht 13/89, Univ. Kaiserslautern, erscheint in: The Jurnal f Systems and Sftware (1992). [14] Schek, H.J., Weikum, G.: Erweiterbarkeit, Kperatin, Föderatin vn Datenbanksystemen. Prc. BTW91, InfrmatikFachberichte 270, SpringerVerlag, 3871 (1991)