Datenbanken in Rechnernetzen und Transaktionssysteme - Exam

Aufgabe 1)

Architektur für verteilte Systeme: Die Wahl der richtigen Architektur ist entscheidend für die Effizienz und Skalierbarkeit eines verteilten Systems. Zu den häufig verwendeten Architekturen gehören Client-Server, Peer-to-Peer (P2P), Schichtenarchitekturen und Microservices. Jede dieser Architekturen hat ihre eigenen Vor- und Nachteile hinsichtlich Skalierbarkeit, Lastverteilung und Fehlertoleranz. In dieser Aufgabe sollst Du Dich mit diesen Architekturen auseinandersetzen und spezifische Fragestellungen bearbeiten.

a)

(a) Client-Server vs. Peer-to-Peer: Erläutere die Unterschiede zwischen Client-Server- und Peer-to-Peer-Architekturen hinsichtlich ihrer Skalierbarkeit und Fehlertoleranz. Analysiere in welchem Anwendungsfall welche Architektur vorzuziehen ist und warum.

Lösung:

• Client-Server-Architektur:In einer Client-Server-Architektur gibt es in der Regel einen oder mehrere Server, die Dienstleistungen oder Ressourcen anbieten, sowie mehrere Clients, die auf diese Ressourcen zugreifen. Die Clients senden Anfragen an den Server, der diese verarbeitet und entsprechende Antworten zurücksendet. Diese Architektur ist weit verbreitet und bildet das Rückgrat vieler moderner Netzwerkanwendungen wie Webanwendungen, E-Mail-Dienste und Datenbanken.
  • Skalierbarkeit:Die Skalierbarkeit einer Client-Server-Architektur hängt stark von der Leistungsfähigkeit des Servers ab. Wenn die Anzahl der Clients zunimmt, kann der Server schnell an seine Leistungsgrenzen stoßen. Um die Skalierbarkeit zu erhöhen, können Lastverteilung und Server-Cluster eingesetzt werden, was jedoch mit zusätzlichen Kosten und Komplexität verbunden ist.
  • Fehlertoleranz:Die Fehlertoleranz ist begrenzt, da der Ausfall des Servers die gesamte Kommunikation zwischen den Clients stören kann. Um die Fehlertoleranz zu verbessern, können Mechanismen wie Server-Redundanz und Failover-Lösungen implementiert werden.
• Peer-to-Peer (P2P)-Architektur:In einer Peer-to-Peer-Architektur agieren alle Knoten (Peers) sowohl als Clients als auch als Server. Jeder Peer kann sowohl Ressourcen anbieten als auch auf Ressourcen anderer Peers zugreifen. Dies schafft eine dezentralisierte Netzwerkstruktur, in der jeder Teilnehmer gleichberechtigt ist.
  • Skalierbarkeit:Die Skalierbarkeit ist in einer P2P-Architektur in der Regel besser, da die Last gleichmäßig auf alle Peers verteilt wird. Bei steigender Anzahl von Peers erhöht sich die Gesamtkapazität des Systems. Dies führt zu einer natürlichen Lastverteilung und dynamischer Skalierbarkeit.
  • Fehlertoleranz:Die Fehlertoleranz ist ebenfalls höher, da das System dezentralisiert ist. Der Ausfall einzelner Peers hat nur geringe Auswirkungen auf das Gesamtsystem, da die anderen Peers weiterhin in der Lage sind, miteinander zu kommunizieren und Ressourcen bereitzustellen. Mechanismen wie Replikation und redundante Datenvorhaltung tragen zur Erhöhung der Fehlertoleranz bei.
• Anwendungsfälle:
  • Client-Server-Architektur: Diese Architektur ist besonders geeignet für Anwendungen, bei denen zentrale Steuerung und Verwaltung erforderlich sind, wie z. B. Online-Banking, E-Commerce-Websites und Enterprise-Anwendungen. Sie bietet eine zentrale Kontrollinstanz, was die Implementierung von Sicherheitsmaßnahmen und die Verwaltung von Daten erleichtert.
  • Peer-to-Peer-Architektur: Diese Architektur ist vorteilhaft für Anwendungen, die hohe Skalierbarkeit und Fehlertoleranz erfordern, wie z. B. Datei-Sharing-Netzwerke, dezentrale soziale Netzwerke und Kryptowährungen. Sie ermöglicht eine flexible und robuste Infrastruktur ohne zentrale Abhängigkeiten.

b)

(b) Microservices: Betrachte eine typische Microservices-Architektur. Angenommen, eine E-Commerce-Plattform ist in folgende Microservices unterteilt: Authentifizierung, Produktkatalog, Warenkorb und Zahlung. Berechne die theoretische maximale Anfrageanzahl, die das System verarbeiten kann, wenn jeder Microservice eine maximale Last von 1000 Anfragen pro Sekunde bewältigen kann und Lastverteilung existiert. Diskutiere zudem, wie sich eine fehlerhafte Instanz eines Microservices auf das Gesamtsystem auswirken würde und welche Mechanismen implementiert werden könnten, um diese Auswirkungen zu minimieren.

Lösung:

• Architektur für verteilte Systeme: MicroservicesBetrachten wir eine typische Microservices-Architektur im Kontext einer E-Commerce-Plattform, die in die folgenden Microservices unterteilt ist: Authentifizierung, Produktkatalog, Warenkorb und Zahlung. Jeder dieser Microservices kann eine maximale Last von 1000 Anfragen pro Sekunde bewältigen.
• Theoretische maximale Anfrageanzahl:Da die E-Commerce-Plattform aus vier separaten Microservices besteht und Lastverteilung existiert, können wir die theoretische maximale Anfrageanzahl berechnen, indem wir die Kapazitäten der einzelnen Microservices addieren.
• • Maximale Last pro Microservice: 1000 Anfragen/Sekunde
  • Anzahl der Microservices: 4
  • Theoretische maximale Anfrageanzahl: 4 * 1000 = 4000 Anfragen/Sekunde
  Somit kann das System theoretisch bis zu 4000 Anfragen pro Sekunde verarbeiten, wenn jeder Microservice seine maximale Last erreicht.
• Auswirkungen einer fehlerhaften Instanz:In einer Microservices-Architektur hat der Ausfall einer Instanz eines Microservices in der Regel nur begrenzte Auswirkungen auf das Gesamtsystem. Dies liegt daran, dass die anderen Instanzen des ausgefallenen Microservices weiterhin Anfragen verarbeiten können. Dennoch kann der Ausfall einer Instanz zu Verzögerungen oder temporären Engpässen führen, insbesondere wenn die Lastverteilung plötzlich die verbleibenden Instanzen stärker belastet.
• Mechanismen zur Minimierung der Auswirkungen:Es gibt mehrere Mechanismen, die implementiert werden können, um die Auswirkungen einer fehlerhaften Instanz eines Microservices zu minimieren:
  • Lastverteilung: Eine effektive Lastverteilung sorgt dafür, dass Anfragen gleichmäßig auf verfügbare Instanzen verteilt werden. Dadurch wird die Last im Falle des Ausfalls einer Instanz automatisch auf die verbleibenden Instanzen verteilt.
  • Auto-Skalierung: Auto-Skalierungsmechanismen können zusätzliche Instanzen des betroffenen Microservices starten, um die durch den Ausfall verursachte erhöhte Last zu bewältigen.
  • Service-Wiederherstellung: Implementiere Mechanismen zur automatischen Wiederherstellung fehlerhafter Instanzen, sodass ausgefallene Microservices schnell wieder online sind.
  • Circuit Breaker Pattern: Dieses Pattern verhindert, dass fehlerhafte Microservices durch übermäßige Anfragen weiter belastet werden. Es erkennt Fehlerzustände und leitet Anfragen gegebenenfalls auf alternative Services um oder blockiert sie, bis der fehlerhafte Service wieder verfügbar ist.
  • Monitoring und Alerts: Ein umfassendes Monitoring-System mit Alerts kann dazu beitragen, Probleme frühzeitig zu erkennen und sofortige Maßnahmen zu ergreifen, wenn eine Instanz ausfällt.

Durch die Implementierung dieser Mechanismen kann die Zuverlässigkeit und Stabilität einer Microservices-Architektur erheblich verbessert werden, wodurch die Auswirkungen fehlerhafter Instanzen minimiert werden und das Gesamtsystem insgesamt robuster wird.

Aufgabe 2)

ACID-Eigenschaften (Atomicity, Consistency, Isolation, Durability)

ACID-Eigenschaften sind grundlegende Prinzipien, die Transaktionen in Datenbanksystemen sicherstellen, um Datenintegrität und Zuverlässigkeit zu gewährleisten.

• Atomicity: Transaktionen sind unteilbar; entweder wird die gesamte Transaktion durchgeführt oder gar nicht. -> Ganz oder gar nicht Prinzip.
• Consistency: Transaktionen führen das System von einem konsistenten Zustand in einen anderen. -> Datenintegrität wird erhalten.
• Isolation: Gleichzeitige Transaktionen beeinflussen sich nicht gegenseitig. -> Erscheinungsbild von sequentieller Ausführung.
• Durability: Nach Abschluss einer Transaktion bleiben die Änderungen dauerhaft bestehen, selbst bei Systemausfällen. -> Permanent gesicherte Daten.

a)

Betrachte ein Szenario, bei dem die Transaktion T1 einen Betrag von 100€ von Konto A zu Konto B überweisen soll und die Transaktion T2 gleichzeitig einen Betrag von 50€ von Konto B zu Konto A überweisen soll.

(a) Erläutere, unter Verwendung der ACID-Eigenschaften, wie mögliche Probleme vermieden werden können, wenn beide Transaktionen parallel ausgeführt werden. Füge spezifische Beispiele hinzu, wie Isolation und Consistency hier eine Rolle spielen.

Lösung:

Um mögliche Probleme zu vermeiden, wenn die Transaktionen T1 und T2 parallel ausgeführt werden, können die ACID-Eigenschaften folgendermaßen angewendet werden:

• Atomicity: Beide Transaktionen müssen als unteilbare Einheiten betrachtet werden. Das bedeutet, entweder werden alle Operationen innerhalb der Transaktion erfolgreich durchgeführt, oder es wird nichts geändert. Wenn zum Beispiel bei T1 ein Fehler auftritt, nachdem 100€ von Konto A abgezogen wurden, aber bevor sie zu Konto B hinzugefügt wurden, muss die ganze Transaktion abgerollt werden, sodass der ursprüngliche Zustand wiederhergestellt wird.
• Consistency: Transaktionen müssen das System von einem konsistenten Zustand in einen anderen überführen. Wenn zum Beispiel das Ausgangsguthaben der Konten A und B zusammen 200€ beträgt, sollte die Summe nach beiden Transaktionen ebenfalls 200€ sein. So bleibt die Datenintegrität erhalten, und Regelungen zur Überprüfung von Kontoständen müssen angewendet werden, um sicherzustellen, dass Kontoüberziehungen nicht möglich sind.
• Isolation: Die gleichzeitige Ausführung von T1 und T2 sollte so erfolgen, dass die Transaktionen unabhängig voneinander erscheinen. Das bedeutet, eine Transaktion sollte keine unvollständigen Daten einer anderen Transaktion sehen. Beispielsweise, während T1 ausgeführt wird, sollte T2 entweder den ursprünglichen Zustand vor T1 oder den vollendeten Zustand nach T1 sehen, aber nicht einen Zwischenzustand. Dies kann durch Sperren der betreffenden Konten während der Transaktionen erreicht werden.
• Durability: Sobald eine Transaktion abgeschlossen ist, müssen die Änderungen permanent bestehen bleiben, selbst bei Systemausfällen. Wenn beispielsweise T1 erfolgreich ist und 100€ von A zu B überwiesen wurden, dann sollte dieser Zustand auch nach einem Systemabsturz erhalten bleiben. Dies wird oft durch das Schreiben von Transaktionslogs erreicht, die im Falle eines Absturzes wieder abgespielt werden können.

Beispiel Szenario:

• Transaktion T1 beginnt und zieht 100€ von Konto A ab.
• Bevor T1 die 100€ zu Konto B hinzufügt, beginnt Transaktion T2 und zieht 50€ von Konto B ab.
• In einem nicht-ACID-konformen System könnte eine vertauschte Ausführungsreihenfolge und Lese-/Schreibkonflikte auftreten. Im schlimmsten Fall könnte das System in einen inkonsistenten Zustand führen.
• Durch Anwendung der ACID-Eigenschaften wird sichergestellt, dass Isolation T1 und T2 in einer sequentiellen Reihenfolge erscheinen lässt. Consistency verifiziert, dass alle Geschäftsregeln während der Transaktionen eingehalten werden.

Somit werden mögliche Probleme wie Inkonsistenzen und Datenkorruption vermieden.

b)

(b) Angenommen, die Transaktion T1 wird nach der Hälfte abgebrochen, während die Datenbank in einem instabilen Zustand ist. Wie stellt die Atomicity-Eigenschaft sicher, dass die Datenbank in einem konsistenten Zustand bleibt? Beschreibe die Rolle von Protokollen oder Mechanismen, die dies unterstützen.

Lösung:

Wenn die Transaktion T1 nach der Hälfte abgebrochen wird, während sich die Datenbank in einem instabilen Zustand befindet, spielt die Atomicity-Eigenschaft eine entscheidende Rolle, um sicherzustellen, dass die Datenbank in einem konsistenten Zustand bleibt. Dabei werden folgende Punkte beachtet:

• Atomicity: Die Atomicity-Eigenschaft besagt, dass eine Transaktion entweder vollständig ausgeführt wird oder gar nicht. Um dies zu gewährleisten, werden Mechanismen wie Transaktionsprotokolle und Rollback-Operationen eingesetzt. Sollten bei der Transaktion T1 beispielsweise 100€ von Konto A abgezogen, aber noch nicht auf Konto B gutgeschrieben worden sein und die Transaktion abgebrochen werden, wird ein Rollback durchgeführt, das alle bisher durchgeführten Änderungen rückgängig macht. Auf diese Weise wird sichergestellt, dass keine Teilergebnisse zurückbleiben und die Datenbank in einem konsistenten Zustand bleibt.
• Protokolle und Mechanismen zur Unterstützung der Atomicity:
• Transaktionslog: Ein Transaktionslog (auch Write-Ahead Log) ist ein Protokoll, das vor jeder Änderung einer Datenbank einen Eintrag erstellt. Dieses Protokoll speichert alle Änderungsoperationen, sodass im Falle eines Fehlers alle Änderungen, die unvollständig sind, zurückgesetzt werden können. Das Transaktionslog ein wichtiges Element zur Sicherstellung von Atomicity. Wenn die Transaktion T1 abbricht, kann das System mithilfe dieses Logs alle Änderungen erkennen und eine Undo-Operation durchführen, um den ursprünglichen Zustand wiederherzustellen.
• Checkpointing: Checkpointing ist eine Technik, bei der in regelmäßigen Abständen konsistente Zustände der Datenbank gespeichert werden. Diese Punkte dienen als Referenz, um bei Fehlern die Datenbank auf einen konsistenten Zustand zurückzusetzen. Wenn T1 abbricht, stellt das System sicher, dass alle Änderungen seit dem letzten Checkpoint entweder komplett zurückgesetzt oder vollständig durchgeführt werden.
• Recovery-Mechanismen: Im Falle eines Systemausfalls kommen Recovery-Mechanismen zum Einsatz. Diese Mechanismen nutzen Transaktionsprotokolle und Checkpoints, um sicherzustellen, dass die Datenbank nach einem Absturz in einen konsistenten Zustand zurückversetzt wird. Falls T1 abbricht, wird der Recovery-Mechanismus alle transaktionalen Änderungen rückgängig machen, die nicht vollständig durchgeführt wurden, bevor der Fehler auftrat.

Zusammenfassend sorgt die Atomicity-Eigenschaft, unterstützt durch Protokolle wie Transaktionslogs und Mechanismen wie Checkpointing und Recovery, dafür, dass bei einem Abbruch der Transaktion T1 die Datenbank in einen konsistenten Zustand gebracht wird, indem alle nur teilweise durchgeführten Änderungen rückgängig gemacht werden. Dadurch wird sichergestellt, dass keine inkonsistenten Daten verbleiben und die Integrität des Systems bewahrt bleibt.

Aufgabe 3)

Replikationstechniken in Datenbanksystemen: Betrachte ein verteiltes Datenbanksystem, das sowohl synchrone als auch asynchrone Replikationsmethoden unterstützt. Eine Primärdatenbank (DB_P) wird verwendet, um Änderungen zu initiieren, und diese Änderungen müssen schließlich auf alle Replikas (DB_R1, DB_R2, ...) angewendet werden. Die synchrone Replikation setzt voraus, dass Änderungen an DB_P sofort auf alle Replikas propagiert werden, während die asynchrone Replikation Änderungen in einem späteren Zeitpunkt propagiert. Betrachten wir die folgenden Kenngrößen:

• Primärdatenbank-Antwortzeit (T_primär): Die Zeit, die für eine Transaktion auf der Primärdatenbank benötigt wird.
• Netzwerklatenz (T_netz): Die Zeit, die benötigt wird, um die Änderungen über das Netzwerk zu allen Replikas zu senden.
• Replikationszeit (T_rep): Die gesamte Zeit, die benötigt wird, um eine Transaktion synchron auf allen Replikas anzuwenden.
• Latenzdifferenz (D_latenz): Der Unterschied zwischen der Antwortzeit der Primärdatenbank und der Zeit, die eine Replika benötigt, um die Änderungen anzuwenden.

a)

Erläutere den Unterschied zwischen synchroner und asynchroner Replikation in Bezug auf Latenz und Netzwerkauslastung. Berücksichtige dabei die Gleichungen aus den gegebenen Informationen.

Lösung:

Unterschied zwischen synchroner und asynchroner Replikation in Bezug auf Latenz und Netzwerkauslastung:

• Synchrone Replikation:Bei der synchronen Replikation werden Änderungen, die an der Primärdatenbank (DB_P) vorgenommen werden, sofort auf alle Replikas (DB_R1, DB_R2, ...) propagiert. Dies bedeutet, dass die Transaktion nicht als abgeschlossen gilt, bis alle Replikas die Änderungen übernommen haben.
• Latenz:Die Latenz bei synchroner Replikation umfasst sowohl die Primärdatenbank-Antwortzeit (T_primär) als auch die Netzwerklatenz (T_netz) und die Zeit, die die Replikas benötigen, um die Änderungen anzuwenden. Somit ergibt sich die gesamte Replikationszeit (T_rep) für eine Transaktion als:

   Trep = Tprimär + Tnetz

  Dieser Ansatz führt zu höherer Latenz, da jede Transaktion erst abgeschlossen wird, wenn alle Replikas die Änderungen erfolgreich übernommen haben.
• Netzwerkauslastung:Da bei der synchronen Replikation jede Änderung sofort an alle Replikas gesendet werden muss, kann dies zu einer hohen Netzwerkauslastung führen. Dies ist besonders kritisch in Umgebungen mit vielen Replikas oder großen Datenmengen.
• Asynchrone Replikation:Bei der asynchronen Replikation werden Änderungen an der Primärdatenbank (DB_P) zunächst nur dort bestätigt. Die Änderungen werden dann zu einem späteren Zeitpunkt auf die Replikas (DB_R1, DB_R2, ...) propagiert.
• Latenz:Die Latenz der Primärdatenbank (DB_P) ist bei der asynchronen Replikation geringer, da Transaktionen bereits als abgeschlossen gelten, bevor die Änderungen die Replikas erreicht haben. Daher berücksichtigt die Latenzdifferenz (D_latenz) die Differenz zwischen der Antwortzeit der Primärdatenbank (T_primär) und der Zeit, die eine Replika benötigt, um die Änderungen anzuwenden:

  Dlatenz = Trep - Tprimär

  Dies kann zu einer zeitlichen Verzögerung führen, da die Replikas die Änderungen erst später übernehmen.
• Netzwerkauslastung:Bei der asynchronen Replikation kann die Netzwerkauslastung optimiert werden, da die Änderungen gebündelt und zu weniger zeitkritischen Zeitpunkten gesendet werden können. Dies reduziert die Momentanbelastung des Netzwerks im Vergleich zur synchronen Replikation.

b)

Angenommen, die Primärdatenbank (DB_P) benötigt 150ms, um eine Transaktion abzuschließen, und die Netzwerklatenz für die synchrone Replikation beträgt 100ms. Berechne die gesamte Replikationszeit (T_rep). Wenn im Fall der asynchronen Replikation eine Replika (DB_R1) eine zusätzliche Verzögerung von 50ms hat, berechne die Latenzdifferenz (D_latenz) für diese Replika.

Lösung:

Berechnung der gesamten Replikationszeit (T_rep) und der Latenzdifferenz (D_latenz):

• Gegebene Daten:
• Primärdatenbank-Antwortzeit (T_primär): 150ms
• Netzwerklatenz (T_netz) für synchrone Replikation: 100ms
• Zusätzliche Verzögerung für asynchrone Replikation bei DB_R1: 50ms
• Synchrone Replikation:
• Berechnung der gesamten Replikationszeit (T_rep):

Trep = Tprimär + Tnetz

Einsetzen der Werte:

Trep = 150ms + 100ms = 250ms

Die gesamte Replikationszeit (T_rep) für die synchrone Replikation beträgt also 250ms.

Asynchrone Replikation:

• Berechnung der Latenzdifferenz (D_latenz) für DB_R1:

Dlatenz = Trep - Tprimär

Einsetzen der Replika-Antwortzeit für DB_R1:

• Replika-Antwortzeit (T_R1):

TR1 = Tprimär + Zusätzliche Verzögerung

Einsetzen der Werte:

TR1 = 150ms + 50ms = 200ms

Die Latenzdifferenz (D_latenz) für DB_R1 beträgt:

Dlatenz = TR1 - Tprimär

Einsetzen der Werte:

Dlatenz = 200ms - 150ms = 50ms

Die Latenzdifferenz (D_latenz) für die Replika DB_R1 bei asynchroner Replikation beträgt also 50ms.

Aufgabe 4)

In einem verteilten Datenbanksystem, welches zur Online-Bestellverarbeitung verwendet wird, treten regelmäßig Netzwerkpartitionen auf. Dieses System muss deswegen die Prinzipien des CAP-Theorems berücksichtigen. Die Datenbank soll sowohl die Bestell- als auch die Lagerbestandsinformationen speichern. Ein weiteres Ziel des Systems ist es, sicherzustellen, dass Kundenbestellungen in Echtzeit abgewickelt werden können, und dass zu jeder Zeit die korrekten Lagerbestände angezeigt werden.

a)

Frage 1: Angenommen, es erfolgt eine Netzwerkpartition in dem beschriebenen System und das System entscheidet sich für Konsistenz (C) und Partitionstoleranz (P). Erläutere ausführlich die Auswirkungen dieser Entscheidung auf die Funktionalität und Leistung des Systems. Berücksichtige dabei insbesondere, wie die Echtzeit-Abwicklung von Kundenbestellungen und die Anzeige korrekter Lagerbestände gewährleistet oder beeinträchtigt werden könnten.

Lösung:

Das CAP-Theorem besagt, dass es in einem verteilten System unmöglich ist, gleichzeitig Konsistenz (Consistency), Verfügbarkeit (Availability) und Partitionstoleranz (Partition Tolerance) vollständig zu gewährleisten. Man muss sich also für zwei der drei Eigenschaften entscheiden.

Wenn das beschriebene System sich für Konsistenz (C) und Partitionstoleranz (P) entscheidet, dann hat dies folgende konkrete Auswirkungen auf die Funktionalität und Leistung des Systems:

• Konsistenz (C): Jede Lese- und Schreiboperation muss sicherstellen, dass alle Relationen in der Datenbank vollständig konsistent sind. Der Zustand der Datenbank muss also zu jeder Zeit den vereinbarten Konsistenzregeln entsprechen. Das bedeutet, alle Daten sind synchron und es gibt keine inkonsistenten Zustände.
• Partitionstoleranz (P): Das System kann Netzwerkpartitionen tolerieren, d.h., auch wenn Teile des Netzwerks ausfallen oder geteilt werden, wird das System weiterhin korrekt funktionieren. Daten können in getrennten Partitionen existieren, aber das System bleibt betriebsfähig.
• Auswirkungen auf die Echtzeit-Abwicklung:
• Da das System Konsistenz über Verfügbarkeit priorisiert, kann es während einer Netzwerkpartition zu Verzögerungen kommen. Bestellungen könnten verzögert abgewickelt werden, da das System sicherstellen muss, dass die Datenbank konsistent bleibt.
• Diese Verzögerungen können sich direkt auf die Nutzererfahrung auswirken, da das System möglicherweise Anfragen blockiert oder die Bearbeitung verzögert, bis die Konsistenz gewährleistet werden kann.
• Auswirkungen auf die korrekten Lagerbestände:
• Die Entscheidung für Konsistenz stellt sicher, dass alle über das System abgerufenen Lagerbestandsinformationen zu jeder Zeit korrekt und aktuell sind. Es gibt keine widersprüchlichen Informationen.
• Jedoch müssen Nutzer möglicherweise warten, bis die Daten aus allen Partitionen synchronisiert sind, um die neuesten Lagerbestände anzuzeigen, was ebenfalls zu Verzögerungen führen kann.

Zusammengefasst wird das System, das sich für Konsistenz und Partitionstoleranz entscheidet, sicherstellen, dass die Daten immer konsistent bleiben, selbst wenn dies bedeutet, dass einige Benutzer auf die Bearbeitung ihrer Anfragen warten müssen. Diese Priorisierung könnte die Echtzeit-Verarbeitung von Bestellungen beeinträchtigen und führt zu potenziellen Verzögerungen bei der Anzeige korrekter Lagerbestände.

b)

Frage 2: Angenommen, das System entscheidet sich stattdessen für Verfügbarkeit (A) und Partitionstoleranz (P). Modelle und beschreibe in mathematischer Form, wie das System bei einer Bestellung während einer Netzwerkpartition reagieren sollte und welche Inkonsistenzen im Lagerbestand auftreten könnten. Zeige dabei anhand eines Beispiels, wie die verteilte Datenbank später eine Konsistenz der Daten wiederherstellen könnte, wenn die Netzwerkpartition aufgehoben wird.

Du kannst folgende Variablen verwenden:

• Anzahl der Bestellungen während der Netzwerkpartition: n
• Initialer Lagerbestand vor Netzwerkpartition: S_initial
• Lagerbestand nach Netzwerkpartition: S_final
• Fehlerhafte Lagerbestandsdaten: E

Stelle sicher, dass Du die Gleichungen zur Berechnung der inkonsistenten Lagerbestände und zur späteren Wiederherstellung der Konsistenz korrekt formulierst.

Lösung:

Wenn das System sich für Verfügbarkeit (A) und Partitionstoleranz (P) entscheidet, bleibt es trotz einer Netzwerkpartition funktionsfähig und akzeptiert weiterhin Bestellungen. Dadurch können jedoch Inkonsistenzen in den Lagerbestandsdaten auftreten. Untenstehend sind die mathematischen Modelle und eine Beschreibung, wie das System reagieren sollte, sowie die Berechnungsmethoden zur Wiederherstellung der Konsistenz nach der Netzwerkpartition.

• Anzahl der Bestellungen während der Netzwerkpartition: n
• Initialer Lagerbestand vor der Netzwerkpartition: S_initial
• Fehlerhafte Lagerbestandsdaten: E

Während der Netzwerkpartition:

• Angenommen, dass in jeder Partition n_i Bestellungen durchgeführt werden, wobei die Summe der Bestellungen aus allen Partitionen n ist: n = n_1 + n_2 + ... + n_k
• Der Fehlerhafte Lagerbestand in Partition i ist: E_i = S_initial - n_i

Wenn die Netzwerkpartition aufgehoben wird:

Zur Wiederherstellung der Konsistenz aggregiert das System die Bestellungen und passt den Lagerbestand entsprechend an. Dies erfolgt durch die folgende Gleichung:

S_final = S_initial - nS_final = S_initial - (n_1 + n_2 + ... + n_k)

Beispiel:

Angenommen, der initiale Lagerbestand beträgt 100 Einheiten (S_initial = 100), und während der Netzwerkpartition werden 20 Bestellungen in Partition 1 und 30 Bestellungen in Partition 2 getätigt (n_1 = 20 und n_2 = 30).

• Fehlerhafter Lagerbestand in Partition 1:E_1 = 100 - 20 = 80
• Fehlerhafter Lagerbestand in Partition 2:E_2 = 100 - 30 = 70

Nach der Wiederherstellung der Netzwerkverbindung:

S_final = 100 - (20 + 30) = 100 - 50 = 50

Das System korrigiert die Lagerbestände und stellt sicher, dass der korrekte Lagerbestand von 50 Einheiten wiederhergestellt wird. Diese Berechnung stellt sicher, dass auch nach der Aufhebung der Netzwerkpartition die Konsistenz wiederhergestellt wird.