Parallelverarbeitung, Replikation & Datenbank-Grids

Parallelverarbeitung - Transbase® Dynamic Multithreading

Transbase® Dynamic Multithreading wurde konzipiert, um die Möglichkeiten von Multiprozessorarchitekturen (heute auch in Notebooks Standard) auch bei rechenintensiven Abfragen nutzen zu können.

Dies erfolgt durch die dynamische Parallelisierung bestimmter dafür geeigneter Teilberechnungen. Über Transbase® Dynamic Multithreading werden die ausgewählten Teilberechnungen in mehrere gleichartige Threads aufgeteilt, wobei die Parallelität nahezu beliebig verändert werden kann.

Die Aufteilung erfolgt über einen speziellen Operatorbaumknoten ASYNC, der folgende wesentliche Aspekte der Parallelverarbeitung in sich konzentriert:

  • Bereitstellung eines Tupelpuffers, in die darunterliegende Knoten ihre Tupel ablegen und aus denen darüberliegende Knoten ihre Tupel abholen
  • Starten und beenden von Threads und Synchronisation der Pufferzugriffe - die Anzahl der generierten Threads ist dynamisch und hängt von der Verarbeitungsgeschwindigkeit der Threads ab

Ergibt sich an einer Stelle im Operatorbaum ein 'Stau', so werden zum Abbau des Staus weitere Threads kreiert. Dadurch ergibt sich ein dynamisches Gleichgewicht der Threads mit der Folge, dass sie weder wegen voller noch wegen leerer Puffer zu oft warten müssen.

Während also bei vielen gleichzeitigen Anfragen schon die Verteilung dieser Anfragen auf verschiedene Transbase® Kernel-Prozesse für die Ausnutzung der CPUs sorgt, ist es im Fall geringer Anfrage-Parallelität Aufgabe des einzelnen Prozesses, mehrere CPUs gleichzeitig auszunutzen.

Threads

Dynamic Multithreading mit 4 Pipelines

Über zwei verschiedene Verfahren kann der Prozess in mehrere Threads zerlegt werden, die dann parallel an einer einzelnen Query arbeiten können:

  • Zerlegung in verschiedenartige Threads

    z.B. IO-Threads, Restriktions-Threads, Sortier-Threads, etc.
    Hierbei sind der Parallelität gewisse Grenzen gesetzt, die sich durch die verschiedenen Funktionen der Threads ergeben.

  • Zerlegung in mehrere gleichartige Threads

    Hier kann die Parallelität fast beliebig verändert werden, soweit eine gewisse Datenparallelität gegeben ist. Diese Zerlegung erfolgt als Dynamisches Multithreading (siehe Grafik), wobei die Anzahl der parallel arbeitenden Threads dynamisch während der Ausführung angepasst wird.

    Die Parallelverarbeitung erstreckt sich insbesondere auch auf die IO-relevanten Phasen der Query-Verarbeitung. Dadurch wird automatisch auch der IO-Durchsatz deutlich gesteigert, so dass große RAID-Systeme optimal ausgelastet werden können. IO-relevant sind insbesondere die B-Baum-Algorithmen für den Blattzugriff - Sequential Scan und Intervallzugriff -  die Hypercube-Algorithmen - multidimensionaler Zugriff - sowie die Sortieralgorithmen, die je nach Sortiervolumen eine hohe IO-Last erzeugen können.

Somit können vorhandene Hardwareressourcen nicht nur für die parallele Abarbeitung unterschiedlicher Anfragen, sondern auch für die Beschleunigung einzelner rechenintensiver Anfragen voll ausgenutzt werden.


Replikation & Datenbank-Grids

Transbase® Datenbanken lassen sich sehr einfach, robust und schnell replizieren. Die Replikation dient zur

  • Einrichtung eines Standby-Betriebs
  • Lastverteilung in einem Datenbank-Grid
  • kontinuierlichen oder periodischen Distribution aus einer zentralen Datenbank in autonome Offline-Datenbanken

Replikation:

Bei der Replikation wird der Log der Master-Datenbank laufend auf die Slave-Datenbank(en) übertragen und dort prozessiert. Damit ist jede Slave-Datenbank unmittelbar und ohne Anlaufzeit in der Lage, die Rolle der Master-Datenbank zu übernehmen, falls dies nötig sein sollte (= Standby-Betrieb). Dieser Standby-Betrieb ist insbesondere für hochverfügbare Datenbanken essentiell.

Die Replikation erfolgt – wie die Kommunikation zwischen Client und Server auch – über einen festen TCP/IP Port. Damit lässt sich eine Datenbank auch auf einen geographisch entfernten Rechner replizieren.

Datenbank-Grids & Standby-Datenbanken:

Standby-Datenbanken sind reine Read-Only-Datenbanken und können ausschließlich über die Replikation verändert werden. Ansonsten können sie wie normale Datenbanken betrieben werden, auch während eine Replikation aktiv ist. Alle Slave-Datenbanken können in ein Datenbank-Grid eingebunden werden, in dem Transbase® für eine automatische dynamische Lastverteilung von Read-Only-Anfragen sorgt.

Über die Replikation kann eine zentrale Datenbank auf viele autonome Datenbanken repliziert werden, die ihrerseits periodisch oder kontinuierlich aktualisiert werden. Dies eignet sich z.B. im Automobilsektor für die Versorgung von Werkstätten aus einer zentralen Datenquelle. Nach einer morgendlichen Aktualisierung können Werkstätten autonom auf einem tagesaktuellen Datenbankstand arbeiten.

In diesem Umfeld werden auch beliebig hierarchische Strukturen unterstützt, in denen Standby-Datenbanken sowohl Master als auch Slave sein können.

Lesen Sie mehr über Transbase® Replication oder ein Anwendungsbeispiel.


Lesen Sie mehr zu Transbase® in unserem Info-Center.