Hallo zusammen.
Und willkommen zurück.
Im heutigen Video werden wir über die Rolle von Nachrichtenwarteschlangen bei Datenbanktransaktionen sprechen.
Lassen Sie uns also fortfahren und dies anhand eines Anwendungsfalls verstehen.
Nehmen wir also an, Sie haben eine einzige Datenbank, die auf RDF gehostet wird.
Aufgrund einer laufenden Verkaufsförderungsaktion hat die Anzahl der richtigen Transaktionen in der Datenbank
in letzter Zeit das Zehnfache der normalen Belastung erreicht.
Sie haben also eine große Anzahl von richtigen Transaktionen, die jetzt stattfinden, da Sie eine einzige Datenbank
haben, die vorhanden ist, und es gibt eine hohe Last, viele der Anfragen sind regelmäßig fehlgeschlagen.
Und es gibt noch eine weitere wichtige Voraussetzung, nämlich dass die neuen Verkaufsaktionen, die im Gange
sind, weil es das 20-fache der normalen Belastung gibt, diese Verkaufsaktionen sind jeden zweiten Monat geplant.
Es handelt sich also nicht um 24 Stunden im Monat.
Sie findet jeden zweiten Monat statt.
Lassen Sie uns nun auf der Grundlage dieses speziellen Anwendungsfalls untersuchen, welche Lösung Sie implementieren
können.
Eine der einfachsten Lösungen, die man hier vermuten könnte, ist, dass
man direkt die Größe der Datenbank erhöht und auch die Anzahl der bereitgestellten IOPS erhöht,
so dass sie die 20-fache Last bewältigen kann, die derzeit durch die Verkaufsförderung
entsteht.
Die erste Einschränkung ist, dass es eine Ausfallzeit gibt. Wenn Sie diese Datenbank vertikal skalieren wollen,
müssen Sie die Datenbank herunterfahren und dann wieder starten.
Dies ist also eine besondere Herausforderung.
Die zweite Herausforderung sind die gestiegenen Kosten.
Nehmen wir zum Beispiel an, Sie haben die Datenbank skaliert. Früher hatte die Datenbank zwei
GB RAM, jetzt hat Ihre Datenbank 16 GB RAM und alles funktioniert perfekt.
Doch was geschieht nach Abschluss der Verkaufsförderung?
Ihre 16-GB-Datenbank wird ständig laufen, und das wird Ihre Kosten erheblich erhöhen.
Also gut.
Es handelt sich also um eine der Architekturen, die Unternehmen in der Regel vor allem wegen dieser Herausforderungen
meiden.
Um dieses Problem zu lösen, gibt es einen besseren Ansatz, bei dem eine Nachrichtenwarteschlange verwendet wird.
Bei dieser Art von Architektur werden die Nachrichten also nicht direkt in die Datenbank
eingefügt, sondern als Teil der ASCS-Warteschlange und der EC.
Zwei Instanzen ziehen die Nachricht aus der Warteschlange und fügen sie je nach Auslastung in die Datenbank
ein.
Nehmen wir an, dass die Datenbank bereits sehr stark belastet ist.
Dann können die Nachrichten beispielsweise ein oder zwei Minuten in der US-Warteschlange bleiben, und wenn die Datenbanklast
die Menge der EC erhöht, können zwei Instanzen die Nachricht abrufen und die Daten wieder in die Datenbank einfügen.
Und diese Art von Architektur finden Sie in vielen Organisationen.
Zu beachten ist, dass bei dieser Art von Architektur eine kleine Zeitverzögerung zwischen
der vom Client gesendeten Nachricht und der in die Datenbank eingefügten Nachricht entsteht.
Es wird also eine kleine Zeitverzögerung geben.
Aber für die meisten Anwendungsfälle spielt die Verzögerung diesmal keine Rolle.
Wenn Sie Ihren Profilnamen in einem bestimmten Forum geändert haben und dieser Profilname, sagen wir
nach 2 bis 3 Minuten, aktualisiert wird, spielt das keine Rolle usw.
Es gibt also viele Anwendungsfälle, bei denen dies keine Rolle spielt.
Aber für Anwendungsfälle, in denen eine Zeitverzögerung nicht akzeptabel ist, kann man diese Art von Architektur
vermeiden.
In Prüfungen können Sie also je nach Anwendungsfall die passende Antwort auswählen.
Damit endet unser heutiges Video.