<sub class="descriptionSection">08-10-2024 08:15:am // #DBMS // [[Databases]]</sub> ____ Datenbanken können verschieden Architekturen annehmen. Aus der [[Ansi-Sparc Architektur|3-Schicht-Architektur]] von [[DBMS Begriffe#DBS|DBS]] ergeben sich verschiedene Möglichkeiten für den Aufbau eines DBS (meistens abhängig von der Netzwerk-Struktur und den Anforderungen für Programme an Leistung, Reliability, etc.). ## Zentralisiertes DBS / Centralized DBS Ein Zentralisiertes DBS stellt einen Zentralisierten Mainframe da, auf dem **eine** Anwendunge läuft. Auf diesen Mainframe greifen dann alle Clients (Terminal = Clients) zu: ![[Pasted image 20241008081923.png]] ### Vorteile - Hoch Zentralisiert - Einfache Wartung - Einfache Verwaltung ### Nachteile - Hohe Kosten - Niedrige Ausfallsicherheit - Hohe Anforderungen an das Netzwerk unter bestimmten bedingungen ## Verteiltes DBS / Distributed DBS Ein Verteiltes DBS ist vor allem gut, wenn man riesen große Datenmengen hat und ein Server diese nicht mehr verarbeiten kann (passiert in den meisten Fällen nie, man kann eigentlich immer alles über einen SQL Server laufen lassen wenn man die DB gut designed). Es kann auch hilfreich sein um die ausfallsicherheit zu Steigern oder die Auslastung des Netzwerks zu verringern. Verteilte DBS meinen somit einfach nur mehrere logsich zusammengehörige Teil-Datenbanken (oder volle Datenbanken) die entweder in einem Datacenter stehen oder in verschiedenen Ländern / Städten, etc. stehen: ![[Pasted image 20241008082344.png]] Die DBS Knoten haben die Aufgabe, die Verteilung der Daten auf verschieden Standorte Transparent zu halten (d.h der Nutzer denkt er arbeitet an einer zentrallen Datenbank). ### Vorteile - Entlastet Netzwerke - Hohe Fehlerresistenz ### Nachteile - Hohe Komplexität - Hohe Kosten - Nur Schwer Sicherungen möglich - Unvorhersehbare Abfrage Zeiten (also wenn eine Datenbank erstmal um die halbe welt Telefonieren muss nur um eine Row aus einer anderen Tabelle zu holen) - Kann zu sehr komischen Anomalien führen wenn ein Knoten ausfällt ### Gegenargumente Ein Distributed DBS ist nur in sehr wenig fällen wirklich notwendig und sollte nur von wirklichen Profis aufgesetzt und gemanged werden. Ein Beispiel ist der "Github Incident" der in diesem sehr Empfehlenswerten Video beschrieben wird: https://youtu.be/dsHyUgGMht0?si=kZJgHF7Vz1OoyFn_ Hier war ein Knoten für nur 43 **Sekunden** Offline und hat dazugeführt das Github für 1 Tag nicht mehr funktioniert hat. ## Client-Server Architektur Eine Client-Server Architektur ist heutzutage der Standard und auch am einfachsten zu managen. Hier hält ein Server die Daten immer bereit zum abfragen, der Client kann dann "on-demand" die Daten abfragen. - Client und Server können auf dem gleichen Rechner sein - Client und Server können auch in einem Netwzerk Verteilt sein (oder in einem komplett anderen Netzwerk sein) ![[Pasted image 20241008083149.png]] Dies ist bei weitem das verbreiteste Modell und lässt sich auch in die anderen beiden modelle übertragen. ### Vorteile - Weit genutzt - Viel Dokumentation verfügbar - Viele Profis die sich damit auskennen - Niedrige kosten bei richtigem aufsetzen - Wenig Anomalien die nicht durch googeln behoben werden können - Viel Auswahlmöglichkeiten bei DBS ### Nachteile - Für sehr bestimmte use cases nicht ausreichend - Bei Vielen Daten kann dieses System in die knie gehen (aber wir reden hier über Terra bis Peta bytes an daten)