Globale aktive Tabellen in NDCS

Oracle NoSQL Database Cloud Service unterstützt eine globale aktive Tabellenarchitektur, in der Sie Tabellen erstellen, über mehrere Regionen hinweg replizieren und synchronisierte Daten über die regionalen Replikate hinweg verwalten können.

Unternehmen von heute müssen ihren Kunden schnellere und bessere Services bieten. Die Netzwerklatenz ist ein wichtiger Parameter für die Bewertung der Performance jeder Anwendung. Die Netzwerklatenz ist die Mindestzeit, die ein Datenpaket benötigt, um durch das Netzwerk zu reisen. Benutzer erwarten, dass ihre Online-Aktivitäten von überall aus reibungslos und schnell abgeschlossen werden. Um diese Erwartungen zu erfüllen, müssen Unternehmen Anwendungen und Daten in verteilten Regionen hosten, die ihren Benutzern am nächsten sind.

Oracle NoSQL Database Cloud Service bietet über Global Active-Tabellen eine Lösung für diese Anforderungen. Mit dieser Funktion können in einer Region geschriebene Anwendungsdaten transparent über mehrere Regionen hinweg repliziert werden.

Globale aktive Tabellen – Vorteile:

Wie wähle ich ein globales aktives Setup in NDCS aus?

Mit dem Feature für globale aktive Tabellen können in einer Region geschriebene Anwendungsdaten transparent über mehrere Regionen hinweg repliziert werden.

Ein seltenes Ereignis eines Ausfalls einer einzelnen Region sollte sich nicht auf die Benutzererfahrung auswirken. Beispiel: Wenn eine einzelne Region offline, isoliert oder herabgestuft wird, muss die Anwendung in eine andere Region umgeleitet werden und weiterhin Lese- und Schreibvorgänge ausführen. Kurz gesagt, Ihre Datenbank muss ein Disaster Recovery bereitstellen, selbst wenn eine Region ausfällt. Mit einer Global Active-Tabelle in Oracle NoSQL Database Cloud Service (NDCS) können Sie ein Disaster Recovery über eine Active/Active-Konfiguration bereitstellen oder Daten über mehrere Regionen hinweg aktiv replizieren, um mit lokalem Datenzugriff eine geringe Latenz zu erreichen.

Betrachten Sie die Bedürfnisse eines reisenden Benutzers, der von einer beliebten Website einkauft. Sie können am selben Tag auf dieselbe Shopping-Website aus verschiedenen Teilen der Welt zugreifen. Sie müssen sicherstellen, dass die Benutzer eine minimale Latenz und eine nahtlose Interaktion haben, egal wo sie sich befinden.

Das Tabellenfeature "Global Active" in NDCS bietet eine Lösung für beide oben beschriebenen Szenarios. Lassen Sie uns jedes der beiden Szenarios untersuchen und verstehen, wie eine Global Active-Tabelle die beste Lösung sein wird, um High Availability, geringe Latenz und Disaster Recovery bereitzustellen.

Gehen Sie im ersten Szenario davon aus, dass Ihr Unternehmen NDCS in Phoenix (US-West), Frankfurt (Deutschland) und Tokio (Japan) verwendet. In der Tabelle ShoppingCart werden die Einkaufsinformationen von Kunden gespeichert, die in verschiedenen Regionen auf der ganzen Welt einkaufen. In diesem Beispiel betreut Ihr Unternehmen seine Kunden über Rechenzentren, die ihnen geografisch am nächsten stehen. Ein solches Setup umfasst mehrere geografische Standorte, an denen Oracle NoSQL Database Cloud Service verfügbar ist. Eine Architektur mit zwei oder mehr geografisch verteilten Regionen und einem NoSQL Database Cloud-Service, die in jeder dieser Regionen verfügbar sind, wird als globale aktive Tabellenarchitektur bezeichnet. Die Tabelle ShoppingCart ist eine Tabelle "Global Active" und wird in mehreren Regionen repliziert.

In einer Aktiv/Aktiv-Konfiguration ist NDCS in mehreren Regionen verfügbar, und die Daten in allen Regionen werden synchronisiert. Wenn eine Region ausfällt, funktionieren Global Active-Tabellen in den anderen Replikatregionen weiterhin wie gewohnt und sind von der ausgefallenen Region nicht betroffen. Wenn die ausgefallene Region zurückkehrt, wird ihr regionales Tabellenreplikat mit den anderen Regionen synchronisiert. Die Tabelle Global Active bietet ein Disaster Recovery, wenn eine Region heruntergefahren ist, ist Ihre Anwendung mit einem anderen Replikat verbunden.

Im zweiten Szenario nehmen Sie an, dass der Benutzer in Phoenix online einkauft und seinem Warenkorb ein Mobiltelefon hinzufügt. Die NDCS-Region an der Westküste dient dieser Session, und der Benutzer erfährt eine minimale Latenz von Lese- und Schreibanforderungen aus dem lokalen Datenspeicher der Region. Dieser Nutzer steigt dann in ein Flugzeug nach Deutschland, landet 13 Stunden später, kommt ins Hotel, verbindet sich mit dem Wi-Fi-Netzwerk, geht zum Online-Shop des Mobilfunkunternehmens und findet, dass es ein anderes Modell des Telefons gibt, das attraktiver aussieht. So beschließt der Benutzer, den Warenkorb mit diesem neuen Modell des Telefons zu aktualisieren und fährt fort, den mobilen E-Commerce-Shop zu durchsuchen. Der regionale Datenspeicher in Frankfurt, der proximalste Datenspeicher, dient dieser Sitzung und bietet dem Benutzer die gleiche Lese- und Schreiberfahrung mit geringer Latenz wie in den USA. Der Benutzer reist dann nach Japan und beschließt, einen lokalen Mobile Store zu besuchen, um weitere Informationen über die neuesten mobilen Modelle zu erhalten. Der Benutzer aktualisiert dann den Warenkorb mit dem neuesten Modell des Telefons, das im Mobile Store vorhanden ist. Da NoSQL Database Cloud Service in drei Regionen verfügbar ist, eine in Phoenix, eine zweite in Deutschland und eine dritte in Japan, und es gibt mehr als ein regionales Tabellenreplikat, wenn der Benutzer den Warenkorb aktualisiert oder den mobilen E-Commerce-Shop durchsucht, die personalisierten Suchergebnisse und andere Daten aus einer lokalen Region abgerufen werden, die dem Benutzer am nächsten ist. Diese Art der lokalen Verarbeitung bietet die niedrigsten Latenzzeiten, die beste Performance und eliminiert den Weitverkehrsnetzzugriff.

Grundlagen

In globalen aktiven Tabellen verwendete Terminologie:

Grundregeln für das Erstellen und Verwalten von Global Active-Tabellen:

Die folgenden Kriterien müssen für die Erstellung und Verwaltung einer globalen aktiven Tabelle erfüllt sein.

Hinweis: In NDCS wird die regionale Tabellenreplikation asynchron im Hintergrund ausgeführt.

Sie können untergeordnete Tabellen in einer globalen aktiven Tabelle erstellen. Eine untergeordnete Tabelle einer Global Active-Tabelle kann eine Singleton- oder eine Global Active-Tabelle sein. Um die untergeordnete Tabelle zu einer Global Active-Tabelle zu machen, müssen Sie das Schema der untergeordneten Tabelle einfrieren und ein regionales Replikat hinzufügen. Sie können aus einem der regionalen Replikate der übergeordneten Tabelle wählen.

Globale aktive Tabellen - Workflow

Was wird in einer Global Active-Tabelle repliziert?

Wenn Sie ein regionales Tabellenreplikat einer vorhandenen NoSQL-Tabelle hinzufügen, konvertieren Sie die Singleton-Tabelle in eine Global Active-Tabelle. Folgendes wird in einer Tabelle repliziert.

Hinweis: Mit OCI-Tags können Sie Ressourcen Metadaten hinzufügen. Mindestens ein Tag kann mit einer Tabelle "Global Active" verknüpft werden. OCI-Tags werden nicht repliziert, und eine globale aktive Tabelle kann verschiedene Tags in verschiedenen Regionen enthalten.

Regionales Tabellenreplikat hinzufügen

Wenn Sie eine Tabelle replizieren, wird die Tabelle in einer anderen Region erstellt, die als Empfängerregion bezeichnet wird. Wenn die Tabelle im Absenderbereich ein Singleton ist, wird sie in eine Tabelle "Global Active" konvertiert. Wenn die Tabelle im Absenderbereich bereits eine Tabelle "Global Active" ist, wird der Tabelle ein weiteres regionales Replikat hinzugefügt. Das regionale Replikat wird mit den Daten aus der Tabelle der Absenderregion initialisiert. Beispiel: Wenn Ihre Tabelle im Absenderbereich 1000 Zeilen enthält, werden alle Daten in das neu erstellte regionale Replikat kopiert.

Hinweis: Wenn Sie ein regionales Tabellenreplikat hinzufügen, wird die Tabelle in der Empfängerregion in demselben Compartment mit demselben Tabellennamen wie die Tabelle in der Absenderregion platziert. Während der Lebensdauer der Tabelle "Global aktiv" können Sie sie jederzeit in ein anderes Compartment verschieben.

Kapazität (Leseeinheiten, Schreibeinheiten und Speicher) für regionale Tabellenreplikate

Wenn Sie ein regionales Replikat einer Tabelle hinzufügen, werden die Felder Lesekapazität, Schreibkapazität und Speicherkapazität automatisch auf die entsprechenden Werte der Tabelle in der Absenderregion gesetzt. Sie können jedoch die Werte der Lese- und Schreibkapazität der Tabelle im Empfängerbereich bearbeiten und ändern. Die Speicherkapazität der Tabelle kann nicht geändert werden. Die Tabelle im Empfängerbereich hat dieselbe Speicherkapazität wie die Tabelle im Absenderbereich. Der Kapazitätsmodus einer globalen aktiven Tabelle kann bedarfsgesteuert oder bereitgestellt werden. Sie können auch den Kapazitätsmodus jedes regionalen Replikats für eine Global Active-Tabelle ändern, nachdem es erstellt wurde. Die Änderung des Kapazitätsmodus ist für dieses regionale Replikat lokal und wirkt sich nicht auf andere regionale Replikate der Tabelle Global Active aus.

TTL von Datensätzen in regionalen Tabellenreplikationen

Die Gültigkeitsdauer für Tabellen (TTL) wird als die Zeitdauer (Anzahl der Stunden oder Tage) ausgedrückt, in der die Daten in der Tabelle gültig sind. Mit Oracle NoSQL Database Cloud Service können Entwickler eine Ablaufzeit für Tabellenzeilen festlegen, nach der die Zeilen automatisch ablaufen und nicht mehr verfügbar sind. Nach der angegebenen Dauer laufen die Zeilen automatisch ab und sind nicht mehr verfügbar. Die TTL im regionalen Tabellenreplikat entspricht dem TTL der Tabelle in der Absenderregion. Wenn eine Zeile in andere Regionen repliziert wird, wird ihre Ablaufzeit als absoluter Zeitstempel repliziert. Daher läuft diese Zeile gleichzeitig ab, unabhängig davon, wann sie repliziert wurde.

Nachdem ein regionales Tabellenreplikat erstellt wurde, wird es mit den Daten aus der Tabelle der Absenderregion initialisiert. Wenn bei dieser Initialisierung von TTL-Daten der TTL-Wert erreicht wird, laufen diese Zeilen ab, und ein Lesevorgang wird diese Datensätze nicht sehen.

Geltungsbereich von DDL-Vorgängen, nachdem regionale Tabellenreplikate erstellt wurden:

Die folgenden DDL-Vorgänge haben globalen Geltungsbereich. Das bedeutet, dass eine Änderung in einem regionalen Tabellenreplikat automatisch an alle regionalen Tabellenreplikate propagiert wird.

Die folgenden DDL-Vorgänge haben einen lokalen Geltungsbereich, d.h. eine Änderung nur im regionalen Tabellenreplikat, in dem sie initiiert wird.

Überlegungen zur Datenmodellisierung für globale aktive Tabellen

Warum müssen Sie das Schema einer Tabelle einfrieren?

In einer Global Active-Tabellenkonfiguration sind Tabellen in NDCS über mehrere Regionen hinweg bereitgestellt, und alle Regionen verarbeiten gleichzeitig Lese- und Schreibanforderungen. Die Anwendung, die eine Verbindung zu NDCS herstellt, muss so konzipiert sein, dass sie eine Verbindung zur nächstgelegenen Replikationsregion herstellt. Primärschlüssel, Shard-Schlüssel und Daten der Tabelle müssen über Replikationsregionen hinweg identisch sein, da diese drei ein wesentlicher Bestandteil der Verwendung der Tabelle durch die Anwendung und der Ausführung von Abfragen sind. Da die Tabellendatensätze in mehreren Regionen gleichzeitig in die Tabelle geschrieben werden können, muss in einer Tabelle Global Active ein Konsens über das Schema für die Tabelle erzielt werden. Sie können dies tun, indem Sie verhindern, dass sich das Schema ändert, indem Sie alle Regionen in einen sofortigen Konsens über das Schema für eine Tabelle zwingen. Aus Gründen der Einfachheit, Performance und Vorhersehbarkeit muss für Oracle NoSQL Cloud Service ein Schema für alle Tabellen eingefroren werden, die an der regionalen Replikation teilnehmen. Daher muss das Tabellenschema vor der Konvertierung einer Singleton-Tabelle in eine globale aktive Tabelle eingefroren werden, und es sind keine weiteren Schemaänderungen zulässig. Wenn Sie das Schema einer Global Active-Tabelle nach dem Erstellen regionaler Replikate ändern müssen, müssen Sie zunächst alle regionalen Replikate löschen, das Schema der Tabelle ändern und dann die regionalen Replikate erneut hinzufügen. Oracle NoSQL Cloud-Service füllt alle regionalen Replikate erneut mit den aktuellsten Daten aus der Absenderregion auf. Aus diesem Grund wird empfohlen, mindestens eine JSON-Spalte in der Tabelle zu verwenden, da sie mehr Flexibilität im Schema bietet und die Notwendigkeit einer Schemaänderung verhindert.

Identität in einer globalen aktiven Tabelle definieren

Policys und Benutzerberechtigungen

Die IAM-Policys einer Tabelle sind für die Absenderregion spezifisch.

Wenn ein Benutzer ein Replikat einer Singleton-Tabelle oder einer Global Active-Tabelle hinzufügt, wird keine Policy oder Benutzerberechtigung in der Empfängerregion hinzugefügt. Der Benutzer in der Quellregion, der Replikate erstellen und verwalten möchte, muss auch über die erforderlichen Berechtigungen im Empfängerbereich verfügen. Andernfalls wird eine Fehlermeldung angezeigt, wenn der Benutzer ein regionales Tabellenreplikat hinzufügt.

Nachdem die regionalen Tabellenreplikationen erstellt wurden, erfordert das Replizieren von Datenänderungen aus einer Absenderregion in die Empfängerregion keine Benutzerberechtigung. Das bedeutet, dass Datenänderungen in einer Replikattabelle unabhängig von der Benutzerberechtigung in allen anderen Tabellenreplikaten repliziert werden. Die Berechtigungen, die zum Erstellen und Verwalten der regionalen Tabellenreplikate erforderlich sind, werden unten aufgeführt.

Replikat hinzufügen:

Die Benutzer, die Replikate einer Tabelle verwalten möchten, müssen die Berechtigung NOSQL_TABLE_ALTER im Absenderbereich und in allen vorhandenen Empfängerregionen aufweisen. Die Benutzer, die ein neues Replikat erstellen möchten, müssen NOSQL_TABLE_CREATE Berechtigung in der Empfängerregion haben (wo ein Replikat erstellt werden muss). Wenn Sie ein regionales Tabellenreplikat erstellen, wird die vorhandene Lese- und Schreibberechtigung der Tabelle in der Absenderregion nicht im Empfängerbereich erstellt. Die Benutzer, die ein neues Replikat in der Empfängerregion erstellen möchten, sind für die Erstellung der Tabellenlese- und -schreibberechtigungen für jedes regionale Tabellenreplikat verantwortlich, das sie erstellen.

Replikat löschen:

Die Benutzer, die Replikate einer Tabelle verwalten möchten, müssen NOSQL_TABLE_ALTER-Berechtigung in der Absenderregion und allen vorhandenen Empfängerregionen haben. Die Benutzer, die ein Replikat löschen möchten, benötigen NOSQL_TABLE_DROP-Berechtigung in der Empfängerregion (wo ein Replikat gelöscht werden muss).

Index erstellen:

Die Benutzer, die Indizes in regionalen Tabellenreplikationen erstellen möchten, benötigen die Berechtigung NOSQL_INDEX_CREATE.

Index löschen:

Die Benutzer, die Indizes in regionalen Tabellenreplikationen löschen möchten, benötigen die Berechtigung NOSQL_INDEX_DROP.

Tabellenlimits aktualisieren/TTL/:

Die Benutzer, die Replikate einer Tabelle verwalten möchten, müssen in allen regionalen Tabellenreplikationen über NOSQL_TABLE_ALTER-Berechtigung verfügen.

Lese-, Schreib- und ACID-Transaktionen

Nachdem Sie eine Global Active-Tabelle erstellt haben, können Sie mit den vorhandenen Datenzugriffs-APIs oder DML-Anweisungen Lese- oder Schreibvorgänge für die Tabelle ausführen.

Um die beste Latenz zu erzielen, wird Ihre Anwendung in der Regel aus einem lokalen regionalen Replikat gelesen. Die Daten im lokalen regionalen Replikat umfassen auch die Datenupdates, die aus anderen regionalen Tabellenreplikaten repliziert werden. Wenn Sie einen Schreibvorgang (INSERT, UPDATE oder DELETE) für eine Global Active-Tabelle ausführen, werden die Änderungen asynchron über mehrere Regionen hinweg repliziert. Das heißt, wenn Sie eine Zeile im Absenderbereich schreiben, wird der Schreibvorgang vollständig in der Absenderregion ausgeführt, ohne darauf zu warten, dass die Replikatregionen aktualisiert werden. Wenn mehrere Regionen eine Zeile mit demselben Primärschlüssel aktualisieren, wird eine Regel angewendet, um zu entscheiden, welche Regionsaktualisierung als endgültig gilt. In all diesen Fällen führt diese integrierte Konfliktlösungsregel dazu, dass die Aktualisierung mit dem letzten Zeitstempel gewinnt und in der Datenbank festgeschrieben wird. Diese Regel gilt auch, wenn der TTL-Wert aus mehreren Regionen gleichzeitig aktualisiert wird.

ACID-Transaktionen sind lokal in einer Region. Wenn eine Transaktion festgeschrieben wird, ist sie nur in der Region, in der der der Schreibvorgang stattgefunden hat, atomar, konsistent, isoliert und dauerhaft. Die Konsistenzmodellsemantik eines regionalen Tabellenreplikats entspricht der Konsistenzmodellsemantik einer nicht replizierten Tabelle. Die Konsistenz der regionalen Tabellenreplikate ist nicht absolut. Absolute Konsistenz ist lokal in einer Region, in der Sie den Lesevorgang ausführen. Lesezugriffe auf die Daten, die von der Absenderregion in die Empfängerregionen repliziert werden, sind schließlich immer konsistent.

Schreibvorgänge aus einer Absenderregion werden innerhalb einer Zeitverzögerung über alle Empfängerregionen hinweg repliziert. Diese Zeitverzögerung bei der Replikation der Änderungen über mehrere Regionen hinweg umfasst die Zeit, die für den Empfang der Daten aus dem regionalen Tabellenreplikat im Absenderbereich benötigt wird, sowie die Zeit, die für den Abschluss der Schreibvorgänge im Empfängerbereich benötigt wird. Schließlich ruft der Empfängerbereich die Aktualisierung aus dem Absenderbereich ab, und der Empfängerbereich verpasst keine Transaktionsaktualisierung, die im Absenderbereich stattgefunden hat. Alle regionalen Tabellenreplikationen erhalten den Schreibvorgang und werden dauerhaft.

Überblick über Replikatverzögerung

Wenn Sie einen Schreibvorgang (INSERT, UPDATE oder DELETE) für eine Global Active-Tabelle ausführen, werden die Änderungen asynchron über mehrere Regionen hinweg repliziert.

Das heißt, wenn Sie eine Zeile im Absenderbereich schreiben, wird der Schreibvorgang vollständig in der Absenderregion ausgeführt, ohne darauf zu warten, dass die Replikatregionen aktualisiert werden. Die Netzwerklatenz verursacht eine Verzögerung bei der Replikation der Änderungen in den Empfängerregionen. Die Latenz beim Replizieren der Änderungen über mehrere Regionen hinweg umfasst die Zeit, die benötigt wird, um Schreibvorgänge vom Replikat zu empfangen und in der Empfängerregion anzuwenden. Wenn keine Anwendungsschreibvorgänge für die Tabelle im Absenderbereich stattgefunden haben, verwendet der Service die Ping-Mechanismen, um eine Annäherung der Verzögerung zu berechnen, und die Lag-Statistik ist weiterhin im Empfängerbereich verfügbar.

Weitere Details zur Replica Lag-Metrik finden Sie unter Details zur Replica Lag.

Überblick über das Erstellen einer globalen aktiven Tabelle

Der Prozess zum Erstellen einer globalen aktiven Tabelle beginnt mit dem Erstellen einer Singleton-Tabelle und der Konvertierung in eine globale aktive Tabelle

Die Schritte zum Erstellen einer Tabelle "Global Active" werden unten aufgeführt.