Verteilte Datenbanken: Konzepte und Kostenanalyse

Frage 1: Replikation und Kosten

Erklären Sie, wie sich die Replikation auf die Verfügbarkeit von Daten in einer verteilten Datenbank auswirkt. Wie wirkt sie sich auf die Systemkosten aus?

Replikation: Bei der Replikation in einem verteilten Datenbanksystem (DDBMS) muss jeder Knoten eine vollständige Kopie der Datenbank haben. Diese Regelung verursacht offensichtlich hohe Speicherkosten. Da Aktualisierungen in allen Kopien vorgenommen werden müssen, entstehen auch hohe Schreibkosten. Dies lohnt sich jedoch, wenn wir ein System haben, in dem wenig gelesen und viel geschrieben wird, und wo die Verfügbarkeit und Zuverlässigkeit der Daten von größter Bedeutung sind. Mit diesem System können wir bei Ausfall eines Knotens immer noch auf die Datenbank zugreifen, da jeder eine Kopie hat. Je höher die gewünschte Verfügbarkeit einer Datenbank, desto länger muss sie aktiv gehalten werden, was höhere Kosten verursacht. Zum Beispiel ist bei einer replizierten verteilten Datenbank die Verfügbarkeit sehr hoch, aber die Schreibkosten sind ebenfalls sehr hoch.

Frage 2: Parallelitätskontrollmechanismen

Was sind Parallelitätskontrollmechanismen?

Parallelitätskontrolle (Concurrency Control) befasst sich mit den Problemen der Isolation und Konsistenz bei der Transaktionsverarbeitung. Die verteilte Parallelitätskontrolle eines DDBMS stellt sicher, dass die Konsistenz der Datenbank in einer verteilten Mehrbenutzerumgebung gewahrt bleibt. Damit Transaktionen in sich konsistent sind, ist der einfachste Weg, dies zu erreichen, jede einzelne Transaktion nacheinander auszuführen. Dies kann jedoch erhebliche Auswirkungen auf die Leistung des DDBMS haben, da der Grad der Parallelität minimiert wird. Der Grad der Parallelität ist wahrscheinlich der wichtigste Parameter in verteilten Systemen. Deshalb suchen Parallelitätskontrollmechanismen eine Balance zwischen der Wahrung der Datenbankkonsistenz und einem hohen Grad an Parallelität zu finden.

Wenn keine geeignete Parallelitätskontrolle erfolgt, kann dies zu zwei Anomalien führen. Erstens kann es dazu führen, dass die Auswirkungen bestimmter Transaktions-Updates verloren gehen und nicht in der Datenbank erfasst werden. Zweitens kann es zu widersprüchlichen Abfrageergebnissen führen.

Frage 3: Globale Atomarität und Protokolle

Was verstehen Sie unter Globaler Atomarität in einer verteilten Datenbank? Welches Protokoll ermöglicht globale Atomarität?

In Datenbanken bezeichnet ACID eine Reihe von Eigenschaften für eine Menge von Operationen, die als eine einzige logische Einheit (Transaktion) betrachtet werden müssen. Wenn ein Datenbank-Management-System ACID-konform ist, bedeutet dies, dass es die notwendige Funktionalität bietet, um sicherzustellen, dass seine Transaktionen die ACID-Eigenschaften erfüllen.

ACID ist ein Akronym für: Atomicity (Atomarität), Consistency (Konsistenz), Isolation (Isolation) und Durability (Dauerhaftigkeit).

Frage 4: Nachricht bei Koordinatorausfall

Welche Nachricht sendet ein untergeordneter Knoten an einen anderen Knoten, wenn der Transaktionskoordinator nicht erfolgreich beendet?

Abort

Frage 5: Beispiel für verteilte Transaktion

Nennen Sie ein Beispiel für eine verteilte Transaktion.

Banktransaktionen zwischen verschiedenen Filialen.

Frage 6: Fehlerhafte Betriebszustände

Beschreiben Sie fehlerhafte Betriebszustände des Systems.

Verteilte Systeme können unter den gleichen Arten von Fehlern leiden wie zentralisierte Systeme (z. B. Softwarefehler, Hardwareausfälle und Festplattenfehler).

Allerdings gibt es mehrere Arten von Fehlern, mit denen wir in verteilten Umgebungen umgehen müssen. Die grundlegenden Fehlertypen sind:

• Ausfall eines Standortes
• Nachrichtenverlust
• Ausfall einer Kommunikationsverbindung
• Netzwerkpartitionierung

Der Verlust oder die Beschädigung von Einträgen ist in verteilten Systemen immer möglich. Das System verwendet Übertragungsprotokolle wie TCP/IP, um solche Fehler zu behandeln. Informationen hierzu finden Sie in Lehrbüchern über Netzwerkstandards (siehe bibliographische Hinweise).

Fallstudie: NH Hotelkette und Semi-Join Kosten

Die NH Hotelkette wird durch eine verteilte Datenbank verwaltet.

Die Daten jedes Zimmers und die entsprechenden Aktionen befinden sich auf den Knoten des jeweiligen Hotels.

Die Daten der Hotels befinden sich auf einem Knoten in der Zentrale der Hotelkette.

Die Zentrale ist für die Abfrage aller Aktionen und Termine für die einzelnen Hotels der Kette zuständig.

Dies ist eine internationale Hotelkette mit 4.000 Hotels. Der Hotelcode benötigt 6 Bytes.

Es gibt rund 40.000 Hotelzimmer mit durchschnittlich 200 Aktionen pro Zimmer. Die Beschreibung der Aktionen benötigt 128 Byte und der Zeitpunkt der Aktion 6 Bytes.

Frage 7: Kosten der Abfrage mit Semi-Join

Wie hoch sind die Kosten dieser Abfrage unter Verwendung der Semi-Join-Technik?

Kostenberechnung (Semi-Join)

• Kosten: Zentrale zu Hotelknoten: 4.000 Hotels * 6 Byte (Hotelcode) = 24.000 Bytes
• Kosten: Hotelknoten zu Zentrale: 40.000 Zimmer * 200 Aktionen/Zimmer * (128 Byte Beschreibung + 6 Byte Datum + 6 Byte Hotelcode) = 8.000.000 Aktionen * 140 Byte/Aktion = 1.120.000.000 Bytes

GESAMTKOSTEN (Semi-Join): 24.000 Bytes + 1.120.000.000 Bytes = 1.120.024.000 Bytes