MongoDB unterstützt verschiedene Deployment-Modelle, die sich je nach
Anforderungen an Skalierbarkeit, Verfügbarkeit, Performance und
Management unterscheiden. Nachfolgend die wichtigsten Modelle:
6.1 Single Node (Einzelner
Knoten)
6.1.1 Standalone
Beschreibung: Ein einzelner MongoDB-Server ohne
Replikation oder Sharding.
Anwendungsfall: Entwicklungs- und Testumgebungen,
wo Skalierbarkeit und hohe Verfügbarkeit nicht erforderlich sind.
Vorteile: Einfach einzurichten und zu
verwalten.
Nachteile: Keine Ausfallsicherheit, keine
horizontale Skalierung.
6.2 Replica Set
6.2.1 Primary-Secondary-Modell
Ein Replica Set besteht aus mehreren MongoDB-Instanzen:
Primary Node: Bearbeitet Schreiboperationen und
repliziert Änderungen an die sekundären Knoten.
Secondary Nodes: Halten eine Kopie der Daten und
können Leseoperationen ausführen.
Arbiter (optional): Nimmt an der Wahl eines neuen
Primärknotens teil, speichert aber keine Daten.
Funktionalität: - Schreiboperationen erfolgen
ausschließlich auf dem Primary. - Sekundäre Knoten replizieren Daten
asynchron über das Oplog. - Automatisches Failover: Wenn der Primary
ausfällt, wird einer der Secondaries zum neuen Primary gewählt.
Anwendungsfälle: - Szenarien mit hohen
Verfügbarkeitsanforderungen. - Systeme, die Leselast auf mehrere Knoten
verteilen möchten.
Vorteile: - Hohe Verfügbarkeit. - Datenreplikation
für Ausfallsicherheit.
Nachteile: - Zusätzlicher Ressourcenbedarf für
mehrere Knoten.
6.3 Sharded Cluster (Verteilter
Cluster)
Ein Sharded Cluster teilt Daten horizontal über mehrere Shards:
Shard: Speichert einen Teil der Daten; jeder Shard
kann selbst ein Replica Set sein.
Mongos: Routing-Instanz, die Anfragen an die
passenden Shards weiterleitet.
Config Server: Speichert Metadaten über die
Datenverteilung und sorgt für Konsistenz im Cluster.
Funktionalität: - Daten werden basierend auf einem
Shard Key auf Shards verteilt. - Skalierbarkeit durch
Hinzufügen neuer Shards.
Anwendungsfälle: - Große Datenmengen, die nicht auf
einem einzelnen Server gehalten werden können. - Anwendungen mit hoher
Lese- und Schreibleistung.
Vorteile: - Nahezu unbegrenzte horizontale
Skalierung. - Lastverteilung über mehrere Server.
Nachteile: - Komplexere Einrichtung und Verwaltung.
- Effizienz hängt stark von der Wahl des Shard Keys ab.
6.4 Kombinierte Modelle
6.4.1 Sharded Replica Sets
Beschreibung: Jeder Shard in einem Sharded Cluster
ist ein Replica Set.
Vorteile: Kombination aus Skalierbarkeit (Sharding)
und hoher Verfügbarkeit (Replikation).
Anwendungsfälle: Anwendungen, die sowohl hohe
Datenmengen als auch Ausfallsicherheit erfordern.
6.5 Cloud-Modelle
6.5.1 MongoDB Atlas
Beschreibung: Ein vollständig verwalteter
MongoDB-Service, verfügbar auf AWS, Azure und Google Cloud.
Funktionen:
Automatische Skalierung und Backups.
Eingebaute Sicherheit und Monitoring.
Nahtlose Integration mit Cloud-Diensten.
Anwendungsfälle: Unternehmen, die eine einfache
Verwaltung und schnelle Bereitstellung benötigen.
6.5.2 Self-managed in der
Cloud
Beschreibung: Manuelle Verwaltung einer
MongoDB-Instanz in einer Cloud-Umgebung (z. B. AWS EC2, Google Compute
Engine).
Vorteile: Mehr Kontrolle über die
Konfiguration.
Nachteile: Höherer Verwaltungsaufwand.
6.6 Entscheidungskriterien für ein
Deployment-Modell
Datenvolumen und Zugriffsanforderungen: Sharding
für große Datenmengen, Replica Sets für hohe Verfügbarkeit.
Ausfallsicherheit: Replica Sets oder Sharded
Replica Sets.
Einsatzumgebung: Standalone für Entwicklung, Atlas
für einfache Cloud-Deployments.
Kosten: Cloud-Dienste wie Atlas bieten Komfort,
sind aber teurer als Self-managed Lösungen.
Das optimale Deployment-Modell hängt von den spezifischen
Anforderungen der Anwendung, den verfügbaren Ressourcen und den
Skalierungszielen ab.
