Einheit 5.4: NoSQL-Datenbanken (Managed MongoDB)

Einführung

Das relationale Cluster aus Einheit 5.3 bildet die System of Record für FinCorp: Kontostände, Hauptbücher und Transaktionen, bei denen ein festes Schema und starke Konsistenz im Vordergrund stehen. Nicht jede Workload von FinCorp jedoch benötigt ein festes Schema. Der Fraud-Scoring-Dienst verarbeitet heterogene Ereignisdokumente, deren Felder je nach Kanal unterschiedlich sind und sich mit jedem Sprint weiterentwickeln, während der Customer-360-Dienst verschachtelte Profil-, Einwilligungs- und Interaktionsdaten zusammenführt, die andernfalls über ein Dutzend verknüpfter Tabellen verstreut wären. Es handelt sich um Dokument-Workloads, die auf IONOS CLOUD auf Managed MongoDB abgelegt werden.

Diese Einheit beginnt mit der Modellentscheidung (wann das Dokumentenmodell dem relationalen Modell überlegen ist) und der Editionsentscheidung (die auf eine Weise endgültig ist, die sich auswirkt), baut anschließend ein Cluster im Data Center Designer auf und stellt die Verbindung dazu her. Zwei Grenzen von IONOS CLOUD prägen hier jede Designentscheidung, daher werden sie klar benannt und bei der Planung berücksichtigt: Managed MongoDB bietet keine verwaltete Change-Stream-Replikation zu einem zweiten Cluster, und der auf Acronis basierende Backup Service sichert verwaltete Datenbanken überhaupt nicht ab.

1. Das Dokumentenmodell und wann es gegenüber relationalen Datenbanken geeignet ist

MongoDB speichert Daten als BSON-Dokumente, die in Sammlungen gruppiert sind, ohne ein erzwungenes Tabellenschema. Das ist der eigentliche Grund, diese Datenbank zu wählen. Ein Dokumenten-Workload ist geeignet, wenn die Datensätze selbstständige Aggregatobjekte sind, deren Struktur variiert oder sich entwickelt, wenn die meisten Lesevorgänge ein einzelnes, reichhaltiges verschachteltes Objekt abrufen, anstatt viele normalisierte Zeilen zu verknüpfen, und wenn das Schema ohne koordinierte Migration geändert werden muss. Die relationale Ebene bleibt die richtige Wahl, wenn Sie ACID-Transaktionen über mehrere Zeilen hinweg über normalisierte Tabellen benötigen, eine vom Engine erzwungene referentielle Integrität oder ad-hoc SQL-Analysen auf einem stabilen Schema. Für FinCorp verbleibt das Hauptbuch auf Managed PostgreSQL; der Fraud-Event-Speicher und das Customer-360-Aggregat werden auf Managed MongoDB migriert, da ihre Dokumente unregelmäßig sind und ihr Schema sich ständig ändert.

Der IONOS CLOUD Database Manager unterstützt MongoDB-Versionen 6.0 und 7.0, vollständig verwaltet (Provisioning, Patching, Updates und Monitoring werden von der Plattform übernommen). Die Zugriffskontrolle innerhalb der Datenbank nutzt die eigenen eingebauten Rollen von MongoDB (read, readWrite, readAnyDatabase, readWriteAnyDatabase, dbAdmin, dbAdminAnyDatabase und clusterMonitor); dies ist eine rollenbasierte Zuweisung auf Datenebene, die sich vom IONOS CLOUD-Modell für Gruppen und Berechtigungen unterscheidet, bei dem das Privileg „Access and manage DBaaS" steuert, wer den Database Manager überhaupt öffnen darf.

1.1 Editionen und Topologie

Die Entscheidung über die Edition ist die folgenreichste in dieser Einheit, da sie faktisch dauerhaft ist. Der Wechsel von Business zu Enterprise ist eine Plattformmigration (ein manueller Datenübertrag in ein neu provisioniertes Cluster) und keine In-Place-Größenanpassung, und Downgrades werden nicht unterstützt. Wählen Sie die Edition basierend darauf, wo der Workload in einem Jahr stehen wird, nicht wo er beginnt.

Die folgende Tabelle zeigt den IONOS CLOUD-Editionsvergleich; nutzen Sie sie, um einen Workload zu positionieren, bevor Sie etwas provisionieren.

Über den beiden Produktionseditionen befindet sich Playground: eine feste Instanz mit 1 vCPU / 2 GB RAM / 50 GB, die für Testzwecke bestimmt ist und ausdrücklich von jeder SLA ausgenommen ist. Behandeln Sie sie nur als Sandbox, niemals als Ersatz für ein Produktionscluster im Staging-Umfeld.

Die Topologie folgt der Edition. Business ist immer ein einzelnes Replica Set mit einer Knotenanzahl von 1 oder 3 (verwenden Sie 3 in der Produktion für Hochverfügbarkeit). Enterprise-Replica-Sets unterstützen 1, 3, 5 oder 7 Knoten, wobei 5 oder 7 Knoten für die Leseverteilung und Resilienz vorgesehen sind, und nur Enterprise kann sharding nutzen. Sharding ist horizontale Skalierung: Sammlungen werden über Shards hinweg anhand eines Shard-Schlüssels partitioniert, mit einem Minimum von 2 Shards (die Anzahl kann erhöht, aber nicht verringert werden). Jedes Sharded Cluster provisioniert auch automatisch drei Config-Server-Instanzen (je 2 Kerne / 4 GB / 40 GB Speicher), die von Ihren abgerechneten Ressourcen ausgenommen sind; die gesamt abgerechneten Ressourcen sind die Ressourcen pro Knoten multipliziert mit der Anzahl der Instanzen und der Anzahl der Shards. Das Aktivieren von Sharding für eine Sammlung erfordert die Rolle enableSharding.

Greifen Sie nur dann zu Sharding, wenn eine einzelne Instanz an eine vertikale Grenze stößt. Eine einzelne Enterprise-Instanz skaliert bis zu 31 vCPU und 230 GB RAM, unterstützt etwa 114.000 Verbindungen und erreicht eine Obergrenze von 30.000 Schreib-IOPS (erreicht bei einem Volumen von etwa 600 GB) und etwa 600 MB/s sequenziellen Durchsatz. Überschreiten Sie diese Schwellenwerte (Arbeitsbereich über 230 GB, Verbindungsbedarf über ~114.000 oder Schreib-IOPS über 30.000), und Sie sharding, um die Kapazität über Shards zu aggregieren; darunter ist ein vertikal skaliertes Replica Set einfacher und günstiger. Für FinCorp beginnt der Fraud-Event-Speicher als 3-Knoten-Business-Replica-Set, mit einem dokumentierten Weg zu Enterprise, falls das Event-Volumen den Arbeitsbereich über die RAM-Grenze eines einzelnen Knotens zwingt. Beachten Sie eine Konsequenz für das Verbindungsmanagement: IONOS CLOUD bietet keinen verwalteten Connection Pooler für MongoDB, daher ist die Verbindungsobergrenze ein hartes Budget auf Anwendungsebene. Treiber müssen Verbindungen selbst poolen.

1.2 Design um die zwei Grenzen herum

Keine verwaltete Change-Stream-Replikation. IONOS CLOUD bietet keine verwaltete Cross-Cluster-Replikation für MongoDB: Sie können ein verwaltetes Cluster nicht auf ein anderes zeigen und die Plattform zwischen ihnen Änderungen streamen lassen. Das native Muster ist die Change-Erfassung auf Anwendungsebene, genau der Ersatz, der in Einheit 1.3 eingeführt wurde. Die Anwendung (oder ein MongoDB-Change-Stream-Consumer, den sie ausführt) veröffentlicht Change-Events an Managed Kafka (Einheit 5.6), und Downstream-Consumer projizieren diese Events dorthin, wo sie benötigt werden. Für FinCorp werden Fraud-Scoring-Ergebnisse als Events veröffentlicht, anstatt auf der Datenschicht repliziert zu werden, was der Analytik-Ebene auch einen sauberen Event-Feed ohne Kopplung an den operativen Speicher bietet.

Backup Service deckt verwaltete Datenbanken nicht ab. Der auf Acronis basierende Backup Service (Einheit 5.7) schützt nur VMs und Block Storage; er sichert Managed MongoDB nicht ab. Die Datenbankkontinuität wird vollständig durch das eigene Backup-Modell des Clusters bereitgestellt. Die Plattform erstellt einen Basis-Snapshot, wenn das Cluster erstellt wird (Initial-Sync, normalerweise unter 24 Stunden), nach jedem Restore, alle 24 Stunden und einen vollständigen Snapshot jeden Sonntag. Snapshots werden sieben Tage aufbewahrt, und Sie können von jedem Snapshot mit derselben oder einer älteren MongoDB-Patch-Version wiederherstellen. Point-in-Time-Recovery, die es Ihnen ermöglicht, zu einem gewählten Zeitpunkt zwischen 1 und 24 Stunden in der Vergangenheit wiederherzustellen (Standard 24 Stunden), ist nur für Enterprise verfügbar. Restores erfolgen in-place in dasselbe Cluster und können nur die eigenen Snapshots dieses Clusters verwenden; nur ein Restore-Job läuft gleichzeitig, und das Cluster ist während eines Restore beschäftigt und darf keine Verbindungen empfangen. Für eine langfristige Aufbewahrung über sieben Tage hinaus oder für die Migration von Daten hinein oder heraus, ist der Weg mongodump / mongorestore, dieselbe Dump/Restore-Disziplin wie in der relationalen Ebene. Der Oplog bildet die Grundlage für Replikation und PITR: dimensionieren Sie ihn so, dass er mindestens 24 Stunden Historie hält; er kann später ohne Downtime mit replSetResizeOplog neu dimensioniert werden. Enterprise-Cluster können auch Offsite-Backups in einer Region ablegen, die sich von der eigenen Region des Clusters unterscheidet (de, eu-south-2, eu-central-3), so hält FinCorp eine geografisch getrennte Kopie unter deutscher Datenresidenz.

Managed MongoDB erbt die Standard-DBaaS-SLA-Struktur: eine HA-Konfiguration mit 3 oder mehr Knoten hat eine Uptime-Verpflichtung von 99,95 % pro Service, ein Cluster mit einem oder zwei Knoten hat 99,9 %, und Playground hat keine SLA. Dies ist ein weiterer Grund, warum der Produktions-Fraud-Speicher von FinCorp ab Tag eins 3 Knoten betreibt.

2. DCD-Implementierung: Schritt-für-Schritt-Anleitung

Wir provisionieren den Fraud-Event-Store von FinCorp: einen 3-Knoten-MongoDB-Business-Replikatsatz auf dem privaten Daten-LAN des bestehenden FinCorp-VDC. Anschließend verbinden wir uns von einem Client innerhalb des VDC damit. Damit wird die Dokumentenebene der geschichteten Architektur umgesetzt, die, genau wie das relationale Cluster, ausschließlich privat hinter der Anwendungsebene liegt. MongoDB bietet kein automatisches IP-Adressmanagement, und das einzige unterstützte Subnetz ist /24. Daher muss das Netzwerk zuerst vorbereitet werden.

Voraussetzungen: Der FinCorp-VDC mit einem dedizierten privaten LAN; mindestens ein an dieses LAN angeschlossener Client-Server, der öffentlichen DNS auflösen kann (die Datenbank wird über einen mongodb+srv-Namen erreicht); das Recht „Access and manage DBaaS“ in Ihrer Gruppe; und eine freie private IP pro Instanz (drei IPs für ein 3-Knoten-Cluster), ausgewählt so, dass sie nicht mit dem DHCP-Bereich kollidieren. Bei einem IONOS CLOUD DHCP /24 wählen Sie Adressen zwischen x.x.x.3/24 und x.x.x.10/24. Diese werden von DHCP nie zugewiesen.

Bauziel: Ein Cluster provisionieren und eine Verbindung herstellen.

Schritte (im Data Center Designer):

1. Öffnen Sie den Database Manager für MongoDB und klicken Sie auf Create cluster. Das Panel Resource allocation zeigt die genutzte und ungenutzte Vertragsquote. Das Cluster wird darauf angerechnet.
2. Setzen Sie unter Properties einen aussagekräftigen Cluster Name, wählen Sie den Location (das Rechenzentrum / die Region, in der die Daten liegen; wählen Sie für die Datenhaltung von FinCorp eine deutsche Region) und wählen Sie die MongoDB Version (6.0 oder 7.0).
3. Wählen Sie die Edition. Wählen Sie Business und wählen Sie dann ein Template, das RAM / vCPU / Speicher aus der vordefinierten Liste dimensioniert. (Enterprise bietet stattdessen flexible Ressourcenregler sowie die Wahl zwischen Replikatsatz und sharded Cluster und den BI Connector-Schalter. Playground ist die feste kostenlose Sandbox.)
4. Setzen Sie die Knotenanzahl auf 3 instances für den Produktionsreplikatsatz (Business unterstützt 1 oder 3).
5. Wählen Sie unter Network configuration das Datacenter und das private Datacenter LAN aus dem Dropdown und geben Sie pro Instanz eine IP/Subnet ein. Verwenden Sie die in den Voraussetzungen reservierten freien privaten IPs. Dadurch bleibt das Cluster ausschließlich privat.
6. Setzen Sie das Maintenance window: Wählen Sie einen Day und eine Start Time (UTC). Wartung läuft in einem festen 4-Stunden-Fenster ab. Wählen Sie daher ein echtes Zeitfenster mit geringem Traffic, statt es beliebig zu lassen.
7. Prüfen Sie den geschätzten Preis und klicken Sie dann auf Save, um zu provisionieren. Das Cluster wechselt in einen Erstellungszustand und ist kurz darauf verfügbar.
8. Um eine Verbindung herzustellen, öffnen Sie den Tab Cluster details des Clusters und kopieren Sie die Connection URI (sie hat die Form mongodb+srv://m-<id>.mongodb.<region>.ionos.com). Führen Sie von einem Client auf demselben privaten LAN mongosh gegen diese URI mit Ihrem Datenbankbenutzernamen und -Passwort aus. Die Verbindung muss von einem Client innerhalb des VDC ausgehen, da der Endpunkt nur privat ist.

Häufige Fehler:

• Wählen Sie die Edition nicht leichtfertig. Der Wechsel von Business zu Enterprise ist eine manuelle Plattformmigration, kein Resize, und Downgrades werden nicht unterstützt. Dimensionieren Sie die Edition für die Zukunft der Workload, nicht für die erste Woche.
• Reservieren und dokumentieren Sie Ihre privaten IPs, bevor Sie beginnen, eine pro Instanz, innerhalb des sicheren Bereichs von x.x.x.3 bis x.x.x.10 auf einem IONOS CLOUD DHCP /24. Das einzige unterstützte Subnetz ist /24. Das Cluster übernimmt kein IP-Management für Sie. Eine Kollision mit dem DHCP-Bereich oder einem anderen Server bricht den Build.
• Versuchen Sie nicht, das Cluster von außerhalb des VDC zu erreichen, oder erwarten Sie einen öffentlichen Endpunkt. Die Verbindung muss von einem Client auf demselben privaten LAN ausgehen. Der Client muss weiterhin öffentlichen DNS auflösen, um den mongodb+srv-Namen zu ermitteln.
• Gehen Sie nicht davon aus, dass der Backup Service diese Datenbank schützt. Er tut es nicht. Kontinuität wird durch die eigenen Snapshots des Clusters (7-Tage-Retention), PITR nur in Enterprise (1 bis 24 Stunden) sowie mongodump / mongorestore für längere Zeiträume oder für Migrationen sichergestellt.
• Setzen Sie ein echtes Wartungsfenster. Es ist ein festes 4-Stunden-Fenster, in dem verwaltete Operationen ausgeführt werden. Legen Sie es in eine Zeit mit geringem Traffic.
• Planen Sie die Verbindungsanzahl gegen die Obergrenze pro Instanz (etwa 114.000 auf einem 230-GB-Enterprise-Knoten) und verwenden Sie Pooling im Treiber. Es gibt keinen verwalteten Connection Pooler, der einen Verbindungsschwall auffängt.

Zusammenfassung

Managed MongoDB ist die Dokumentenebene von FinCorp: der Ort für unregelmäßige, schnelllebige Aggregatstrukturen wie den Betrugsvorfallspeicher und customer-360, während das relationale Cluster das Hauptbuch verwaltet. Die Editionswahl ist de facto dauerhaft (der Wechsel von Business zu Enterprise ist eine manuelle Migration), daher wird die Dimensionierung auf die Zukunft ausgelegt, und die Topologie leitet sich daraus ab: Business ist ein einzelner Replikat-Satz, Enterprise ergänzt größere Replikat-Sätze und Sharding für Workloads, die die Grenzen einer einzelnen Instanz überschreiten. Das Cluster wird ausschließlich privat auf einem /24 LAN mit einer reservierten IP pro Knoten aufgebaut und über eine mongodb+srv URI von einem Client innerhalb des VDC erreicht. Zwei Grenzen prägen das Design: keine verwaltete Change-Stream-Replikation, daher werden Änderungen über anwendungsebene Ereignisse in Kafka propagiert, und keine Abdeckung durch den Backup Service für Datenbanken, daher beruht die Kontinuität auf den eigenen Snapshots des Clusters, Enterprise-PITR und Dump/Restore.

Wichtige Punkte:

• Wählen Sie die Dokumenten- statt der relationale Ebene, wenn Datensätze selbstständige, schema-flexible Aggregatstrukturen sind, die als ganze Objekte gelesen werden; behalten Sie mehrzeilige ACID-Transaktionen und SQL-Analysen auf der relationalen Ebene.
• Die Edition ist nahezu dauerhaft: Business (einzelner Replikat-Satz, 1 oder 3 Knoten) vs. Enterprise (Replikat-Sätze mit 1/3/5/7 Knoten, Sharding, BI Connector, PITR); der Wechsel von Business zu Enterprise ist eine manuelle Plattformmigration, keine Größenanpassung.
• Sharding ist erst erforderlich, wenn die Grenzen einer einzelnen Enterprise-Instanz überschritten werden (230 GB RAM, ca. 114.000 Verbindungen, 30.000 Schreib-IOPS); mindestens 2 Shards, plus drei nicht abrechenbare Konfigurationsserver.
• Bereitstellen Sie ausschließlich privat auf einem /24 LAN mit einer freien IP pro Instanz im DHCP-sicheren Bereich; verbinden Sie sich mit mongosh über die mongodb+srv URI von einem Client innerhalb des VDC.
• Es gibt keine verwaltete Change-Stream-Replikation; propagieren Sie Änderungen über die Veröffentlichung von Ereignissen auf Anwendungsebene in Managed Kafka.
• Der Backup Service deckt verwaltete Datenbanken nicht ab; die Kontinuität wird durch die 7-Tage-Snapshots des Clusters, das nur für Enterprise verfügbare PITR (1 bis 24 Stunden) und mongodump / mongorestore gewährleistet.

Wichtige Begriffe:

• Replikat-Satz: eine Gruppe von MongoDB-Instanzen, die Kopien derselben Daten für Redundanz und Hochverfügbarkeit hält; die einzige Topologie für Business und die einfachere Topologie für Enterprise.
• Geshardetes Cluster: eine nur für Enterprise verfügbare Topologie für horizontale Skalierung, die Sammlungen anhand eines Shard-Schlüssels auf Shards verteilt (mindestens 2 Shards) plus drei nicht abrechenbare Konfigurationsserver.
• Oplog: das Operationstagebuch, das Replikation und Wiederherstellung zu einem bestimmten Zeitpunkt stützt; dimensionieren Sie es für mindestens 24 Stunden Historie und passen Sie die Größe online mit replSetResizeOplog an.
• PITR (Wiederherstellung zu einem bestimmten Zeitpunkt): Wiederherstellung zu einem gewählten Zeitpunkt zwischen 1 und 24 Stunden in der Vergangenheit; nur für Enterprise verfügbar und direkt in dasselbe Cluster.