1. Stellen Sie linear skalierbare Oracle Datenbanken bereit, die über Oracle Cloud, Microsoft Azure und Amazon Web Services verteilt sind
  2. Bereitstellung von linear skalierbaren Shard-Datenbanken von Oracle über Oracle Cloud, Microsoft Azure und Amazon Web Services hinweg

Bereitstellung von linear skalierbaren Shard-Datenbanken von Oracle über Oracle Cloud, Microsoft Azure und Amazon Web Services hinweg

Wenn Sie eine Datenbank benötigen, die eine extreme Skalierung mit vollständiger Datenisolierung über verschiedene Cloud-Provider hinweg unterstützt, stellen Sie Sharded-Instanzen von Oracle Database in einer fehlertoleranten Topologie bereit. Sie können die Topologie in Oracle Cloud, Microsoft Azure und Amazon Web Services bereitstellen.

Oracle Sharding ermöglicht Hyperscale-Datenbanken, die weltweit verteilt sind. Sie unterstützt Anwendungen, die lineare Skalierbarkeit, Elastizität, Fehlerisolierung und geografische Verteilung von Daten für Daten-Eigenständigkeit erfordern. Dabei werden Chunks eines Datasets auf unabhängige Oracle-Datenbanken (Shards) verteilt. Sie können Shards in der Cloud oder On Premise bereitstellen, ohne spezielle Hardware oder Software benötigen. Shards kommunizieren zur Laufzeit nicht miteinander in dieser gemeinsam genutzten Architektur, mit der Sie Shards in einer Cloud bereitstellen können, während sich andere Shards in einer anderen Cloud oder On Premise befinden.

Architektur

Die folgende Architektur zeigt eine fehlertolerante Oracle Database 19c-Topologie in Sharding. Die primären Shards werden über Regionen in Oracle Cloud, Microsoft Azure und Amazon Web Services verteilt. Für jeden primären Shard wird ein Standby Shard innerhalb derselben Region bereitgestellt.

Die Architektur verfügt über redundante Ressourcen in jeder Schicht (Shard-Direktor, Katalog und Shards) in jedem Cloud-Provider, um die maximale Verfügbarkeit der Sharded-Datenbank sicherzustellen.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung von sharded-db-oci-azure-aws.png folgt
Beschreibung der Abbildung sharded-db-oci-azure-aws.png

Die Architektur umfasst folgende Komponenten:

  • Internetgateway

    Das Internetgateway ermöglicht Traffic zwischen den öffentlichen Subnetzen und dem öffentlichen Internet. Jeder Cloud-Provider ist mit dem öffentlichen Internet verbunden.

  • Regisseur (Shard)

    Ein Shard-Direktor (auch Global Service Manager genannt) ist ein Netzwerk-Listener, der ein High Performance Connection Routing an die entsprechenden Datenbank-Shards basierend auf Sharding-Schlüsseln ermöglicht.

    Sie können die Anzahl der erforderlichen Shard-Direktoren angeben. Die Shard-Direktoren werden in einzelnen Compute-Instanzen in jedem Cloud-Provider bereitgestellt. Sie können die Ausprägung der Compute-Instanzen auswählen, die für die Shard-Direktoren verwendet werden sollen.

  • Primär- und Standby-Shard-Kataloge

    Ein Shard-Katalog ist eine Oracle Database-Sonderinstanz, die automatisiertes Shard-Deployment, zentralisierte Verwaltung einer Sharded-Datenbank und Abfragen mit mehreren Speicherorten unterstützt.

    Diese Architektur enthält ein Primär-Standby-Paar von Katalogdatenbanken, jeweils in einem Datenbanksystem mit einem Knoten. Sie können die Datenbankausprägung und die verfügbare Speicherkapazität für die Katalogdatenbanken wählen. In jedem Cloud-Provider wird ein Primär-Standby-Paar von Katalogdatenbanken bereitgestellt.

  • Datenbank-Shards

    Jeder Datenbank-Shard ist ein Datenbanksystem mit einem Knoten. Die primären Shards werden über Oracle Cloud, Microsoft Azure und Amazon Web Services verteilt. Jedem primären Shard ist ein Standby Shard zugeordnet.

Empfehlungen

Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für die Bereitstellung von Oracle Database-Shards in Oracle Cloud, Microsoft Azure und Amazon Web Services. Ihre Anforderungen können sich von der hier beschriebenen Architektur unterscheiden.
  • Größe und Anzahl der Shards
    Beim Deployment des Stacks können Sie die zu verwendende Datenbankausprägung und die Anzahl der Shards angeben.
    • Wählen Sie eine geeignete Ausprägung basierend auf Ihren Workload-Anforderungen. Die angegebene Ausprägung wird für alle Shards verwendet.

      Nach dem Deployment können Sie die Form der einzelnen Shards ändern, um sie an Änderungen der Workload anzupassen. Der Shard, für den Sie die Ausprägung ändern, wird gestoppt und dann mit der neuen Ausprägung neu gestartet.

    • Im Allgemeinen bietet eine große Anzahl kleiner Shards eine bessere Gesamtfehlertoleranz als eine geringe Anzahl großer Shards. Um die Topologie zu skalieren oder die Fehlertoleranz zu verbessern, können Sie jederzeit Shards hinzufügen, ohne die Verfügbarkeit der vorhandenen Shards zu beeinträchtigen. Bei Bedarf können Sie in der Sharded-Datenbank skalieren. Der zuletzt erstellte Shard wird zuerst entfernt, nachdem die Daten in die anderen Shards verschoben wurden.
  • Shards Availability

    Um High Availability der Shards sicherzustellen, stellen Sie Standby-Shards bereit und verwenden Oracle Data Guard für die Primär-Standbysynchronisierung und für Failover.

  • Verfügbarkeit des Shard-Katalogs

    Stellen Sie für High Availability des Shard-Katalogs einen Standbykatalog bereit, und verwenden Sie Oracle Data Guard für Synchronisierung und Failover. Beachten Sie, dass sich die Verfügbarkeit des Shard-Katalogs nicht auf die Verfügbarkeit der Sharded-Datenbank auswirkt. Ein Ausfall des Shard-Katalogs wirkt sich nur auf die Möglichkeit aus, Wartungsvorgänge oder Multishard-Abfragen auszuführen, während ein Failover zum Standby-Katalog erfolgt. OLTP-Transaktionen werden weiterhin an die Shards weitergeleitet.

  • Shard Director Availability

    Für High Availability der Shard-Direktorschicht stellen Sie mehrere Shard-Direktoren bereit. Sie können bis zu fünf Shard-Directors in einer Region bereitstellen. Oracle empfiehlt, dass Sie mindestens zwei Shard-Direktoren bereitstellen. In Oracle Cloud empfiehlt Oracle, die Shard-Direktoren in separaten Availability-Domains oder Faultdomains zu isolieren.

  • Speicherung

    Wählen Sie eine Speicherkapazität, die für Ihre Workload geeignet ist. Beispiel: An jeden Datenbank-Shard wird entweder ein lokaler Speicher oder ein Block-Volume einer angegebenen Größe angehängt.

    You can scale up the storage at any time without affecting the availability of the database based on the cloud storage providers capability. For shards located in Oracle Cloud, see the Oracle Cloud Infrastructure Database documentation for more information about storage in Oracle Cloud.

Überlegungen

  • Anwendungsdesign

    Jede Anwendung, die über eine genau definierte Datenverteilungsstrategie verfügt und hauptsächlich über einen Sharding-Schlüssel (z.B. Kunden-ID, Kontonummer usw.) auf Daten zugreift, ist für Sharded-Datenbanken geeignet.

  • Skalierbarkeit

    Nach dem Deployment der Sharded-Datenbank können Sie die Anzahl der Shards erhöhen oder verringern, indem Sie den Stack bearbeiten und die Änderungen anwenden. Je nach Replikationsfaktor, den Sie beim Deployment des Stacks angeben, werden die Standby-Shards ebenfalls skaliert.

    Sie können auch die Anzahl der Shard-Direktoren skalieren.

  • Sicherheit

    Geben Sie beim Deployment der Sharded-Datenbank einen SSH-Public Key an, um sichere SSH-Verbindungen mit den Datenbankservern zu ermöglichen.

    Verwenden Sie gegebenenfalls Firewalls und Proxys basierend auf Ihren speziellen Anwendungsfällen und Sicherheitsanforderungen.

  • Netzwerkisolierung

    Um die Netzwerkisolierung sicherzustellen, sollten Sie die Sharded-Datenbank in einem privaten Subnetz bereitstellen. Routing- und Firewalllösungen müssen basierend auf Ihrem Anwendungsdesign und Ihren Anforderungen bestimmt werden.

Mehr anzeigen

Prüfen Sie die folgenden zusätzlichen Referenzarchitekturen und Lösungs-Playbooks:

Oracle Sharding verwenden (Oracle Database 19c-Dokumentation)