Migrierte MongoDB-Workload in Oracle Autonomous JSON Database bereitstellen

Migrieren Sie eine vorhandene Workload, die eine Dokumentendatenbank (in diesem Fall MongoDB) verwendet, zu Oracle Autonomous JSON Database auf Oracle Cloud Infrastructure (OCI), um die Entwicklung Ihrer JSON-zentrierten Anwendungen zu modernisieren.

Workloads und Anwendungen, die Dokumente und Dokumentdatenbanken verwenden, um Datenschemas und Anwendungen zu entwickeln, sind aufgrund der Flexibilität, die sie Entwicklern bieten, sehr beliebt. Schemaflexibilität, schnelle Entwicklung und Skalierbarkeit ermöglichen ein schnelles Prototyping von Anwendungsfunktionen, eine einfachere Anwendungsentwicklung und die Sicherheit, iterativ kleinere Anwendungen und Funktionen zu erstellen, die Entwickler skalieren können, um eine große Benutzerbasis zu erreichen. Diese Arten von Workloads haben jedoch ihre Herausforderungen, darunter schwächere Transaktionsgarantien, Vielseitigkeit der Datenabfrage und die Unfähigkeit, andere Workloads in Dokumenten wie Analysen oder maschinelles Lernen zu unterstützen.

Was wäre, wenn diese Workloads von allen Vorteilen herkömmlicher Dokumentendatenbanken profitieren könnten, aber gleichzeitig die Vorteile relationaler Datenbanken nutzen könnten? Verfügen Sie beispielsweise über stärkere Transaktionsgarantien und nutzen Sie zusätzliche Funktionen wie Analysen und maschinelles Lernen, ohne dass Daten in eine andere Datenbank oder ein anderes System repliziert werden müssen.

Autonomous JSON Database bietet Dokument-APIs im NoSQL-Stil (Simple Oracle Document Access (SODA) und Oracle Database API for MongoDB), serverlose Skalierung, leistungsstarke ACID-Transaktionen, umfassende Sicherheit und niedrige Pay-per-Use-Preise. Autonome JSON-Datenbank automatisiert Provisioning, Konfiguration, Optimierung, Skalierung, Patching, Verschlüsselung und Reparatur von Datenbanken, eliminiert das Datenbankmanagement und bietet eine Verfügbarkeit von 99,95%.

Funktionale Architektur

Diese Architektur setzt als Ausgangspunkt voraus, dass eine Workload mit einer Anwendung und einer MongoDB-Datenbank entweder ein On-Premise- oder Cloud-Deployment besteht und zu OCI migriert wird. Es beschreibt die zukünftige Statusarchitektur, ihre Vorteile, wie sie bereitgestellt werden kann und welche zusätzlichen Features zur Erweiterung der vorhandenen Workload verwendet werden können.

Eines der Hauptfeatures, die in dieser Architektur verwendet werden, ist die Oracle Database-API für MongoDB, mit der Anwendungen mit Sammlungen von JSON-Dokumenten in Oracle Database mit MongoDB-Treibern, -Tools und -SDKs interagieren können. Vorhandener Anwendungscode kann mit in Autonomous JSON Database gespeicherten Daten arbeiten, ohne dass sie neu berechnet werden müssen.

Das folgende Diagramm zeigt eine typische Anwendung, die aus einer Datenbank-, Backend- und Frontend-Tier besteht.

Beschreibung der Abbildung mongodb-json-logical-arch-migration.png

mongodb-json-logical-arch-migration-oracle.zip

Ein beliebter Stack, der zur Implementierung dieses Musters verwendet wird, ist der MEAN-Stack, der MongoDB als Dokumentdatenbank, Express als Backend-Framework, Angular als Frontend-Framework und Node.js als Backend-Server verwendet. In diesem Dokument wird ein MEAN-Stack als Beispiel für ein vorhandenes Deployment verwendet, das zu OCI und Autonomous JSON Database migriert wird.

Die Migration dieser Workload zu OCI und Autonomous JSON Database ist unkompliziert und umfasst auf hoher Ebene die folgenden Schritte:

1. Stellen Sie eine Autonomous JSON Database-Instanz bereit, um die Oracle Database Mongo DB-API beim Erstellen zu ermöglichen
2. Migrieren Sie Metadaten und Daten aus MongoDB in Autonomous JSON Database.
3. Stellen Sie Anwendungsserver bereit, um Node.js und Express mit VMs, Containern oder Kubernetes in derselben Region und Availability-Domain wie Autonomous JSON Database auszuführen.
4. Stellen Sie den Backend-Anwendungscode auf den Anwendungsservern bereit.
5. Verbinden Sie die Backend-Anwendung mit autonomen JSON-Datenbank mit denselben MongoDB-Tools und -Treibern, die in der aktuellen Anwendung verwendet werden.
6. Benutzer sollen sich bei der neuen Anwendungs-URI anmelden.

Diese Referenzarchitektur konzentriert sich auf das Deployment der migrierten Workload und nicht auf den Migrationsprozess selbst. Weitere Informationen zum Migrationsprozess finden Sie im Abschnitt Weitere Informationen.

Nachdem die Workload in eine autonome JSON-Datenbank migriert wurde, können Sie mehrere Features verwenden, um die vorhandene Funktionalität zu erweitern, unabhängig davon, ob diese auf 1) zusätzliche nicht funktionale Anforderungen unterstützt, wie z. B. einfache Verbesserung der Skalierbarkeit, Resilienz oder Hochverfügbarkeit oder 2) zusätzliche Funktionsfunktionen wie Betriebsberichte, Analysen und maschinelles Lernen vorhanden sind, ohne dass Daten aus der Datenbank kopiert werden müssen.

Um die Skalierbarkeit und High Availability zu verbessern, verwenden Sie das Autoscaling-Feature Autonomous JSON Database, mit dem die Workload mit einem einzigen Klick oder API-Aufruf bis zum 3-fachen der Basiskapazität ohne Ausfallzeiten nutzen kann. Beachten Sie, dass Autonomous JSON Database die Oracle Real Application Clusters-(Oracle RAC-)Technologie für High Availability verwendet. Verwenden Sie für die Backend-Tier Compute-Instanzpools mit Autoscaling-Regeln, um High Availability und Skalierbarkeit für Anwendungen zu ermöglichen.

Da die autonome JSON-Datenbank auf einer Multimodell-, Multi-Workload-Datenbanktechnologie basiert, können zusätzliche Funktionen hinzugefügt werden, die auf relationalen, räumlichen, Diagramm- oder Vektordatentypen basieren und neben der vorhandenen Anwendung arbeiten. Es ist üblich, dass Benutzer Analysen über JSON-Daten durchführen und SQL in Autonomous JSON Database verwenden möchten, um die Erstellung betrieblicher und analytischer Berichte mit derselben Engine und denselben Daten zu vereinfachen.

Autonomous JSON Database hat ein Limit von 20 GB an Nicht-JSON-Daten, kann aber einfach in Autonomous Transaction Processing Serverless konvertiert werden. Dabei werden dieselben Features unterstützt, wenn sich die Anforderungen an das Datenvolumen ändern. Do note that Views and Materialized Views storage doesn't count towards the Autonomous JSON Database 20 Gb non-JSON data limit, so those can be easily created and used, for instance, to support operational analytics using SQL on top of JSON documents.

Physische Architektur

Die physische Architektur umfasst öffentliche und private Subnetze in OCI mit einer sekundären Backupregion zur Unterstützung von High Availability.

Die Architektur unterstützt Folgendes:

• Frontend-Tier
  • Anwendungsbenutzer können über das Internet oder das Unternehmensnetzwerk eine Verbindung herstellen
  • Benutzerverbindung wird mit einer Web Application Firewall gesichert
  • Die Benutzerverbindung zur Anwendung wird für mehr Resilienz und Skalierbarkeit belastet
  • Load Balancer wird mit High Availability bereitgestellt
• Backend-Tier
  • Anwendungsserver werden mit einem Instanzpool in High Availability bereitgestellt
  • Instanzpool wird mit Autoscaling verwendet, um horizontale Skalierbarkeit zu erreichen
  • Instanzpool ist so konfiguriert, dass Instanzen in derselben Availability-Domain wie die autonome JSON-Datenbank bereitgestellt werden, sodass Anwendungs- und Datenbank-Colocation vorhanden ist und somit die Verbindungslatenz optimiert wird
  • Instanzpool ist so konfiguriert, dass Instanzen über Faultdomains in derselben Availability-Domain verteilt werden, in der die autonome JSON-Datenbank gespeichert ist, um die Workload-Resilienz zu erhöhen
• Datenbankebene
  • Autonomous JSON Database bietet High Availability, da Oracle Real Application Clusters (Oracle RAC) und mehrere Datenbankknoten die Serviceinstanz untermauern. Daher ist die Datenbankebene standardmäßig hochverfügbar und resilient.
  • Mit der Oracle Database-API für MongoDB, die in Autonomous JSON Database aktiviert ist, können Sie vorhandenen Anwendungscode ohne Änderungen verwenden.
  • Die Oracle Database-API für MongoDB ist äußerst resilient und diese Resilienz wird intern von der Autonomous JSON Database garantiert.
  • Autonome JSON-Datenbank kann Autoscaling verwenden und sich an Erhöhungen und Verringerungen der Systemlast anpassen.
  • Die Geschäftskontinuität der autonomen JSON-Datenbank wird durch eine regionsübergreifende Notfallwiederherstellung auf Backupbasis erreicht. Alternativ können Sie aktualisierbare Klone verwenden.
• Disaster Recovery
  • Zwei Regionen unterstützen regionsübergreifendes Disaster Recovery für das gesamte Cloud-Deployment.
  • Die autonome JSON-Datenbank in der primären Region verfügt über einen regionsübergreifenden Backup-Peer in der sekundären Region.
  • Die zweite Region wird mit einer ähnlichen Topologie bereitgestellt, um das Gesamtziel für die Recovery-Zeit zu reduzieren.
  • Um das allgemeine RTO zu reduzieren, können Sie eine Warm-DR-Strategie verwenden, bei der die Cloud-Ressourcen der Backend-Tier bereits bereitgestellt sind, sowie die Standbydatenbank der autonomen JSON-Datenbank.
  • Alternativ können Sie die Backend-Tierressourcen im Falle eines Fehlers bereitstellen. Dadurch werden die Kosten für die Ausführung der DR-Ressourcen gesenkt, aber das RTO insgesamt erhöht.
  • Mögliche Designverbesserungen, die in diesem Deployment aus Gründen der Einfachheit nicht dargestellt werden, umfassen die Verwendung von OCI Full Stack Disaster Recovery zur Automatisierung der Disaster Recovery für den Load Balancer und die Backend-Tier.
• Networking
  • Die in beiden Regionen bereitgestellten dynamischen Routinggateways werden per Peering verglichen.
  • On-Premise-Konnektivität nutzt sowohl OCI FastConnect als auch Site-to-Site-VPN für Redundanz.
  • Der gesamte eingehende Traffic von On Premise und vom Internet wird zuerst an das Hub-VCN und dann an das Workload-VCN weitergeleitet.
  • Verwendet ein Hub- und Spoke-Netzwerkdesign, um den Sicherheitsstatus zu erhöhen und andere Workload-VCNs aufzunehmen.
  • Services werden mit privaten Endpunkten bereitgestellt, um den Sicherheitsstatus zu erhöhen.
  • Das JSON-Workload-VCN ist in mehrere private Subnetze unterteilt, um den Sicherheitsstatus zu erhöhen.
• Sicherheit

  Alle Daten sind während der Übertragung und im Ruhezustand sicher.

• Mögliche Designverbesserungen, die in diesem Deployment aus Gründen der Einfachheit nicht dargestellt werden, umfassen die Verwendung einer vollständigen CIS-konformen Landing Zone und die Nutzung einer Netzwerkfirewall, die im Hub-VCN bereitgestellt ist. Eine Netzwerkfirewall verbessert die allgemeine Sicherheitslage, indem der gesamte Datenverkehr geprüft und Richtlinien durchgesetzt werden.

Das folgende Diagramm veranschaulicht diese Architektur.

Beschreibung der Abbildung mongodb-json-physical-arch.png

mongodb-json-physical-arch-oracle.zip

Die Architektur umfasst folgende Komponenten:

• Region

  Eine OCI-Region ist ein lokalisierter geografischer Bereich, der mindestens ein Data Centre enthält, das Availability-Domains hostet. Regionen sind unabhängig von anderen Regionen, und große Entfernungen können über Länder oder Kontinente voneinander getrennt werden.

• Virtuelles Cloud-Netzwerk (VCN) und Subnetze

  Ein VCN ist ein anpassbares, softwaredefiniertes Netzwerk, das Sie in einer OCI-Region einrichten. Wie herkömmliche Data Center-Netzwerke erhalten Sie über VCNs die Kontrolle über Ihre Netzwerkumgebung. Ein VCN kann mehrere nicht überschneidende CIDR-Blöcke aufweisen, die Sie nach dem Erstellen des VCN ändern können. Sie können ein VCN in Subnetze segmentieren, die sich auf eine Region oder eine Availability-Domain beschränken. Jedes Subnetz besteht aus einem Bereich zusammenhängender Adressen, die sich nicht mit anderen Subnetzen im VCN überschneiden. Sie können die Größe eines Subnetzes nach der Erstellung ändern. Ein Subnetz kann öffentlich oder privat sein.

• FastConnect

  Oracle Cloud Infrastructure FastConnect erstellt eine dedizierte, private Verbindung zwischen Ihrem Data Center und OCI. FastConnect bietet Optionen höherer Bandbreite und ein zuverlässigeres Netzwerk als bei internetbasierten Verbindungen.

• Dynamisches Routinggateway (DRG)

  Das DRG ist ein virtueller Router, der einen Pfad für den privaten Netzwerktraffic zwischen VCNs in derselben Region zwischen einem VCN und einem Netzwerk außerhalb der Region bereitstellt, z.B. ein VCN in einer anderen OCI-Region, ein On-Premise-Netzwerk oder ein Netzwerk in einem anderen Cloud-Provider.

• Network Address Translation-(NAT-)Gateway

  Mit einem NAT-Gateway können private Ressourcen in einem VCN auf Hosts im Internet zugreifen, ohne diese Ressourcen für eingehende Internetverbindungen verfügbar zu machen.

• Servicegateway

  Ein Servicegateway ermöglicht den Zugriff von einem VCN auf andere Services, wie Oracle Cloud Infrastructure Object Storage. Der Datenverkehr vom VCN zum Oracle-Service wird über die Oracle-Netzwerkstruktur geleitet und durchläuft nicht das Internet.

• Internetgateway

  Ein Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen in einem VCN und dem öffentlichen Internet.

• Load Balancer

  Oracle Cloud Infrastructure Load Balancing bietet eine automatisierte Trafficverteilung von einem einzigen Einstiegspunkt auf mehrere Server.

• Web Application Firewall

  Oracle Cloud Infrastructure Web Application Firewall (WAF) ist ein regionaler Edge-Enforcement Service, der an einen Enforcement Point angehängt ist, wie einen Load Balancer oder einen Domainnamen einer Webanwendung. WAF schützt Anwendungen vor schädlichem und unerwünschtem Internettraffic. Mit WAF können Sie jeden internetseitigen Endpunkt schützen und eine konsistente Regeldurchsetzung über Ihre Anwendungen hinweg ermöglichen.

• Anwendungsserver

  Anwendungsserver verwenden einen sekundären Peer, der wie die Datenbank die Verarbeitung im Katastrophenfall übernimmt. Anwendungsserver verwenden Konfiguration und Metadaten, die sowohl in der Datenbank als auch im Dateisystem gespeichert sind. Das Application Server-Clustering bietet Schutz im Geltungsbereich einer einzelnen Region. Für ein konsistentes Disaster Recovery müssen jedoch fortlaufend laufende Änderungen und neue Deployments an den sekundären Speicherort repliziert werden.

• Oracle Database API für MongoDB

  Mit der Oracle Database-API für MongoDB können Anwendungen mit Sammlungen von JSON-Dokumenten in Oracle Database mit MongoDB-Treibern, -Tools und -SDKs interagieren.

• Autonomous JSON Database

  Oracle Autonomous JSON Database ist ein Cloud-Dokumentdatenbankservice, mit dem Sie ganz einfach JSON-zentrierte Anwendungen entwickeln können. Es bietet einfache Dokument-APIs, serverlose Skalierung, leistungsstarke ACID-Transaktionen, umfassende Sicherheit und niedrige Pay-per-Use-Preise. Autonome JSON-Datenbank automatisiert das Provisioning, die Konfiguration, Optimierung, Skalierung, Patching, Verschlüsselung und Reparatur der Datenbank.

• Objektspeicher

  OCI Object Storage bietet Zugriff auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und sicher direkt aus dem Internet bzw. aus der Cloud-Plattform speichern. Sie können den Storage skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird.

  Verwenden Sie den Standardspeicher für "Hot Storage", auf die Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicherung für "Cold Storage", die Sie über lange Zeiträume beibehalten und nur selten darauf zugreifen.

Architekturvariante

Die vollständig verwaltete MongoDB-API, die von Autonomous JSON Database bereitgestellt wird, ist die beste Lösung für die meisten Workloads, da sie einfacher zu verwalten ist.

Wenn die Konfiguration und Verwaltung von Oracle REST Data Services manuell gesteuert werden muss, ist die Verwendung von vom Kunden verwalteten Oracle REST Data Services eine Option. Beispiel: Damit die Anwendung größere Connection Pools verwenden kann.

Hinweis:

Verwenden Sie diese Architekturvariante, wenn dafür eine bestimmte Workload erforderlich ist. Nur fortgeschrittene Benutzer sollten diese Architekturvariante bereitstellen.

In diesem Abschnitt werden nur die Unterschiede zur zuvor beschriebenen physischen Architektur beschrieben. Daher sind alle Prinzipien des physischen Architekturdesigns gültig, sofern nicht anders angegeben.

Das folgende Architekturdiagramm zeigt, wie die Variante bereitgestellt wird. Der Einfachheit halber werden nur die im JSON-Workload-VCN bereitgestellten Cloud-Ressourcen dargestellt, da der Rest des Deployments mit dem zuvor beschriebenen identisch ist.

Beschreibung der Abbildung mongodb-json-arch-variant.png

mongodb-json-arch-variant-oracle.zip

Folgendes ist die Frontend-Ebene für die Variante:

• Backend-Anwendungscode wird auf Anwendungsservern bereitgestellt, die Teil eines Instanzpools sind.
• Die eingehenden Benutzeranforderungen werden vom Load Balancer verteilt, sodass die Frontend-Tier horizontal skalierbar ist und keinen einzelnen Fehlerpunkt aufweist.
• Vom Kunden verwaltete Oracle REST Data Services wird auf jedem Anwendungsserver installiert und so konfiguriert, dass die API MongoDB aktiviert wird, sodass die Anwendung mit MongoDB-Tools und -Treibern eine Verbindung zur Datenbank herstellen kann.
• Vom Kunden verwaltete Oracle REST Data Services sind so konfiguriert, dass sie an die nicht funktionalen Workload-Anforderungen angepasst werden. Beispiel: Sie konfigurieren größere Connection Pools oder verwenden einen anderen Datenbankservice.
• Sowohl der Backend-Code als auch die vom Kunden verwalteten Oracle REST Data Services sind in der vom Pool verwendeten Instanzkonfiguration vorinstalliert und vorkonfiguriert. So kann eine Instanz nach dem Instanz-Provisioning immer dann das Backend ausführen und eine Verbindung zur Datenbank herstellen, wenn sie dem Pool hinzugefügt wird.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt, um die Workload weiter zu verbessern und weiterzuentwickeln. Ihre Anforderungen können von der hier beschriebenen Architektur abweichen.

• VCN

  Wenn Sie ein VCN erstellen, bestimmen Sie die Anzahl der erforderlichen CIDR-Blöcke und die Größe jedes Blocks basierend auf der Anzahl der Ressourcen, die Sie an Subnetze im VCN anhängen möchten. Verwenden Sie CIDR-Blöcke, die sich innerhalb des standardmäßigen privaten IP-Adressraums befinden.

  Wählen Sie CIDR-Blöcke aus, die sich mit keinem anderen Netzwerk (in Oracle Cloud Infrastructure, Ihrem On-Premise-Data Center oder einem anderen Cloud-Provider) überschneiden, zu dem Sie private Verbindungen einrichten möchten.

  Nachdem Sie ein VCN erstellt haben, können Sie die zugehörigen CIDR-Blöcke ändern, hinzufügen und entfernen.

  Berücksichtigen Sie beim Entwerfen der Subnetze den Verkehrsfluss und die Sicherheitsanforderungen. Hängen Sie alle Ressourcen innerhalb einer bestimmten Tier oder Rolle an dasselbe Subnetz an, das als Sicherheitsgrenze dienen kann.

• Anwendungs-Deployment

  Sie sollten ein containerbasiertes Deployment mit Oracle Kubernetes Engine (OKE) verwenden, wenn die Anwendung in Containern ausgeführt werden kann.

• Sicherheit

  Verwenden Sie Data Safe, um den Sicherheitsstatus der Workload weiter zu erhöhen und Datenbankauditing ausführen zu können.

• Beobachtbarkeit
  • Ziehen Sie die Verwendung von OCI Audit in Betracht, um forensisches Auditing für alle OCI-Services außerhalb der Autonomous JSON Database durchzuführen.
  • Verwenden Sie Monitoring, Logging und Logging Analytics, um einen vollständigen Überblick über den Betriebsstatus der Umgebung zu erhalten.
• Disaster Recovery

  Ziehen Sie die Verwendung von OCI Full Stack Disaster Recovery in Betracht, um die Disaster und Recovery aller Layer des Stacks zu automatisieren und zu orchestrieren.

• Betriebliche Effizienz
  • Verwenden Sie Elastic Pools, wenn die Autonomous JSON-Workload Teil einer größeren Datenbankflotte ist, um die Kosteneffizienz zu steigern.
  • Aktivieren Sie Database Management, einen OCI-Service, der umfassende Features zur Überwachung und Verwaltung der Datenbankperformance bereitstellt, um das AJD-Instanzmanagement zu optimieren.
• Anwendungsentwicklung
  • Stellen Sie Betriebsanalysen und Echtzeitberichte in Autonomous JSON Database mit SQL und einem Frontend wie APEX oder Oracle Analytics Cloud bereit, ohne Daten aus der Datenbank zu verschieben, für eine vertrauenswürdige Datenanalyse in Echtzeit
  • Verwenden Sie Autonomous JSON Database für maschinelles Lernen mit Oracle Machine Learning (OML), um Modelle mit JSON-Daten zu erstellen und zu trainieren, ohne dass Daten verschoben werden müssen, und um die Modelle neben der vorhandenen Workload für eine effiziente Inferenzierung bereitzustellen
  • Bei zusätzlichen Anwendungsfällen, die über den Anwendungskern hinausgehen, sollten Sie Autonomous JSON Database verwenden. KI- und Datenbankansichten auswählen, die JSON abfragen und Metadaten enthalten, damit Benutzer JSON-Daten in natürlicher Sprache abfragen können
  • Verwenden Sie Autonomous JSON Database, um zusätzliche Datentypen (relational, vektor, räumlich oder grafisch) bis zu 20 GB zu speichern, um zusätzliche Workload-Funktionalität und Flexibilität zu erhalten.

Mehr erfahren

Weitere Informationen zu den Features dieser Architektur:

• Oracle Datenplattform
• Autonome JSON-Datenbank
• Oracle Database API für MongoDB
• Migration einer MongoDB-Datenbank, die auf MongoDB Atlas oder On Premise ausgeführt wird, zu Oracle Autonomous JSON Database (Tutorial)
• Vom Kunden verwaltete Oracle REST Data Services in Autonomous Database

Prüfen Sie die folgenden zusätzlichen Ressourcen:

• Oracle Cloud Infrastructure-Dokumentation
• Gut durchdachte Framework-Architektur für Oracle Cloud Infrastructure
• Oracle Cloud-Kostenrechner
• Cloud Adoption Framework
• Moderne App-Entwicklung

Bestätigungen

• Autoren: José Cruz
• Mitwirkende: Massimo Castelli, Simon Griffith, Hermann Baer, Matt DeMarco, Julian Dontcheff