Auf zahlreichen FAQ’s und auch an anderen Stelen unserer Website wird die extrem ausgeprägte Client/Server-Topologie von transObjects® als eines dessen wichtigsten technischen Merkmale neben der durchgehenden Objektausrichtung charakterisiert. So werden beispielsweise in unseren FAQ-Artikeln „transObjects® vs. WinXY…“ bzw. „…Citrix- WinTerm-Software…“ gravierende Konsequenzen des Wegbleibens einer Client/Server-Topologie (bzw. gar der aktiven Datenbankinstanz überhaupt) diskutiert und mit Beispielen aus praktischer Erfahrung untermauert. Die Zielsetzung dieses Artikels kann daher nicht darin bestehen, die Sinnhaftigkeit der Client/Server-Topologie vor dem Hintergrund beispielsweise einer Terminal-Topologie zu beleuchten. Vielmehr beschäftigen wir uns nachfolgend mit einer Art Enhancement oder Verallgemeinerung der Client/Server-Topologie und zwar mit den sog. verteilten Datenbanksystemen.
Bei der Beschreibung der Systemvoraussetzungen fürs transObjects® fällt bereits der Begriff des verteilten Datenbanksystems (DDS, distributed database system) und zwar im Zusammenhang mit der aktiven Datenbankinstanz, als eine alternative Systemvoraussetzung hierzu. Und das ist es auch in der Tat, d.h. eine einzelne Datenbankinstanz (also ein Datenbankserver) ist ein Spezialfall eines verteilten Datenbanksystems, gewissermassen ein verkrüppeltes DDS. Die Frage, die in diesem Zusammenhang sofort gestellt wird – sozusagen die FAQ schlechthin – lautet, ob denn die ganze Philosophie des DDS in der Nutzung mehrerer Datenbankinstanzen bestehe? Ist beispielsweise der Datenaustausch mit den Datenbanken des transObjects®-Datacenters und parallel dazu das Arbeiten mit dem unternehmenseigenen Datenbankserver (beispielsweise bei der Anwendung von Corporate-Editions der elektronischen Verzollungsanwendungen) bereits als Anwendung eines verteilten Datenbanksystems zu bezeichnen?
Dazu ein klares „Ja“. Denn eine abwechselnde Nutzung mehrerer Datenbankserver durch einen Client, der Daten aus geographisch weit verstreuten Datenbanken benötigt und diesen unterschiedliche Daten zukommen lässt, fällt in der Tat in die Kategorie der Nutzung eines verteilten Datenbanksystems. Das tut jedoch dem High-End-Anspruch eines DDS keinen Abbruch – denken wir doch an das DDS, das bereits mit nur einem einzelnen Datenbankserver losgeht. Aber um auf die obige Frage zurückzukommen, ja, das Wesen eines DDS besteht im Prinzip in einer Vereinigung von mehreren Datenbankinstanzen, wobei erst deren Zusammenwirken untereinander ein modernes DDS ausmacht..
An dieser Stelle sei vorweg genommen, dass ein DDS per se nichts mit dem Clustering zu tun hat – auch nicht mit einem Hauptknotencluster unter Windows 2003 Enterprise- oder Datacenter-Edition. Denn das Wesen des Clusterings – zumindest unter den gängigen Betriebssystemen – besteht ja darin, einzelne Clusternodes abwechselnd für bestimmte Datenbankinstanzen und Datenpools zu aktivieren. Das Failover-Prinzip des Clusterings bedeutet die potentielle Bereitschaft eines Clusternodes zur Aufrechterhaltung einer Datenbankinstanz mit einem zugeordneten Datenpool, wenn andere Nodes diese Bereitschaft – aus welchen gründen auch immer – nicht aufrechterhalten können.
Um ein klassisches DDS zu charakterisieren, entwerfen wir ein Szenario, in dem die Client/ Server-Topologie mit nur einer Datenbankinstanz an ihre Grenzen stossen könnte, wobei gleich vorweggenommen sei, dass dies kein Fall ist, wo andere Topologien die bessere Wahl wären; ganz im Gegenteil. Mit einer Terminal-Topologie (zu denen gewissermassen auch eine Browser-Anwendung zählt) könnten wir nachfolgend gleich einpacken.
Seien A und E Standorte eines Unternehmens entsprechend in Afrika und in Europa. Das Unternehmen wendet diverse Special-Builds von transObjects®-Applikationen für den operativen Bereich sowie processPRO für den administrativen Bereich an, wo es um vielfältige Auswertungen dieser Daten geht. Natürlich bietet sich eine via Internet erreichbare zentrale Datenbankinstanz hierfür bestens an, z.B. am Standort E, so dass am Standort A mit den Clients über eine WAN-technische Anbindung (Internet) auf diese Instanz zugegriffen werden kann. Dies ist grundsätzlich kein sehr grosses Problem, wo doch transObjects® für eine Minimierung des Client/Server-Datenflusses bekannt ist. Dann können wir ruhigen Gewissens voraussetzen, dass die Bandbreite der WAN-Anbindung an die zentrale Datenbankinstanz signifikant geringer ist, als die LAN-technische Anbindung am Standort E.
Wo ist also das Problem bzw. der Sinn und Zweck eines DDS? Nun, die geringere Bandbreite der WAN-Anbindung an die Datenbankinstanz kann nicht mehr umgangen werden, wenn der Datenfluss notwendigerweise sehr hoch ist. Das könnte beispielsweise dann der Fall sein, wenn am Standort A Daten an sehr vielen und stark frequentierten Clients nach E geschickt werden – oder denken wir an das Beispiel des philippinischen Energieversorgers Real-World Benchmark: Caché vs. Oracle…, wo anderweitig erfasste Daten mit einem hohen Stream in den zentralen Server (in unserem Beispiel wäre es der Standort E) „gepumpt“ werden müssen. Hier reicht langsame Leitung schlicht nicht mehr aus, egal, wie schnell die Internetverbindungen künftig werden sollten.
Was also tun? Auch am Standort E werden vielen Daten im operativen Bereich erfasst und ebenso wir am Standort A transObjects® processPRO angewendet, um Auswertungen, Controlling-Aufgaben etc. wahrzunehmen. Somit ist es damit nicht getan, den Datenbankserver von E nach A zu verlegen. Was man aber machen kann, ist auch am Standort A eine Datenbankinstanz zu etablieren. Das Bandbreitenproblem ist damit zwar behoben, nicht jedoch das der Datenintegrität, das so sauber durch eine zentrale Datenbankinstanz gelöst werden konnte. Hier hilft nur eines, nämlich ein gezielt implementierter Datenabgleich von den beiden Datenbankinstanzen untereinender und zwar über die bestehende WAN-technische Verbindung.
Was erreichen wir dadurch? Nun kann an beiden Standorten mit der hohen Bandbreite einer LAN-technischen Verbindung gearbeitet werden, es können datenintensive Streams gespeichert und umfangreiche Abfragen problemlos durchgeführt werden – dem verteilten Datenbanksystem aus den beiden Instanzen an beiden Standorten sei Dank.
Natürlich stösst ein solches DDS durchaus an seine Grenzen. Haben wir beispielsweise nicht nur 2 sondern 20 Standorte, so wäre der Aufwand des Datenabgleichs und der Bandbreitenverbrauch hierfür enorm. Oder denken wir an das zuvor zitierte Beispiel des Energieversorgers, der nachts erst einmal gute zwei Stunden lang Daten in den (lokalen) Oracle-Datenbankserver eingelesen hat. Solche Datenmengen über eine Internetleitung abzugleichen, würde viel zu lange dauern. Und wäre ein solcher Abgleich endlich einmal durch, wären die Daten womöglich längst obsolet. Deshalb sprechen wir vom gezielten Abgleich*. In unserem Beispiel wären nur bestimmte Daten oder auch Zwischenresultate der Queries etc. abzugleichen.
________________________________________
* Um ein verteiltes Datenbanksystem mit Hilfe der transObjects®-Technologie aufzubauen, werden Enterprise bzw. Special-Build-Editions der transObjects®-Clients benötigt, ferner sind Caché-Server für alle DDS-Standorte erforderlich. Einen gezielten Datenabgleich übernehmen entweder die jeweiligen Caché-Server selbst oder proprietäre transObjects®-Services.
