17 Datenverteilung in Parallelen DBS
17.5 Datenverteilung bei Shared-Everything und Shared-Disk
Für Shared-Everything und Shared-Disk bezieht sich die Festlegung der Datenverteilung lediglich auf die Platten, nicht jedoch auf die einzelnen Prozessoren. Der Verteilgrad einer Relation bestimmt daher nicht in dem Maße wie bei Shared-Nothing den Overhead zur Parallelisierung, da alle Prozessoren ohne Kommunikationsverzögerung auf Daten aller Platten zugreifen können. Somit ist auch die Verteilung einer großen Relation über alle Platten eher vertretbar, um ein Maximum an E/A-Parallelität zu unterstützen. Für Relationen-Scans kann die hohe E/A-Parallelität einfach genutzt werden, unabhängig von der verwendeten Fragmentierungsstrategie. Dabei ist zur Vermeidung von Plattenengpässen lediglich darauf zu achten, daß pro Anfrage nicht mehrere Prozessoren von einer Platte lesen. Dies gestattet dennoch die Möglichkeit, die Anzahl von Prozessoren (den Parallelitätsgrad) p dynamisch zu wählen. Denn bei einem Verteilgrad D muß lediglich gelten
p * k = D,
wobei k die Anzahl der Platten angibt, die pro Teilanfrage zu bearbeiten ist. So kann für eine über 100 Platten verteilte Relation ein Relation-Scan von p= 1,2, 4, 5, 10, 20, 25, 50 oder 100 Teilanfragen parallel bearbeitet werden, während bei Shared-Nothing der Parallelitätsgrad i.a. durch den Verteilgrad (100) bestimmt ist.
Die Wahl eines hohen Verteilgrades geht bei Shared-Everything und Shared-Disk auch nicht zu Lasten selektiver Anfragen, die etwa nur eine Seite betreffen. Denn sofern ein Index zur Bestimmung der relevanten Seite genutzt werden kann, läßt sich die Bearbeitung problemlos auf einen Prozessor sowie eine Platte beschränken. Generell ist es bei diesen Architekturen möglich, Anfragen zur Minimierung des Kommunikationsaufwandes auf einen Prozessor zu beschränken.
Problematischer ist dagegen die Parallelisierung von Operationen, welche nur eine Teilmenge einer Relation betreffen, deren sequentielle Bearbeitung jedoch zu hohe Antwortzeiten verursacht. Die Schwierigkeit liegt in der Bestimmung einer Parallelisierung, welche garantiert, daß parallele Sub-Transaktionen nicht auf die selben Platten zugreifen. Hierzu ist eine dem DBS bekannte, logische Datenverteilung zu wählen, etwa auf Basis einer Hash- oder Bereichsfragmentierung. Damit kann das DBS wenigstens Anfragen auf dem Verteilattribut wiederum auf eine Teilmenge der Platten beschränken und sicherstellen, daß höchstens eine Sub-Transaktion auf eine Platte zugreift.
Beispiel 17-6
- Eine Relation soll über folgende Bereichspartitionierung auf Attribut A über 100 Platten verteilt sein:
- A: (1 - 10.000; 10.001 - 20.000; 20.001 - 30.000; ... 990.001 - 1.000.000)
- Eine Bereichsanfrage für A-Werte zwischen 70.000 und 220.000 kann damit von 15 (5, 3, 1) parallelen Teilanfragen bearbeitet werden, die jeweils 1 (3, 5, 15) der 100 Platten bearbeiten.
Die diskutierten Replikationsformen Spiegelplatten, verstreute und verkettete Replikation können für Shared-Everything und Shared-Disk zur schnellen Behandlung von Plattenfehlern genutzt werden [CK89, WZ93]. Die Replikation kann dabei für logische Objekte (Dateien, Sätze) oder auf physischer Ebene (Segmente, Seiten) außerhalb des DBS realisiert werden. Bei physischer Verwaltung der Kopien durch die Platten-Controller könnten auch bei verstreuter bzw. verketteter Replikation die Kopien (ähnlich wie für Spiegelplatten) einfach zur Lastbalancierung im Normalbetrieb genutzt werden [WZ93].