Hohe Performance und Skalierbarkeit von verteilten
Werbung
Hohe Performance und Skalierbarkeit von verteilten Anwendungen • Unterstützung heterogener Netzwerke, • flexible Gestaltung der Datenhaltung (lokal/remote gemischt), • minimaler Konfigurationsaufwand, • automatischer Systembetrieb einschließlich Recovery. Bernhard Röhrig Hohe Performance und Skalierbarkeit von verteilten Anwendungen mit dem Enterprise Cache Protocol (ECP) Datenbanksysteme mit vielen tausend Benutzern werden meist in verteilten Serverlandschaften betrieben, um zufrieden stellende Antwortzeiten zu gewährleisten. Besonders bei Web-Anwendungen ist oft nicht vorherzusagen, für welche Transaktionslast das Gesamtsystem ausgelegt sein muss. Performance und Skalierbarkeit sind deshalb neben der Sicherheit die Hauptanforderungen an ein solches System. Das Enterprise Cache Protocol (ECP) der Firma InterSystems liefert hierfür eine Lösung. Es setzt auf das TCP/ IP-Protokoll auf und bietet Strategien zum Daten- und Objekt-Caching an. 1 Einführung Das Enterprise Cache Protocol (ECP) ist ein Transaktionsprotokoll für verteilte Datenbanken als Bestandteil des DBMS Caché der Firma InterSystems, das aktuell in der Version 5 vorliegt [InterSystems 2003]. Es dient dazu, die Performance in verteilten Systemen zu erhöhen, und bietet sich für Thin-Client-Architekturen an, die heute vielfach im Einsatz sind. Die Wirkungsweise des ECP zeigt Abbildung 1: Fordert ein Client eine Information aus der Datenbank an, versucht der Applikationsserver, die Anfrage aus seinem lokalen Cache zu bedienen. Ist dies nicht möglich, wird die Information vom zentralen Datenserver abgerufen. Zusätzlich zu den aktuell verlangten Daten liefert der Datenserver weitere Informationen, die wahrscheinlich als nächste benötigt werden. Auch diese werden im Cache des Applikationsservers abgelegt und stehen dort für Anforderungen aller angeschlossenen Clientrechner zur Verfügung. Dies senkt die Netzlast und verkürzt Reaktionszeiten des Gesamtsystems. Bei der Entscheidung, welche Daten mit Wahrscheinlichkeit im nächsten Verarbeitungsschritt verlangt werden, hilft die objektorientierte Struktur der CachéDatenbank: Datenbeziehungen werden intern realitätsnah in Form von Objekten abgebildet und in multidimensionalen Arrays gespeichert. Ein Datenobjekt ent- Datenbank-Spektrum 7/2003 hält alle Informationen über ein Objekt der Realität, die nicht erst aus verschiedenen »flachen« Tabellen zusammengesetzt werden müssen. Damit reduziert sich die Zahl der Lese- und Schreibvorgänge auf dem Einzelrechner und der Transportvorgänge im Netz [Kirsten & Ihringer 2002]. Neben der reinen Bereitstellung von Daten kümmert sich ECP darum, die Konsistenz des Caches auf dem lokalen Applikationsserver zu gewährleisten und Änderungen an den Datenserver zurückzuliefern. Erfahrungsgemäß verwenden Clients oft Daten, die auf der mittleren Schicht der 3-Tier-Architektur zwischengespeichert sind. Daraus ergeben sich ein Performance-Vorteil gegenüber Direktzugriffen auf den zentralen Datenserver und eine bessere Skalierbarkeit, insbesondere durch Reduzierung der benötigten Netzbandbreite. Im Einzelnen zeichnet sich ECP durch folgende Merkmale aus: • verteilte Netzwerk-Zwischenspeicher, • Datenbank-Blockgrößen von 8 KB, • robuste Transportschicht (TCP/IP), 2 Die Architektur von Caché und ECP Das mit Caché-Version 5.0 eingeführte ECP ist eine Weiterentwicklung von DCP, dem Distributed Cache Protocol früherer Caché-Versionen, und baut auf den langjährigen Erfahrungen auf, die mit diesem Protokoll gesammelt wurden [InterSystems 2002]. Wie sein Vorgänger ist es fest in das Caché-DBMS integriert, so dass zu seinem Einsatz keine besonderen Entwicklungs-, Kodierungs- und Implementierungsarbeiten erforderlich werden. Es sind lediglich einige Konfigurationseinstellungen an den Datenbankservern der verteilten Struktur vorzunehmen. Diese Verfahrensweise besitzt eine Reihe von Vorzügen: • Anwendungen sind aus funktionaler Sicht beliebig skalierbar, da am Programmcode keine Änderungen vorgenommen werden müssen. Ein und dieselbe Anwendung lässt sich sowohl auf einem PC als auch auf großen Mehrrechnersystemen einsetzen, unabhängig von den Betriebssystemen, unter denen die einzelnen Stationen betrieben werden. Datenserver Datenbank (Caché) Applikationsserver Applikationsserver lokaler Cache lokaler Cache Thin Clients (Webbrowser) Thin Clients (Webbrowser) Abb. 1: ECP verwaltet Daten in einer 3-Tier-Architektur 13 Hohe Performance und Skalierbarkeit von verteilten Anwendungen • Auch aus der Sicht des Datendurchsatzes und der Anzahl möglicher, konkurrierender Benutzerzugriffe ergeben sich bemerkenswerte Leistungssteigerungen durch das verteilte Caching, wie verschiedene Untersuchungen (z.B. [Epic 2002]) belegen. • Außerdem vereinfacht sich der Entwicklungsprozess. Der Programmierer muss sich nicht um Details der Netzinfrastruktur und der Skalierung auf größere Serverlandschaften kümmern, da diese Prozesse für ihn transparent vom ECP abgewickelt werden. • Hinzu kommt eine gesteigerte Zuverlässigkeit. Die meisten Laufzeitprobleme, wie Ausfälle einzelner Server, werden von ECP abgefangen und automatisch bearbeitet, ohne dass ein Administrationseingriff erforderlich wird. Das Prinzip ist einfach: ECP bietet die Möglichkeit, Daten und ausführbaren Code auf verteilten Caché-Systemen gemeinsam zu nutzen. Speicherung, Transaktionssteuerung und Locking erfolgen zentral, jedoch werden aktuelle Kopien der gelieferten Daten lokal auf verteilten Applikationsservern gehalten, die somit Cache-Funktionen erfüllen. Für das Verständnis des Wirkprinzips ist es nützlich, die Konzepte zu kennen, nach denen in Caché Daten physisch und logisch verwaltet werden. 2.1 Datenspeicherung in Caché Caché ist wie andere DBMS in der Lage, eine Vielzahl unterschiedlichster Informationen abzuspeichern und zu verwalten. Hierbei sind die Möglichkeiten nicht auf rein numerische und alphanumerische Daten sowie BLOBs (Bilder, Klänge, Videoclips usw.) beschränkt. Vielmehr lassen sich auch hierarchisch strukturierte Informationen und darüber hinaus Programmcode zur Umsetzung von Geschäftslogik in der Datenbank ablegen. Umgesetzt wird dies in einer Unified Data Architecture, beschrieben in [Lutz 2002] und anderen Veröffentlichungen (siehe Abb. 2). Diese vom Hersteller InterSystems als postrelational bezeichnete Technik erlaubt es, Daten sowohl für SQL- als auch für objektorientierte Zugriffe auf der Basis einer einheitlichen Speichertechnologie zur Verfügung zu stellen. Speicherung, Verwaltung und Auswertung der Daten sind mit gängigen 14 Java EJB ActiveX .NET C++ CSP SOAP ODBC JDBC XML SQL Objekte Basic Caché Object Script Klassenbibliothek SQLGateway Multidimensionale Caché Data Engine ActiveXGateway Caché-Server Abb. 2: Die Unified Data Architecture von Caché mit Programmierschnittstellen Programmiersprachen beschreibbar, unabhängig vom jeweils vorherrschenden Paradigma (vgl. [Reichelt 2003], [Kaluzova & Manasova 2003]). Die logische Speicherung erfolgt in multidimensionalen Arrays, die beide Zugriffsarten sowie auch den Direktzugriff gestatten [Kirsten et al. 2003]. Als Programmiersprachen für CachéApplikationen kommen objektorientierte wie Java und C++ zum Einsatz oder mittels ODBC und JDBC angebundenes SQL, das in beliebige andere Sprachen eingebettet sein kann. Für die Formulierung von Methodencode finden das proprietäre, jedoch in der Anwendung sehr effektive Caché Object Script (kleine Beispiele u.a. in [Röhrig 2003]) und alternativ seit der Version 5 ein von InterSystems implementierter Basic-Dialekt Verwendung. Die Definition von Objektklassen erfolgt in XML. Intern werden die Daten in Blöcken zu je 8 KB verwaltet. Ein Datenblock enthält dabei einen so genannten Global. Der Begriff bezeichnet den Inhalt einer multidimensionalen, globalen Variablen. Dieser repräsentiert ein Datenobjekt als Instanz einer Objektklasse (evtl. in Kombination mit weiteren Globals z.B. bei Streams). Aus SQL-Sicht entspricht das meist einer Tabellenzeile, wobei die Möglichkeiten von Caché darüber hinausgehen; als Eigenschaften eines solchen Objekts sind außer Literalen auch Listen, Arrays und sogar andere Objekte zugelassen, also ihrerseits strukturierte Daten. Überschreitet der Inhalt eines Globals die Blockgröße von 8 KB, werden mehrere Blöcke verwendet. Die Organisation der Globals erfolgt in Form von B*-Bäumen (Näheres in [Härder & Rahm 1999]). Im Unterschied zur allgemeinen Form von B-Bäumen verweist bei einem B*-Baum jeder Schlüssel eines Zeigerblocks niedrigster Ebene direkt auf einen Datenblock, der den gesuchten Datensatz enthält [Kirsten et al. 2003]. Hierdurch wird die Integration von Schlüssel- und Datenbereichen in einer einheitlichen Speicherstruktur ermöglicht. B*-Bäume enthalten verschiedene Arten von Blöcken: einen Verzeichnisblock an der Spitze, einen oder mehrere Zeigerblöcke und auf der untersten Ebene Datenblöcke, die die eigentliche Information repräsentieren. Neben reinen Daten lässt sich zu den Objekten bzw. Objektklassen auch ausführbarer Programmcode (»Methoden«) speichern, die Caché-Routinen. Die Routinen werden ebenfalls in Form von Globals verwaltet. Damit entfällt eine gesonderte Middleware, die bei der klassischen 3-Tier-Architektur erforderlich wäre [Binder 2003]; die Geschäftslogik integriert sich nahtlos in den Datenbankserver. 2.2 Datenbanken und Namespaces Die Daten- oder Codeblöcke speichert Caché in Datenbankdateien im Verzeichnisbaum des Betriebssystems. Jedes Caché-System verfügt über mehrere System- und benutzereigene Datenbanken. Dieser physischen Speicherungsform überlagert ist das Konzept der logischen Namespaces. Caché-Anwendungen greifen auf die bereitgestellten Daten stets über einen Namespace zu. Abbildung 3 gibt einen Überblick über die Zusammenhänge. Datenbank-Spektrum 7/2003 Hohe Performance und Skalierbarkeit von verteilten Anwendungen Globals (Daten) Routinen (Programmcode) Namespace (logische Sicht) Datenbankserver RAM Datenbankdateien Festplatte DatenbankCache Dateisystem des Betriebssystems solange keine Updates auf das zentral vorliegende Directory erfolgen. Als vorteilhaft erweist sich die beschriebene Technik in verteilten Strukturen, da sich durch Reduzierung der erforderlichen Netzzugriffe die Netzbelastung verringert, die zur Verfügung stehende Bandbreite erhöht und natürlich auch die Reaktionszeiten des Gesamtsystems verkürzen. Darüber hinaus können durch geeignete Defnition von Namespaces Daten und Programmcode intelligent im Netz verteilt und immer dort angeordnet werden, wo sie im Interesse einer hohen Performance am besten aufgehoben sind. Näheres zur Verfahrensweise enthält Abschnitt 3.2 des Artikels. 2.4 ECP-Clients und -Server Äußerlich unterscheidet sich eine ECPKonfiguration nicht von klassischen verAbb. 3: Das Zusammenspiel von Datenbanken, Namespaces und lokalem Cache in einem Caché-System teilten DBS oder 3-Tier-basierten Strukturen. Sie besteht aus einer Anzahl von Ein Namespace ist ein Arbeitsbereich, schnelle Reaktionszeiten des lokalen SysCaché-Systemen, die über TCP/IPin dem Daten und Programmcode logisch tems. Da es sich um Shared Memory hanStacks miteinander kommunizieren und zusammengefasst sind. Bei der Definition delt, stehen die gecachten Globals allen als ECP-Server oder -Clients agieren. eines Namespace durch den DB-Admi- Prozessen auf derselben Maschine zur ECP-Server entsprechen dem Datennistrator wird angegeben, welche Daten Verfügung, nicht nur dem Client, der sie server in Abbildung 1, ECP-Clients den und Programme sich in welcher Daten- angefordert hat. Applikationsservern. Im Unterschied zur bank befinden. Diese Art der GruppieGegenüber einem rein relationalen klassischen 3-Tier-Architektur handelt es rung wird vom Hersteller als Global Map- DBS wird eine zusätzliche Leistungssteisich jedoch nicht um unterschiedliche ping bezeichnet [Kirsten et al. 2003]. gerung dadurch erzielt, dass die Speiche- Software. Vielmehr sind alle diese SysteDer Namespace bietet eine logische rung der Daten generell objektbezogen, me jeweils mit einem Caché-5-Server beSicht auf die Globals und Routinen, die in also realitätsnah erfolgt. Somit ist auch stückt. Der Unterschied liegt lediglich in einer oder mehreren physischen Daten- bei komplizierteren Objekten mit einem der Konfiguration [InterSystems 2002]. banken gespeichert sind, und entkoppelt Lesevorgang gleich das ganze Objekt im Aufgrund der gleichen Softwareausso die Applikationen vom darunter lie- Shared Memory präsent, während die Dastattung kann ein Caché-System auch genden Betriebssystem und dessen Da- ten in einem RDBMS aus verschiedenen gleichzeitig als ECP-Client und ECP-Sertenspeicherungs-Mechanismen. Dies un- Tabellen – und damit auch Speicherblö- ver fungieren. terstützt sowohl die Migration auf eine cken auf dem externen Medium – zusamDefinition: Ein ECP-Server ist ein Cachéandere Hard- oder Softwarebasis als auch mengesucht werden. Durch die VerwenSystem, das Daten für andere Caché-Sysdie Skalierung vom Einzelserver auf verdung der multidimensionalen Speiche- teme bereitstellt. teilte Strukturen. Zusätzliche Server lasrungsform reduziert sich auch die Zahl Jeder ECP-Server in einer gegebenen sen sich im laufenden Betrieb hinzufügen der Festplattenzugriffe, was sich in messStruktur ist zuständig für und vom Administrator als Datenquellen baren Performance-Gewinnen niederoder Applikationsserver konfigurieren, schlägt [Olofson 2003]. • die Speicherung von Daten in seinen lokalen Datenbanken, ohne dass an den darauf aufsetzenden Gegenstand des Caching sind die Da• den Abgleich der Datenbank-Caches Anwendungen irgendetwas geändert tenblöcke, die die Globals repräsentieren, der verschiedenen Clientsysteme, werden müsste. sowie das Global Directory, das zum • die Verwaltung von SperrinformatioAuffinden der gespeicherten Informationen für die Globals. 2.3 Lokales und verteiltes Caching nen dient [Schatz-Cairoli 2003]. Die Verwaltung erfolgt wie bei Speicherseiten in Definition: Ein ECP-Client ist ein SysJedes Caché-System verwaltet, wie bei DBMS üblich, einen lokalen Datenbank- klassischen Datenbank- oder Betriebs- tem, das seine Informationen von einem oder mehreren ECP-Serversystemen besystemen. Cache (Abb. 3), ein Shared-MemoryBei häufig wiederkehrenden Anfragen zieht. Segment, das als Zwischenspeicher für ECP-Clients erfüllen folgende AufZugriffe auf die lokalen Datenbanken ist es sogar möglich, dass die benötigten gaben: Teile des Global Directory überhaupt nicht dient. Dieser Cache reduziert den Aufwand für Datenzugriffsoperationen beim Lesen und Speichern und gewährleistet Datenbank-Spektrum 7/2003 mehr vom externen Datenträger (oder bei ECP aus dem Netz) geholt werden müssen, • Verbindungsaufbau zum ECP-Server, wenn eine Applikation Daten anfor- 15 Hohe Performance und Skalierbarkeit von verteilten Anwendungen dert, die auf diesem Server gespeichert sind, • Statusüberwachung aller Verbindungen zu ECP-Servern und Versuch der Wiederherstellung bei unterbrochenen Verbindungen, • Vorhalten der aus dem Netz gewonnenen Daten im lokalen DatenbankCache. Bezüglich der Betriebssysteme auf den im Netz eingesetzten Rechnern ist der Systemintegrator relativ frei: Es kann sogar jede Station mit einem anderen Betriebssystem gefahren werden, sofern dafür eine Caché-5-Version angeboten wird. Dies betrifft neben den 32-Bit-Windows-Versionen und Open VMS auch alle geschäftlich bedeutsamen Unix- und Linux-Distributionen sowie Mac OS X [InterSystems 2002]. Da die Konfiguration über Namespaces erfolgt, entsteht kein zusätzlicher Aufwand gegenüber einer homogenen Rechnerlandschaft. 2.5 ECP-Interna Eine wichtige Frage in verteilten Strukturen ist die Konsistenz/Kohärenz der beteiligten Caches. Allgemein sind die Requests der ECP-Clients in zwei Gruppen zu unterteilen: • Typ get entspricht dem SELECT in relationalen DBS, • Typ set/kill entspricht INSERT, UPDATE und DELETE. Requests vom Typ »get« lösen auf dem ECP-Client als Erstes eine Suche im Cache aus und im »miss«-Fall die Anforderung des gesuchten Datenblocks vom ECP-Server mit anschließendem Caching auf dem Client. Der ECP-Server führt eine Liste aller Datenblöcke, die auf den einzelnen ECP-Clients aktuell gecacht sind (Abb. 4). Requests vom Typ »set/kill« werden demgegenüber direkt zum ECP-Server gesandt. Betrifft dies einen Block, der auf demselben Client gecacht ist, erfolgt parallel das Update des eigenen Caches. Kann der Request nicht im Rahmen des vorliegenden, gecachten Datenblocks vollzogen werden, wird dieser auf dem Client gelöscht und die Löschung dem Server mitgeteilt, der den Block aus der Liste der gecachten Blocks für das betreffende Clientsystem streicht. Bei jeder Änderung eines Blocks auf dem ECP-Server werden alle Clients benachrichtigt, die diesen Block gecacht ha- 16 ECP-Server Blocklist Client 1: … 47110815 ... Cache Client 2: … # 47110815 Client 3: … 47110815 … get notify set/kill ECP-Client 2 ECP-Client 1 set/kill Cache ECP-Client 3 (Block # 47110815 nicht vorhanden) purge Cache Cache # 47110815 # 47110815 Thin Clients Thin Clients Thin Clients Abb. 4: Der ECP-Server gewährleistet die Konsistenz der Caches ben, und streichen den betreffenden Block aus ihrem Cache. Spielt sich die Änderung im Rahmen eines Blockes ab, wird aus Performance-Gründen auf dem betroffenen ECP-Client der Block nicht gelöscht, wohl aber auf allen anderen Clients, die den gleichen Block zwischengespeichert haben. 3 3ECP in der Praxis Um ECP zu betreiben, werden mindestens zwei, besser mehrere Serversysteme benötigt, auf denen Caché ab der Version 5 installiert ist. Im zu installierenden Softwareumfang gibt es keinerlei Unterschiede. Lediglich einige Konfigurationsparameter teilen dem Einzelsystem mit, welche Funktion es im Gesamtgefüge zu erfüllen hat. Für die Einstellung dieser Parameter stellt Caché eine grafische Oberfläche zur Verfügung. Das vorliegende Kapitel beschreibt die Details der Konfiguration, erläutert die Besonderheiten einer verteilten Struktur unter Caché/ ECP und gibt einen Überblick über die implementierte Recovery-Strategie. 3.1 ECP-Strukturen konfigurieren ECP-fähige Anwendungen basieren auf einer Netzwerkstruktur mit einem oder mehreren ECP-Servern (Datenserver) sowie mehreren ECP-Clients (Applikationsserver). Die Trennung in »Daten«und »Applikations«-Server ist eher formaler Natur, da beide Typen von Servern im Falle von Caché in der Lage sind, sowohl Daten als auch Programmcode für Geschäftsanwendungen zu speichern und letztere auch auszuführen. Zu beachten ist nur, dass für jeden gespeicherten Global ein einziger Server im Netz als Lockmaster fungiert, also diesen Global in seiner lokalen Datenbank auf der Festplatte vorhält; alle anderen üben bezüglich dieses Globals reine Caching-Funktionen aus. Die Konfiguration der Einzelserver erfolgt über ein von InterSystems geliefertes GUI, den Konfigurationsmanager, der unter MS Windows läuft, mit dem sich aber ebenso alle Caché-Server im Netz konfigurieren lassen, die auf anderen Betriebssystemen laufen. Die Konfiguration für die Benutzung von ECP im Netz umfasst drei Bereiche: • Ein System, das als ECP-Server dienen soll, wird als solcher gekennzeichnet. Hierzu ist lediglich eine Checkbox im grafischen Konfigurationsdialog anzuwählen, woraufhin das Serversystem alle notwendigen Einstellungen automatisch vornimmt. Für jeden ECP-Server lässt sich eine Liste von Clients festlegen, die überhaupt auf diesen Server zugreifen dürfen. Dies ist eine reine Sicherheitsfunktion, die mit dem eigentlichen Caching oder der Funktionsweise des Transaktionsprotokolls nichts weiter zu tun hat. Möglich ist die Angabe einzelner Datenbank-Spektrum 7/2003 Hohe Performance und Skalierbarkeit von verteilten Anwendungen Hosts per IP-Adresse oder Hostname wie auch die Festlegung ganzer Bereiche von IP-Adressen. • Für jedes ECP-Clientsystem sind der oder die ECP-Server anzugeben, von denen der Client seine Daten beziehen soll. In diesem Schritt wird lediglich festgelegt, welche Datenbanken von im Netz vorhandenen Servern für die nachfolgende, detailliertere Konfiguration auf dem Clientsystem sichtbar sein sollen. • Auf jedem ECP-Client ist der Zugriff auf Datenbanken des Serversystems einzurichten. Sowohl ECP-Server als auch ECPClients benötigen nach den Konfigurationsschritten des ersten und zweiten Anstriches einen Neustart des Caché-Datenbankservers, nicht jedoch des darunter liegenden Betriebssystems. Auf dem Clientsystem ist nach dem Neustart der Datenbankzugriff zu konfigurieren. ECP verwendet hierzu den Begriff der Remote Database. Eine solche Datenbank residiert physisch auf dem ECP-Server (»Datenserver«), der entsprechende Namespace wird jedoch auf dem Clientsystem (»Applikationsserver«) eingerichtet. Als Werkzeug ist wiederum der Konfigurationsmanager nutzbar. Ein Namespace auf der Basis einer (oder mehrerer) Remote-Datenbank(en) wird hierbei genauso konfiguriert wie sein Äquivalent bei einer rein lokalen Datenbank. Die erforderlichen Zugriffe werden zur Laufzeit gleichsam im Verborgenen ausgeführt, der Programmierer oder Anwender braucht sich hierum nicht zu kümmern. Da die Anwendung nur mit dem Namespace kommuniziert, niemals direkt mit der oder den darunter liegenden Datenbanken, erfolgt der Zuriff völlig transparent. Für die Programmierung hat es keinerlei Konsequenzen, unter welchem Betriebssystem die einzelnen Server laufen und wo sie sich physisch befinden. 3.2 Intelligente Verteilung von Datenobjekten und Programmcode Über die reine Caching-Funktion hinaus ist es in einer ECP-Struktur möglich, weitere Performance-Vorteile durch geschickte Verteilung der Globals und Routinen im Netz zu erzielen. Routinen sind Bestandteil der Klassendefinitionen, gleich ob es sich dabei um Klassen- oder Instanzenmethoden handelt. Das heißt, diese Methoden wer- Datenbank-Spektrum 7/2003 den für gleichartige Objekte nur einmal auf jedem dezentralen System benötigt. Dem trägt ECP Rechnung, indem es diesen Programmcode nur einmal cacht, unabhängig von der Anzahl der Instanzen einer Objektklasse, die aktuell im Cache des Clientsystems vorliegen. Alle diese Instanzen greifen gleichberechtigt und multientrant auf den gecachten Code zu. Andererseits ist es eine Erfahrungstatsache, dass Methodencode sich wesentlich seltener ändert als »gewöhnliche« Objektdaten. Hier bietet Caché die Möglichkeit, Klassendefinitionen samt Routinen dezentral und somit näher am Benutzer zu speichern, so dass Netzzugriffe im täglichen Betrieb für diesen Teil des Datenbankbetriebes unter günstigen Umständen sogar ganz entfallen. Für jeden Namespace kann der Administrator beim Anlegen (oder einer späteren Modifikation) des Namespace festlegen, woher einerseits die Globals und andererseits die Routinen bezogen werden (standardmäßig aus derselben Datenbank, aber nicht Bedingung). Darüber hinaus besteht durch differenziertes Global Mapping die Möglichkeit, einzelne Globals und/oder Routinen auch aus anderen Datenbanken zu beziehen. Hierdurch ergeben sich flexible Strukturen mit minimalen Zugriffszeiten für die Benutzer. 3.3 Recovery im Hintergrund Die Behandlung von Ausnahmesituationen wie Unterbrechungen der Verbindung zwischen Client und Server verläuft unter ECP im Wesentlichen unbemerkt. Bei einer Unterbrechung des Datenverkehrs werden – ähnlich wie in anderen verteilten Systemen – nacheinander die folgenden Schritte durchlaufen: • Der Verbindungszustand wird auf »Trouble« gesetzt. • Der ECP-Client versucht die Verbindung zum Server wiederherzustellen. • Bei Erfolg erhält der Verbindungszustand wieder den Wert »Normal«. • Sperren und offene Transaktionen werden in den Zustand vor der Unterbrechung zurückgesetzt. Lässt sich die Verbindung nicht innerhalb einer vorgegebenen Timeout-Periode automatisch wiederherstellen, hebt ECP auf dem Server alle Sperren auf, die von diesem Clientsystem gehalten werden; offene Transaktionen werden zurückgesetzt (Rollback) und der Verbindungszustand wird auf »Not Connected« gesetzt. Die standardmäßig eingestellten Timeout-Werte zeigt Tabelle 1. Sie können durch Administratoreingriff jederzeit geändert werden, gesondert für jeden einzelnen ECP-Server (erste Tabellenzeile) und ECP-Client (zweite und dritte Tabellenzeile). 60 sec Zeit, die ein Server auf Beendigung des Troublezustandes wartet 5 sec Zeit, bevor ein Client nach missglücktem Versuch erneut Verbindung aufnimmt 20 min Zeit, nach der der Client die Verbindungsversuche aufgibt Tab. 1: Standard-Timeout-Werte des ECPProtokolls Zu erkennen ist, dass der ECP-Client dem Server eine wesentlich größere »Gnadenfrist« einräumt, nach einem etwaigen Crash seine Datenbanken wiederherzustellen, so dass er dann normal mit ihm weiterarbeiten kann. Umgekehrt ist es für den ECP-Server wenig sinnvoll, allzu lange die Verbindungen für einen eventuell ausgefallenen Client offen zu halten. 3.4 Leistungsfähigkeit von ECP Ziel aller Bemühungen sind natürlich messbare Vorteile in der Performance von Datenbanksystemen, die mit der beschriebenen Technik ausgestattet sind. Hierzu gibt es einige Studien, die im Internet und in Zeitschriften bzw. Reports veröffentlicht sind. Eher qualitative Aussagen trifft [Olofson 2003]. Demgegenüber enthält die Untersuchung von [Epic 2002] Zahlenmaterial zum Vergleich zwischen einer Ein-Server-Struktur und einer ECPKonfiguration mit einem Daten- und zwei Applikationsservern. Einen Bericht der sächsischen Landesbibliothek Dresden über die Einführung des ECP-basierten Bibliotheksverwaltungssystems LIBERO enthält [Grothe 2002]. Weitere Anwendungsbeispiele mit Zahlenangaben finden sich auf der Website von InterSystems USA unter http:// www.InterSystems.com/cache/whitepapers/ performance.html. Ein Beispiel aus dem Bereich der Medizin soll den vorliegenden Beitrag abschließen. 17 Hohe Performance und Skalierbarkeit von verteilten Anwendungen 4 Anwendung: ECP bei Partners HealthCare in Boston Ein Anwendungsbereich für Datenbanken, in dem es besonders auf Ausfallsicherheit und kurze Reaktionszeiten ankommt und der sich traditionell durch ein hohes Datenaufkommen auszeichnet, ist das Gesundheitswesen [Kirsten & Ihringer 2002]. Zahlreiche Kliniken und Klinikverbunde in aller Welt verwenden bereits seit längerem das DBMS Caché [Advance 2002]. Mit der Einführung von Version 5 ergeben sich erweiterte Möglichkeiten durch den Einsatz des Enterprise Cache Protocol. Eines der großen Gesundheitsfürsorge-Netzwerke der USA, Partners HealthCare System in Boston, Massachusetts, setzt ECP auf der Basis von Caché-Servern zur Verwaltung seiner Informationssysteme ein. Angeschlossen sind Mitglieds- und Partnereinrichtungen wie das Massachusetts General Hospital und die Harvard School of Medicine mit einer Gesamtzahl von mehreren tausend Ärzten und Angestellten [Flammini 2002]. Das Datenvolumen betrug bereits im Vorjahr etwa 300 GB. Gegenwärtig werden durch das Netz etwa 35.000 Endbenutzer-Arbeitsplätze bedient. Aus beiden Größen ergibt sich ein entsprechendes Transaktionsaufkommen. Erwartet wird ein Wachstum auf ca. 50.000 Arbeitsstationen. Die Hälfte davon sind Thin Clients auf der Basis von Webbrowsern. Seitens der Geschäftsleitung von Partners wird angegeben, dass ständig etwa 5.000 Benutzerzugriffe gleichzeitig erfolgen. Die Tendenz ist hier ebenfalls steigend. Tabelle 2 zeigt noch einmal eine Zusammenstellung der wesentlichen technischen Daten. Anzahl Merkmal 6 Caché-Datenserver (ECP-Server) 11 Caché-Applikationsserver (ECP-Clients) 300 GB gespeicherte Daten 35000 Arbeitsstationen 4 Datenbankadministratoren Tab. 2: Wichtige Kenngrößen des PartnersNetzes in Boston Inhaltlich ist vom System ein breites Spektrum an Aufgaben abzudecken. Enthalten sind eine komplette Mitarbeiter- 18 verwaltung mit integriertem Notrufsystem, das Führen von Patientenakten, die Aufnahme und Archivierung ärztlicher Verordnungen, ein Web-Portal zur öffentlichen Benutzung durch Patienten bzw. Interessenten und ein unternehmensweit nutzbares Repository klinischer Daten. Jede dieser und weiterer, hier nicht genannter Anwendungen muss ständig verfügbar sein (»7x24«-Betrieb), um die Erfordernisse der sieben angeschlossenen Notfallkliniken zu erfüllen. Zu verarbeiten sind die Daten von mehreren Millionen Patientenkontakten. Eine Besonderheit von Partners ist, dass das Netzwerk durch Zusammenschluss von teilweise recht unterschiedlich ausgestatteten Einzelunternehmen entstand und eine dementsprechend heterogene Rechnerlandschaft aufweist. In dieser Umgebung kommen die Vorteile der hier im Artikel beschriebenen Struktur besonders zum Tragen. 5 Fazit Das Enterprise Cache Protocol ECP gestattet die Entwicklung verteilter Datenbankanwendungen unter Entkopplung von der darunter liegenden Hardwareund Betriebssystemtechnik. Für Programmierer und Benutzer ist das Protokoll transparent; für Administratoren bedeutet es nur einen geringen Konfigurationsaufwand. Durch Nutzung von TCP/IP eignet es sich besonders zum Einsatz in heterogenen Netzwerken. Seine Stärken sind hohe Performance durch intelligentes, lokales Caching und Skalierbarkeit ohne zusätzlichen Programmieraufwand sowie eingebaute Sicherheits- und Wiederherstellungsfunktionen bei Teilausfällen im Netz. 6 Literatur [Advance 2002] redaktionell: InterSystems Focuses on Health Care. Advance for Health Information Executives, 6. Jg., 2002, Heft 5 (Mai 2002), S. 72. [Binder 2003] Binder, U.: Schaltzentrale der Unternehmens-IT. InfoWeek.CH, 2003, Ausgabe 08 v. 24.04.2003, S. 23-25. [Epic 2002] Epic: Solaris Unix/Caché and Sun 6800. Stress Testing Results. November 25 December 12, 2002. Epic Systems Corp., Madison (WI), 2002. [Flammini 2002] Flammini, St.: Partners HealthCare Extends Application Reach with InterSystems Caché Post-Relational Database. DM Review, 12. Jg., 2002, Heft 6 (Juli), S. 112. [Grothe 2002] Grothe, J.: Die Einführung von LIBERO in Sachsen. B.I.T., 5. Jg., 2002, Heft 4, S. 313-325. [Härder & Rahm 1999] Härder, T.; Rahm, E.: Datenbanksysteme. Konzepte und Techniken der Implementierung. Springer-Verlag, Berlin, Heidelberg, New York, 1999. [Heuer 1997] Heuer, A.: Objektorientierte Datenbanken. Konzepte, Modelle, Standards und Systeme. 2., aktualisierte und erweiterte Auflage. Addison-Wesley, Bonn, 1997. [InterSystems 2002] InterSystems Corp.: OnlineDokumentation zu Caché 5, Cambridge (MA), 2002. [InterSystems 2003] InterSystems GmbH, Darmstadt: Caché 5 von InterSystems verfügbar. In: Datenbank-Spektrum, 3. Jg., 2003, Heft 6, S. 3. [Kaluzova & Manasova 2003] Kaluzova, L.; Manasova, S.: Relational and Object-oriented Approach in the Environment of the database system Caché. Manuskript für die 5th International Conference on Strategic Management and its Support by Information Systems, Ostrava (Tchechische Republik), 03.-5.09.2003. [Kirsten & Ihringer 2002] Kirsten, W.; Ihringer, M.: Caché von InterSystems. Postrelationale Datenbanktechnologie für das Gesundheitswesen. mdi, 4. Jg., 2002, Heft 4, S. 127 - 130. [Kirsten et al. 2003] Kirsten, W.; Ihringer, M.; Kühn, M.; Röhrig, B.: Objektorientierte Anwendungsentwicklung mit der postrelationalen Datenbank Caché. Springer-Verlag, Berlin, Heidelberg, New York, 2003. [Lutz 2002] Lutz, H.: Postrelationale Datenverwaltung. Technische Kommunikation, 24. Jg., 2002, Heft 6, S. 44-46. [Olofson 2003] Olofson, C. W.: Breaking the Relational Barreer: User Data Management Triumphs with Intersystems' Caché. IDC White Paper. IDC, Framingham (MA), Februar 2003. [Reichelt 2003] Reichelt, D.: Mehr als Objekte. Javamagazin, 6. Jg., 2003, Heft 6, S. 84-87. [Röhrig 2003] Röhrig, B.: Webdatenbanken mit Linux. Computer und Literatur Verlag, Böblingen, 2003. [Schatz-Cairoli 2003] Schatz-Cairoli, K.: persönlich erteilte Auskunft, InterSystems GmbH, Darmstadt, 2003. Dr.-Ing. Bernhard Röhrig leitet die Firma roehrig.com in Erfurt, die sich auf heterogene Netzwerke und Datenbanksysteme spezialisiert hat. Bekannt geworden ist er durch zahlreiche Veröffentlichungen in Fachzeitschriften und in Buchform sowie Vorträge, Seminare und Workshops im gesamten Bundesgebiet. Dr.-Ing. Bernhard Röhrig EDV-Consulting Publikationen Kabarett Singerstr. 96 99099 Erfurt [email protected] http://www.roehrig.com Datenbank-Spektrum 7/2003
