Verteiltes DBMS - Datenbankumgebungen
In diesem Teil des Tutorials werden wir die verschiedenen Aspekte untersuchen, die beim Entwerfen verteilter Datenbankumgebungen hilfreich sind. Dieses Kapitel beginnt mit den Arten verteilter Datenbanken. Verteilte Datenbanken können in homogene und heterogene Datenbanken mit weiteren Unterteilungen eingeteilt werden. Im nächsten Abschnitt dieses Kapitels werden die verteilten Architekturen Client-Server, Peer-to-Peer und Multi-DBMS erläutert. Schließlich werden die verschiedenen Entwurfsalternativen wie Replikation und Fragmentierung vorgestellt.
Arten verteilter Datenbanken
Verteilte Datenbanken können grob in homogene und heterogene verteilte Datenbankumgebungen mit jeweils weiteren Unterteilungen unterteilt werden, wie in der folgenden Abbildung dargestellt.
Homogene verteilte Datenbanken
In einer homogen verteilten Datenbank verwenden alle Standorte identische DBMS- und Betriebssysteme. Seine Eigenschaften sind -
Die Websites verwenden sehr ähnliche Software.
Die Sites verwenden identisches DBMS oder DBMS desselben Herstellers.
Jede Site kennt alle anderen Sites und arbeitet mit anderen Sites zusammen, um Benutzeranforderungen zu verarbeiten.
Der Zugriff auf die Datenbank erfolgt über eine einzelne Schnittstelle, als wäre es eine einzelne Datenbank.
Arten von homogenen verteilten Datenbanken
Es gibt zwei Arten homogen verteilter Datenbanken:
Autonomous- Jede Datenbank ist unabhängig und funktioniert für sich. Sie werden von einer steuernden Anwendung integriert und verwenden die Nachrichtenübermittlung, um Datenaktualisierungen gemeinsam zu nutzen.
Non-autonomous - Die Daten werden auf die homogenen Knoten verteilt, und ein zentrales oder Master-DBMS koordiniert die Datenaktualisierungen über die Standorte hinweg.
Heterogene verteilte Datenbanken
In einer heterogenen verteilten Datenbank haben verschiedene Standorte unterschiedliche Betriebssysteme, DBMS-Produkte und Datenmodelle. Seine Eigenschaften sind -
Verschiedene Sites verwenden unterschiedliche Schemata und Software.
Das System kann aus einer Vielzahl von DBMS bestehen, z. B. relational, netzwerk-, hierarchisch oder objektorientiert.
Die Abfrageverarbeitung ist aufgrund unterschiedlicher Schemata komplex.
Die Transaktionsverarbeitung ist aufgrund unterschiedlicher Software komplex.
Eine Site kennt möglicherweise keine anderen Sites und daher besteht eine eingeschränkte Zusammenarbeit bei der Verarbeitung von Benutzeranforderungen.
Arten heterogen verteilter Datenbanken
Federated - Die heterogenen Datenbanksysteme sind von Natur aus unabhängig und so integriert, dass sie als ein einziges Datenbanksystem fungieren.
Un-federated - Die Datenbanksysteme verwenden ein zentrales Koordinierungsmodul, über das auf die Datenbanken zugegriffen wird.
Verteilte DBMS-Architekturen
DDBMS-Architekturen werden im Allgemeinen in Abhängigkeit von drei Parametern entwickelt:
Distribution - Es gibt die physische Verteilung der Daten auf die verschiedenen Standorte an.
Autonomy - Es gibt die Verteilung der Kontrolle über das Datenbanksystem und den Grad an, in dem jedes konstituierende DBMS unabhängig arbeiten kann.
Heterogeneity - Es bezieht sich auf die Einheitlichkeit oder Unähnlichkeit der Datenmodelle, Systemkomponenten und Datenbanken.
Architekturmodelle
Einige der gängigen Architekturmodelle sind -
- Client-Server-Architektur für DDBMS
- Peer-to-Peer-Architektur für DDBMS
- Multi-DBMS-Architektur
Client-Server-Architektur für DDBMS
Dies ist eine zweistufige Architektur, bei der die Funktionalität in Server und Clients unterteilt ist. Die Serverfunktionen umfassen hauptsächlich Datenverwaltung, Abfrageverarbeitung, Optimierung und Transaktionsverwaltung. Client-Funktionen umfassen hauptsächlich Benutzeroberfläche. Sie verfügen jedoch über einige Funktionen wie Konsistenzprüfung und Transaktionsverwaltung.
Die zwei verschiedenen Client-Server-Architekturen sind -
- Single Server Multiple Client
- Multiple Server Multiple Client (in der folgenden Abbildung dargestellt)
Peer-to-Peer-Architektur für DDBMS
In diesen Systemen fungiert jeder Peer sowohl als Client als auch als Server für die Vermittlung von Datenbankdiensten. Die Peers teilen ihre Ressourcen mit anderen Peers und koordinieren ihre Aktivitäten.
Diese Architektur hat im Allgemeinen vier Ebenen von Schemata -
Global Conceptual Schema - Zeigt die globale logische Ansicht von Daten.
Local Conceptual Schema - Zeigt die logische Datenorganisation an jedem Standort.
Local Internal Schema - Zeigt die physische Datenorganisation an jedem Standort an.
External Schema - Zeigt die Benutzeransicht von Daten.
Multi-DBMS-Architekturen
Dies ist ein integriertes Datenbanksystem, das aus einer Sammlung von zwei oder mehr autonomen Datenbanksystemen besteht.
Multi-DBMS kann durch sechs Schemaebenen ausgedrückt werden -
Multi-database View Level - Zeigt mehrere Benutzeransichten, die aus Teilmengen der integrierten verteilten Datenbank bestehen.
Multi-database Conceptual Level - Zeigt eine integrierte Multi-Datenbank, die globale logische Multi-Datenbank-Strukturdefinitionen enthält.
Multi-database Internal Level - Zeigt die Datenverteilung über verschiedene Standorte und die Zuordnung mehrerer Datenbanken zu lokalen Daten.
Local database View Level - Zeigt die öffentliche Ansicht lokaler Daten.
Local database Conceptual Level - Zeigt die lokale Datenorganisation an jedem Standort.
Local database Internal Level - Zeigt die physische Datenorganisation an jedem Standort an.
Es gibt zwei Entwurfsalternativen für Multi-DBMS:
- Modell mit konzeptioneller Ebene für mehrere Datenbanken.
- Modell ohne konzeptionelle Ebene mit mehreren Datenbanken.
Designalternativen
Die Verteilungsentwurfsalternativen für die Tabellen in einem DDBMS lauten wie folgt:
- Nicht repliziert und nicht fragmentiert
- Vollständig repliziert
- Teilweise repliziert
- Fragmented
- Mixed
Nicht repliziert und nicht fragmentiert
Bei dieser Entwurfsalternative werden verschiedene Tabellen an verschiedenen Standorten platziert. Die Daten werden so platziert, dass sie sich in unmittelbarer Nähe des Standorts befinden, an dem sie am häufigsten verwendet werden. Es eignet sich am besten für Datenbanksysteme, bei denen der Prozentsatz der Abfragen, die zum Verknüpfen von Informationen in Tabellen an verschiedenen Standorten erforderlich sind, gering ist. Wenn eine geeignete Verteilungsstrategie angewendet wird, hilft diese Entwurfsalternative, die Kommunikationskosten während der Datenverarbeitung zu reduzieren.
Vollständig repliziert
Bei dieser Entwurfsalternative wird an jedem Standort eine Kopie aller Datenbanktabellen gespeichert. Da jeder Standort über eine eigene Kopie der gesamten Datenbank verfügt, sind Abfragen sehr schnell und erfordern vernachlässigbare Kommunikationskosten. Im Gegenteil, die massive Redundanz der Daten erfordert enorme Kosten bei Aktualisierungsvorgängen. Dies ist daher für Systeme geeignet, bei denen eine große Anzahl von Abfragen bearbeitet werden muss, während die Anzahl der Datenbankaktualisierungen gering ist.
Teilweise repliziert
Kopien von Tabellen oder Teilen von Tabellen werden an verschiedenen Standorten gespeichert. Die Verteilung der Tabellen erfolgt entsprechend der Zugriffshäufigkeit. Dies berücksichtigt die Tatsache, dass die Häufigkeit des Zugriffs auf die Tabellen von Standort zu Standort erheblich variiert. Die Anzahl der Kopien der Tabellen (oder Teile) hängt davon ab, wie häufig die Zugriffsabfragen ausgeführt werden und von welcher Site die Zugriffsabfragen generiert werden.
Fragmentiert
Bei diesem Entwurf ist eine Tabelle in zwei oder mehr Teile unterteilt, die als Fragmente oder Partitionen bezeichnet werden, und jedes Fragment kann an verschiedenen Orten gespeichert werden. Dies berücksichtigt die Tatsache, dass es selten vorkommt, dass alle in einer Tabelle gespeicherten Daten an einem bestimmten Standort erforderlich sind. Darüber hinaus erhöht die Fragmentierung die Parallelität und bietet eine bessere Notfallwiederherstellung. Hier gibt es nur eine Kopie jedes Fragments im System, dh keine redundanten Daten.
Die drei Fragmentierungstechniken sind -
- Vertikale Fragmentierung
- Horizontale Fragmentierung
- Hybridfragmentierung
Gemischte Verteilung
Dies ist eine Kombination aus Fragmentierung und Teilreplikationen. Hier werden die Tabellen zunächst in irgendeiner Form (horizontal oder vertikal) fragmentiert, und dann werden diese Fragmente je nach Häufigkeit des Zugriffs auf die Fragmente teilweise über die verschiedenen Standorte hinweg repliziert.