Einheit 5.4: NoSQL Datenbanken (Managed MongoDB)

Einführung

Die relationale Cluster aus Einheit 5.3 verankert die Systeme von FinCorp: Kontostände, Bücher und Transaktionen, bei denen ein festes Schema und eine starke Konsistenz im Vordergrund stehen. Aber nicht jeder FinCorp-Workload benötigt ein festes Schema. Der Fraud-Scoring-Service verarbeitet heterogene Ereignisdokumente, deren Felder je nach Kanal variieren und sich jeden Sprint ändern, und der Customer-360-Service kombiniert verschachtelte Profile-, Zustimmungs- und Interaktionsdaten, die sich sonst über ein Dutzend verbundene Tabellen erstrecken würden. Dies sind Dokument-Workloads, und auf IONOS landen sie auf Managed MongoDB.

Diese Einheit beginnt bei der Modellentscheidung (wann Dokument-Beats-Relationales überwiegt) und der Editionsentscheidung (welche auf eine Weise permanent ist, die wichtig ist), dann wird ein Cluster im Data Center Designer erstellt und mit diesem verbunden. Zwei IONOS-Grenzen prägen jede Designentscheidung hier, daher werden sie offen ausgesprochen und in die Designentscheidung einbezogen: Managed MongoDB bietet keine verwaltete Change-Stream-Replikation an eine zweite Cluster, und die auf Acronis basierende Backup Service sichert keine verwalteten Datenbanken überhaupt.

1. Das Dokumentenmodell und wann es über relationale Modelle hinausgeht

MongoDB speichert Daten als BSON-Dokumente, die in Sammlungen gruppiert sind, ohne ein vorgegebenes Tabellenschema. Das ist der ganze Grund, warum man sich für es entscheidet. Ein Dokument Workload passt, wenn die Datensätze selbstenthaltene Aggregate sind, deren Form variieren oder sich entwickeln, wenn die meisten Lesevorgänge ein reiches, verschachteltes Objekt abrufen, anstatt viele normalisierte Zeilen zu verbinden, und wenn das Schema ohne koordinierte Migration geändert werden muss. Die relationale Ebene bleibt die richtige Antwort, wenn man Multi-Zeilen-ACID-Transaktionen über normalisierte Tabellen, referenzielle Integrität, die von der Engine durchgesetzt wird, oder ad-hoc-SQL-Analytics auf einem stabilen Schema benötigt. Für FinCorp bleibt die Hauptbuchhaltung auf Managed PostgreSQL; der Betrugsereignis-Speicher und der Kunden-360-Aggregat wechseln zu Managed MongoDB, weil ihre Dokumente unregelmäßig sind und ihr Schema sich ständig ändert.

Der IONOS-Datenbank-Manager unterstützt MongoDB-Versionen 6.0 und 7.0, vollständig gemanagt (Provisionierung, Patching, Updates und Überwachung werden von der Plattform gehandhabt). Die Zugriffskontrolle innerhalb der Datenbank verwendet die eigenen, eingebauten Rollen von MongoDB (Lesen, Lesen/Schreiben, LesenJedeDatenbank, SchreibenJedeDatenbank, dbAdmin, dbAdminJedeDatenbank und ClusterMonitor); dies ist eine rollenbasierte Zuweisung auf Datenbankebene, die sich von dem IONOS-Gruppen- und Rechte-Modell unterscheidet, bei dem das Recht "Zugriff und Verwaltung von DBaaS" kontrolliert, wer den Datenbank-Manager überhaupt öffnen darf.

1.1 Editionen und Topologie

Die Editionsentscheidung ist die folgenschwerste in dieser Einheit, da sie effektiv permanent ist. Ein Wechsel von Business zu Enterprise ist eine Plattformmigration (ein manueller Datenwechsel in eine neu bereitgestellte Cluster), kein Resize vor Ort, und Downgrades werden nicht unterstützt. Wählen Sie die Edition für den Zeitpunkt, an dem sich die Workload in einem Jahr befinden wird, nicht für den Zeitpunkt, an dem sie beginnt.

Die folgende Tabelle ist der IONOS-Editionen-Vergleich; verwenden Sie sie, um eine Workload zu platzieren, bevor Sie etwas bereitstellen.

Über den beiden Produktionseditionen steht die Playground-Edition: eine feste 1 vCPU / 2 GB RAM / 50 GB-Einzelinstanz, die für Tests gedacht ist und ausdrücklich von jeder SLA ausgeschlossen ist. Behandeln Sie sie als Sandbox, niemals als Ersatz für eine Produktions-Cluster.

Die Topologie folgt der Edition. Business ist immer ein einzelner Replikatsatz mit einer Node-Zahl von 1 oder 3 (verwenden Sie 3 in der Produktion für Hochverfügbarkeit). Enterprise-Replikatsätze erweitern sich auf 5 oder 7 Knoten für Leseverteilung und Widerstandsfähigkeit, und nur Enterprise kann fragmentieren. Fragmentierung ist horizontale Skalierung: Sammlungen werden nach einem Fragmentierungsschlüssel auf Fragmenten partitioniert, mit einem Minimum von 2 Fragmenten (die Anzahl kann erhöht, aber nicht verringert werden). Jedes fragmentierte Cluster bereitstellt auch automatisch drei Konfigurations-Server-Instanzen (2 Kerne / 4 GB / 40 GB Speicher jede), die von Ihren abgerechneten Ressourcen ausgeschlossen sind; die Gesamtabrechnungsressourcen sind die pro-Node-Ressourcen, multipliziert mit der Anzahl der Instanzen und der Anzahl der Fragmente. Die Aktivierung der Fragmentierung auf einer Sammlung erfordert die enableSharding-Rolle.

Greifen Sie nur auf Fragmentierung zurück, wenn eine einzelne Instanz eine vertikale Grenze erreicht. Eine einzelne Enterprise-Instanz skaliert auf 31 vCPU und 230 GB RAM, unterstützt etwa 114.000 Verbindungen und deckt 30.000 Schreib-IOPS (erreicht bei etwa 600 GB Volume) und etwa 600 MB/s sequenzielle Durchsatz ab. Überschreiten Sie diese Schwellenwerte (Arbeitsmenge über 230 GB, Verbindungsanforderung über etwa 114.000 oder Schreib-IOPS über 30.000) und Sie fragmentieren, um die aggregierte Kapazität über Fragmente zu verteilen; darunter ist ein vertikal skaliertes Replikatsatz einfacher und günstiger. Für FinCorp beginnt der Betrugsereignis-Speicher als 3-Node-Business-Replikatsatz, mit einem dokumentierten Pfad zu Enterprise, wenn die Ereignis-Volume-Größe eine Arbeitsmenge über die einzelne-Node-RAM-Grenze hinaus zwingt. Beachten Sie eine Konsequenz für die Verbindungsbewirtschaftung: IONOS bietet keinen gemanagten Verbindungspooler für MongoDB, sodass die Verbindungsobergrenze ein harter Anwendungsseiten-Budget ist. Treiber müssen Verbindungen selbst poolen.

1.2 Designen um die beiden Grenzen herum

Keine gemanagte Änderungsstrom-Replikation. IONOS bietet keine gemanagte Replikation zwischen Cluster-Instanzen für MongoDB: Sie können nicht eine gemanagte Cluster-Instanz auf eine andere verweisen und die Plattform ändert den Änderungsstrom zwischen ihnen. Das native Muster ist die Anwendungsebene-Änderungserfassung, genau das, was in Einheit 1.3 eingeführt wurde. Die Anwendung (oder ein MongoDB-Änderungsstrom-Verbraucher, den sie ausführt) veröffentlicht Änderungsereignisse an Managed Kafka (Einheit 5.6), und nachgelagerte Verbraucher projizieren diese Ereignisse, wo immer sie benötigt werden. Für FinCorp werden Betrugsbewertungsergebnisse als Ereignisse veröffentlicht, anstatt auf der Datenbankebene repliziert zu werden, was auch der Analyse-Ebene eine saubere Ereignis-Quelle ohne Kopplung an den operativen Speicher gibt.

Backup Service deckt keine gemanagten Datenbanken ab. Der Acronis-basierte Backup Service (Einheit 5.7) schützt nur VMs und Block Storage; er sichert keine Managed MongoDB. Die Datenbankkontinuität wird vollständig durch das eigene Backup-Modell von Cluster geliefert. Die Plattform nimmt ein Basis-Snapshot, wenn die Cluster erstellt wird (anfängliche Synchronisation, normalerweise unter 24 Stunden), nach jedem Wiederherstellen, alle 24 Stunden und ein vollständiges Snapshot jeden Sonntag. Snapshots werden sieben Tage lang aufbewahrt, und Sie können von jedem Snapshot wiederherstellen, das mit der gleichen oder einer älteren MongoDB-Patch-Version erstellt wurde. Die Punkt-in-der-Zeit-Wiederherstellung, die es ermöglicht, zu einem gewählten Zeitpunkt zwischen 1 und 24 Stunden in der Vergangenheit wiederherzustellen (Standard 24 Stunden), ist nur in der Enterprise-Edition verfügbar. Wiederherstellungen erfolgen vor Ort in die gleiche Cluster und können nur die eigenen Snapshots dieser Cluster verwenden; nur ein Wiederherstellungsjob kann gleichzeitig ausgeführt werden, und die Cluster ist während einer Wiederherstellung beschäftigt und darf keine Verbindungen empfangen. Für eine langfristige Aufbewahrung über sieben Tage hinaus oder für die Migration von Daten hin oder her ist der Pfad mongodump / mongorestore, dieselbe Dump-/Wiederherstellungsdisziplin wie die relationale Ebene. Der Oplog unterstützt die Replikation und die Punkt-in-der-Zeit-Wiederherstellung: Größen Sie ihn, um mindestens 24 Stunden Geschichte zu speichern; er kann später ohne Ausfallzeit mit replSetResizeOplog geändert werden. Enterprise-Cluster können auch außerhalb des Standorts Backups in einer Region aufbewahren, die sich von der Region der Cluster selbst unterscheidet (de, eu-south-2, eu-central-3), was der Weg ist, den FinCorp geht, um eine geografisch getrennte Kopie unter deutscher Datenresidenz zu halten.

Managed MongoDB erbt die Standard-DBaaS-SLA-Struktur: Eine HA-Konfiguration mit 3 oder mehr Node-Knoten trägt eine 99,95%-pro-Service-Uptime-Garantie, eine einzelne- oder dual-Node-Cluster-Konfiguration trägt 99,9%, und die Playground-Konfiguration trägt keine SLA. Dies ist ein weiterer Grund, warum der Produktions-Betrugs-Speicher von FinCorp von Tag eins an mit 3 Knoten läuft.

2. DCD Implementierung Schritt-für-Schritt

Wir werden den Betrug-Ereignis-Speicher von FinCorp bereitstellen: ein 3-Node MongoDB Business-Replikatsatz auf dem privaten Daten LAN des bestehenden FinCorp VDC, und dann eine Verbindung von einem in-VDC-Client herstellen. Dies realisiert die Dokumentenebene der geschichteten Architektur, die genau wie die relationale Cluster privat nur hinter der Anwendungsebene sitzt. MongoDB hat keine automatische IP-Adressenverwaltung und das einzige unterstützte Subnetz ist /24, so dass das Netzwerk vorher vorbereitet werden muss.

Voraussetzungen: das FinCorp VDC mit einem dedizierten privaten LAN; mindestens ein Client-Server, der an dieses LAN angeschlossen ist und öffentliche DNS auflösen kann (die Datenbank wird über einen mongodb+srv-Namen erreicht); das Privileg "Zugriff und Verwaltung von DBaaS" in Ihrer Gruppe; und eine kostenlose private IP pro Instanz (drei IPs für ein 3-Node Cluster), die so gewählt werden, dass sie nicht mit dem DHCP-Bereich kollidieren. Auf einem IONOS-DHCP /24 werden Adressen zwischen x.x.x.3/24 und x.x.x.10/24 gewählt, die DHCP nie zuweist.

Ziel: Bereitstellung eines Cluster und Herstellung einer Verbindung.

Schritte (im Data Center Designer):

1. Öffnen Sie den Datenbank-Manager für MongoDB und klicken Sie auf Cluster erstellen. Das Ressourcen-Zuweisungs-Panel zeigt die verwendeten und ungenutzten Vertrags-Contingente; das Cluster wird gegen diese Contingente berechnet.
2. In Eigenschaften setzen Sie einen sinnvollen Cluster-Namen, wählen Sie den Standort (das Rechenzentrum/Region, das die Daten enthält; wählen Sie eine deutsche Region für die FinCorp-Residenz) und wählen Sie die MongoDB-Version (6.0 oder 7.0).
3. Wählen Sie die Edition. Wählen Sie Business, dann wählen Sie ein Template, das die RAM / vCPU / Speicher aus der vordefinierten Liste dimensioniert. (Enterprise stellt anstelle dessen die flexiblen Ressourcen-Schieberegler und die Replikatsatz-gegen-Sharding-Cluster-Wahl sowie den BI-Connector-Schalter bereit; Playground ist die feste kostenlose Sandbox.)
4. Setzen Sie die Anzahl der Node-Instanzen auf 3 Instanzen für den Produktions-Replikatsatz (Business unterstützt 1 oder 3).
5. In Netzwerkkonfiguration wählen Sie das Rechenzentrum und das private Rechenzentrum-LAN aus dem Drop-down-Menü, dann geben Sie eine IP/Subnet pro Instanz ein. Verwenden Sie die kostenlosen privaten IPs, die in den Voraussetzungen reserviert wurden; dies hält das Cluster privat nur.
6. Setzen Sie das Wartungsfenster: Wählen Sie einen Tag und eine Startzeit (UTC). Die Wartung läuft in einem festen 4-Stunden-Fenster, also wählen Sie einen echten niedrigen Verkehrsschlitz anstelle von einem willkürlichen.
7. Überprüfen Sie den geschätzten Preis, dann klicken Sie auf Speichern, um das Cluster bereitzustellen. Das Cluster tritt in einen Erstellungsstatus ein und wird kurz nachher verfügbar.
8. Um eine Verbindung herzustellen, öffnen Sie das Cluster-Details-Tab des Cluster und kopieren Sie die Verbindungs-URI (sie hat die Form mongodb+srv://m-<id>.mongodb.<region>.ionos.com). Von einem Client auf demselben privaten LAN aus führen Sie mongosh gegen diese URI mit Ihrem Datenbank-Benutzernamen und -Passwort aus. Die Verbindung muss von einem in-VDC-Client stammen, da der Endpunkt privat nur ist.

Häufige Fehler:

• Wählen Sie die Edition nicht leichtfertig. Von Business zu Enterprise ist eine manuelle Plattform-Migration, keine Größenänderung, und Downgrades werden nicht unterstützt. Dimensionieren Sie die Edition für die Zukunft des Workload, nicht für seine erste Woche.
• Reservieren und notieren Sie Ihre privaten IPs vor dem Start, eine pro Instanz, innerhalb des sicheren x.x.x.3- bis x.x.x.10-Bereichs auf einem IONOS-DHCP /24. Das einzige unterstützte Subnetz ist /24, und das Cluster führt keine IP-Verwaltung für Sie durch, so dass eine Kollision mit dem DHCP-Bereich oder einem anderen Server den Build bricht.
• 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 stammen. Der Client muss immer noch öffentliche DNS auflösen, um den mongodb+srv-Namen aufzulösen.
• Nehmen Sie nicht an, dass das Backup Service diese Datenbank schützt. Es tut dies nicht. Die Kontinuität ist die eigene Snapshot-Funktion des Cluster (7-Tage-Retention), die Enterprise-only PITR (1 bis 24 Stunden) und mongodump / mongorestore für alles Längere oder für die Migration.
• Setzen Sie ein reales Wartungsfenster. Es ist ein festes 4-Stunden-Schlitz, während dem die verwalteten Operationen laufen, also platzieren Sie es in einem niedrigen Verkehrsschlitz.
• Planen Sie die Verbindungszahlen gegen die pro-Instanz-Obergrenze (etwa 114.000 auf einem 230 GB Enterprise Node) und poolen Sie im Treiber. Es gibt keinen verwalteten Verbindungspooler, der einen Verbindungssturm absorbieren kann.

Zusammenfassung

Managed MongoDB ist FinCorps Dokument-Tier: der Ort für unregelmäßige, schnell evolvierende Aggregate wie den Betrugs-Ereignis-Speicher und den Kunden-360, während die relationale Cluster das Ledger führt. Die Editions-Wahl ist effektiv permanent (Business zu Enterprise ist eine manuelle Migration), sodass sie für die Zukunft dimensioniert ist und die Topologie daraus resultiert: Business ist ein einzelnes Replikats-Set, Enterprise fügt größere Replikats-Sets und Sharding für Workloads hinzu, die die Einzel-Instanz-Grenzen überschreiten. Die Cluster wird privat auf einem /24 LAN mit einem reservierten IP pro Node aufgebaut und über eine mongodb+srv-URI von einem in-VDC-Client erreicht. Zwei Grenzen prägen das Design: keine verwaltete Change-Stream-Replikation, sodass Änderungen über Anwendungsebene-Events in Kafka propagieren, und keine Backup Service-Abdeckung für Datenbanken, sodass die Kontinuität auf den eigenen Snapshots der Cluster, der Enterprise-PITR und dem Dump/Restore basiert.

Wichtige Punkte:

• Wählen Sie Dokument anstelle von relational, wenn Datensätze selbstenthaltene, schema-flexible Aggregate sind, die als ganze Objekte gelesen werden; behalten Sie multi-row ACID und SQL-Analytics auf der relationalen Ebene bei.
• Die Edition ist nahezu permanent: Business (einzelnes Replikats-Set, 1 oder 3 Knoten) vs. Enterprise (5/7-Node-Replikats-Sets, Sharding, BI-Connector, PITR); Business zu Enterprise ist eine manuelle Plattform-Migration, keine Größenanpassung.
• Sharden Sie nur über die Grenzen einer einzelnen Enterprise-Instanz hinaus (230 GB RAM, ~114.000 Verbindungen, 30.000 Schreib-IOPS); Mindestens 2 Shards, plus drei unbilled Konfigurationsserver.
• Stellen Sie privat auf einem /24 LAN mit einem kostenlosen IP pro Instanz im DHCP-sicheren Bereich bereit; verbinden Sie mit mongosh über die mongodb+srv-URI von einem in-VDC-Client.
• Es gibt keine verwaltete Change-Stream-Replikation; propagieren Sie Änderungen mit Anwendungsebene-Event-Veröffentlichung zu Managed Kafka.
• Die Backup Service deckt keine verwalteten Datenbanken ab; die Kontinuität basiert auf den 7-Tages-Snapshots der Cluster, der Enterprise-only-PITR (1 bis 24 Stunden) und mongodump / mongorestore.

Wichtige Begriffe:

• Replikats-Set: eine Gruppe von MongoDB-Instanzen, die Kopien der gleichen Daten für Redundanz und Hochverfügbarkeit halten; die einzige Business-Topologie und die einfachere Enterprise-Topologie.
• Geschachtelte Cluster: eine Enterprise-only-Horizontal-Skalierungs-Topologie, die Sammlungen nach Shard-Schlüssel (mindestens 2 Shards) plus drei unbilled Konfigurationsserver partitioniert.
• Oplog: das Operationen-Log, das die Replikation und die Punkt-in-der-Zeit-Wiederherstellung untermauert; dimensionieren Sie es für mindestens 24 Stunden Geschichte und passen Sie es online mit replSetResizeOplog an.
• PITR (Punkt-in-der-Zeit-Wiederherstellung): Wiederherstellung zu einem gewählten Moment zwischen 1 und 24 Stunden in der Vergangenheit; nur für Enterprise und vor Ort in die gleiche Cluster.