Oracle NoSQL Database-Migrator verwenden
Erfahren Sie mehr über Oracle NoSQL Database Migrator und wie Sie ihn für die Datenmigration verwenden.
Oracle NoSQL Database Migrator ist ein Tool, mit dem Sie Oracle NoSQL-Tabellen von einer Datenquelle in eine andere migrieren können. Dieses Tool kann für Tabellen in Oracle NoSQL Database Cloud Service, Oracle NoSQL Database On Premise und AWS S3 verwendet werden. Das Migrator-Tool unterstützt verschiedene Datenformate und physische Medientypen. Unterstützte Datenformate sind JSON-, Parquet-, JSON-formatierte MongoDB-, JSON-formatierte DynamoDB- und CSV-Dateien. Unterstützte physische Medientypen sind Dateien, OCI Object Storage, Oracle NoSQL Database On Premise, Oracle NoSQL Database Cloud Service und AWS S3.
Dieser Artikel enthält die folgenden Themen:
Verwandte Themen
Überblick
Mit dem Oracle NoSQL Database-Migrator können Sie Oracle NoSQL-Tabellen von einer Datenquelle in eine andere verschieben, wie Oracle NoSQL Database On Premise oder Cloud oder sogar eine einfache JSON-Datei.
Es kann viele Situationen geben, in denen Sie NoSQL-Tabellen von oder zu einer Oracle NoSQL Database migrieren müssen. Beispiel: Ein Entwicklerteam, das eine NoSQL-Datenbankanwendung erweitert, möchte möglicherweise seinen aktualisierten Code in der lokalen Oracle NoSQL Database Cloud Service-(NDCS-)Instanz mit cloudim testen. Um alle möglichen Testfälle zu überprüfen, müssen sie die Testdaten ähnlich den tatsächlichen Daten einrichten. Dazu müssen sie die NoSQL-Tabellen aus der Produktionsumgebung in ihre lokale NDCS-Instanz, die cloudim-Umgebung, kopieren. In einer anderen Situation müssen NoSQL-Entwickler ihre Anwendungsdaten möglicherweise für die Entwicklung oder für Tests von On Premise in die Cloud und umgekehrt verschieben.
In all diesen und vielen weiteren Fällen können Sie mit Oracle NoSQL Database Migrator Ihre NoSQL-Tabellen von einer Datenquelle in eine andere verschieben, wie Oracle NoSQL Database On-Premise oder Cloud oder sogar eine einfache JSON-Datei. Sie können auch NoSQL-Tabellen aus einer JSON-Eingabedatei im Format MongoDB, einer DynamoDB-formatierten JSON-Eingabedatei (entweder in der AWS-Quelle S3 oder aus Dateien gespeichert) oder einer CSV-Datei in Ihre NoSQL-Datenbank On-Premise oder Cloud kopieren.
Wie in der folgenden Abbildung dargestellt, fungiert das Utility NoSQL Database Migrator als Connector oder Pipe zwischen der Datenquelle und dem Ziel (als Sink bezeichnet). Im Wesentlichen exportiert dieses Utility Daten aus der ausgewählten Quelle und importiert diese Daten in die Senke. Dieses Tool ist tabellenorientiert, d.h. Sie können die Daten nur auf Tabellenebene verschieben. Eine einzelne Migrationsaufgabe wird für eine einzelne Tabelle ausgeführt und unterstützt die Migration von Tabellendaten von der Quelle zum Senken in verschiedenen Datenformaten.
Mit Oracle NoSQL Database-Migrator verwendete Terminologie
Erfahren Sie mehr über die verschiedenen Begriffe, die im obigen Diagramm verwendet werden, im Detail.
- Quelle: Eine Entity, aus der die NoSQL-Tabellen für die Migration exportiert werden. Beispiele für Quellen sind Oracle NoSQL Database On-Premise oder Cloud, JSON-Datei, MongoDB-formatierte JSON-Datei, DynamoDB-formatierte JSON-Datei und CSV-Dateien.
- Sink: Eine Entity, die NoSQL-Tabellen aus NoSQL Database Migrator importiert. Beispiele für Senken sind Oracle NoSQL Database On Premise oder Cloud- und JSON-Datei.
Das NoSQL Database Migrator-Tool unterstützt verschiedene Typen von Quellen und Senken (d.h. physische Medien oder Repositorys von Daten) und Datenformaten (d.h. die Daten werden in der Quelle oder Senke dargestellt). Unterstützte Datenformate sind JSON-, Parquet-, JSON-formatierte MongoDB-, JSON-formatierte DynamoDB- und CSV-Dateien. Unterstützte Quell- und Sink-Typen sind Dateien, OCI Object Storage, Oracle NoSQL Database On Premise und Oracle NoSQL Database Cloud Service.
- Migrations-Pipe: Die Daten aus einer Quelle werden vom NoSQL Database Migrator an die Senke übertragen. Dies kann als Migration Pipe visualisiert werden.
- Transformationen: Sie können Regeln hinzufügen, um die Tabellendaten in der NoSQL-Pipe zu ändern. Diese Regeln werden Transformationen genannt. Der Oracle NoSQL Database-Migrator ermöglicht Datentransformationen nur in Feldern oder Spalten der obersten Ebene. Sie können die Daten in den verschachtelten Feldern nicht transformieren. Beispiele für zulässige Transformationen:
- Löschen oder ignorieren Sie eine oder mehrere Spalten,
- Benennen Sie eine oder mehrere Spalten um, oder
- Aggregieren Sie mehrere Spalten in einem einzelnen Feld, in der Regel ein JSON-Feld.
- Konfigurationsdatei: In einer Konfigurationsdatei definieren Sie alle für die Migrationsaktivität erforderlichen Parameter im JSON-Format. Später übergeben Sie diese Konfigurationsdatei als einzelnen Parameter über die CLI an den Befehl
runMigrator. Ein typisches Konfigurationsdateiformat sieht wie unten dargestellt aus.{ "source": { "type" : <source type>, //source-configuration for type. See Source Configuration Templates . }, "sink": { "type" : <sink type>, //sink-configuration for type. See Sink Configuration Templates . }, "transforms" : { //transforms configuration. See Transformation Configuration Templates . }, "migratorVersion" : "<migrator version>", "abortOnError" : <true|false> }Gruppieren Parameter Erforderlich (J/N) Zweck Unterstützte Werte sourcetypeY Stellt die Quelle dar, aus der die Daten migriert werden sollen. Die Quelle stellt Daten und Metadaten (sofern vorhanden) für die Migration bereit. Informationen zum Wert typefür jede Quelle finden Sie unter Unterstützte Quellen und Sinks.sourceQuellkonfiguration für Typ Y Definiert die Konfiguration für die Quelle. Diese Konfigurationsparameter sind spezifisch für den oben ausgewählten Quelltyp. Eine vollständige Liste der Konfigurationsparameter für jeden Quelltyp finden Sie unter Quellkonfigurationsvorlagen. sinktypeY Stellt die Senke dar, zu der die Daten migriert werden sollen. Die Sink ist das Ziel oder das Ziel für die Migration. Informationen zum Wert typefür jede Quelle finden Sie unter Unterstützte Quellen und Sinks.sinksink-Konfiguration für Typ Y Definiert die Konfiguration für die Senke. Diese Konfigurationsparameter sind spezifisch für den oben ausgewählten Sinkentyp. Eine vollständige Liste der Konfigurationsparameter für jeden Sink-Typ finden Sie unter Sinkkonfigurationsvorlagen. transformstransformiert die Konfiguration N Definiert die Transformationen, die auf die Daten in der Migrations-Pipe angewendet werden sollen. Die vollständige Liste der Transformationen, die vom Datenmigrator NoSQL unterstützt werden, finden Sie unter Transformationskonfigurationsvorlagen. - migratorVersionN Version des Datenmigrators NoSQL - - abortOnErrorN Gibt an, ob die Migrationsaktivität bei Fehlern gestoppt werden soll.
Der Standardwert ist true. Dies bedeutet, dass die Migration gestoppt wird, wenn ein Migrationsfehler auftritt.
Wenn Sie diesen Wert auf false setzen, wird die Migration auch bei nicht erfolgreichen Datensätzen oder anderen Migrationsfehlern fortgesetzt. Die nicht erfolgreichen Datensätze und Migrationsfehler werden im CLI-Terminal als WARNINGs protokolliert.
True, False Hinweis:
Da bei der JSON-Datei die Groß-/Kleinschreibung beachtet wird, wird bei allen in der Konfigurationsdatei definierten Parametern die Groß-/Kleinschreibung beachtet, sofern nicht anders angegeben.
Unterstützte Quellen und Sinks
Dieses Thema enthält die Liste der Quellen und Senken, die vom Oracle NoSQL Database-Migrator unterstützt werden.
Sie können eine beliebige Kombination aus einer gültigen Quelle und Sink aus dieser Tabelle für die Migrationsaktivität verwenden. Sie müssen jedoch sicherstellen, dass mindestens eines der Enden, d.h. Quelle oder Sink, ein Oracle NoSQL-Produkt sein muss. Mit dem NoSQL-Datenbankmigrator können Sie die Tabellendaten der Datei NoSQL nicht von einer Datei in eine andere verschieben.
|
Typ |
Format |
Gültige Quelle | Gültiger Sink |
|---|---|---|---|
|
Oracle NoSQL Database |
- | Y | Y |
|
Oracle NoSQL Database Cloud Service |
- | Y | Y |
|
Dateisystem |
JSON |
Y | Y |
|
MongoDB JSON |
Y | N | |
|
DynamoDB JSON |
Y | N | |
|
Parquet( |
N | Y | |
|
CSV |
Y | N | |
|
OCI Object Storage |
JSON |
Y | Y |
|
MongoDB JSON |
Y | N | |
|
Parquet( |
N | Y | |
|
CSV |
Y | N | |
| AWS S3 |
DynamoDB JSON |
Y | N |
Hinweis:
Viele Konfigurationsparameter sind in der Quell- und Sink-Konfiguration gemeinsam. Zur einfacheren Referenzierung wird die Beschreibung solcher Parameter für jede Quelle und Sink in den Dokumentationsabschnitten wiederholt, die Konfigurationsdateiformate für verschiedene Arten von Quellen und Senken erläutern. In allen Fällen sind Syntax und Semantik der Parameter mit demselben Namen identisch.Sicherheit für Quelle und Ziel ("Sink")
Einige Quell- und Sink-Typen verfügen zu Authentifizierungszwecken über optionale oder obligatorische Sicherheitsinformationen.
Alle Quellen und Senken, die Services in Oracle Cloud Infrastructure (OCI) verwenden, können bestimmte Parameter zur Angabe optionaler Sicherheitsinformationen verwenden. Diese Informationen können mit einer OCI-Konfigurationsdatei oder einem Instanz-Principal bereitgestellt werden.
Oracle NoSQL Database-Quellen und -Senken erfordern obligatorische Sicherheitsinformationen, wenn die Installation sicher ist und eine Oracle Wallet-basierte Authentifizierung verwendet. Diese Informationen können durch Hinzufügen einer JAR-Datei zum Verzeichnis <MIGRATOR_HOME>/lib bereitgestellt werden.
Wallet-basierte Authentifizierung
Wenn eine Oracle NoSQL Database-Installation die Oracle Wallet-basierte Authentifizierung verwendet, benötigen Sie eine zusätzliche JAR-Datei, die Teil der EE-Installation ist. Weitere Informationen finden Sie unter Oracle Wallet.
Ohne diese JAR-Datei erhalten Sie die folgende Fehlermeldung:
kvstore-ee.jar konnte im lib-Verzeichnis nicht gefunden werden. Kopieren Sie kvstore-ee.jar in das lib-Verzeichnis.
kvstore-EE.jar aus dem EE-Serverpackage in das Verzeichnis <MIGRATOR_HOME>/lib kopieren. <MIGRATOR_HOME> ist das Verzeichnis nosql-migrator-M.N.O/, das durch Extrahieren des Oracle NoSQL Database Migrator-Packages erstellt wurde, und M.N.O stellt die release.major.minor-Nummern der Software dar. Beispiel: nosql-migrator-1.1.0/lib.
Hinweis:
Die Wallet-basierte Authentifizierung wird NUR in der Enterprise Edition (EE) von Oracle NoSQL Database unterstützt.Authentifizieren mit Instance Principals
Instanz-Principals ist ein IAM-Servicefeature, mit dem Instanzen als autorisierte Akteure (oder Principals) Aktionen für Dienstressourcen ausführen können. Jede Compute-Instanz hat eine eigene Identität und authentifiziert die Zertifikate, die ihr hinzugefügt wurden.
Oracle NoSQL Database-Migrator bietet eine Option zum Herstellen einer Verbindung zu einer NoSQL-Cloud- und OCI Object Storage-Quellen und -Senken mit Instanz-Principal-Authentifizierung. Sie wird nur unterstützt, wenn das Tool NoSQL Database Migrator in einer OCI-Compute-Instanz verwendet wird, z.B. das Tool NoSQL Database Migrator, das in einer auf OCI gehosteten VM ausgeführt wird. Um dieses Feature zu aktivieren, verwenden Sie das Attribut useInstancePrincipal der Cloud-Quell- und Sinkkonfigurationsdatei NoSQL. Weitere Informationen zu Konfigurationsparametern für verschiedene Typen von Quellen und Senken finden Sie unter Quellkonfigurationsvorlagen und Sinkkonfigurationsvorlagen.
Weitere Informationen zu Instance Principals finden Sie unter Services von einer Instanz aufrufen.
Workflow für Oracle NoSQL Database-Migrator
Sie lernen die verschiedenen Schritte kennen, die Sie mit dem Utility Oracle NoSQL Database Migrator für die Migration der NoSQL-Daten ausführen.
Der allgemeine Ablauf der Aufgaben bei der Verwendung von NoSQL Database Migrator wird in der folgenden Abbildung dargestellt.
Laden Sie das Datenmigrator-Utility NoSQL herunter
runMigrator zugreifen.
Hinweis:
Das Utility Oracle NoSQL Database Migrator erfordert die Ausführung von Java 11 oder höher.Quelle und Sink identifizieren
- Sink-Tabellenschema identifizieren: Wenn die Sink On-Premise oder Cloud Oracle NoSQL Database ist, müssen Sie das Schema für die Sink-Tabelle identifizieren und sicherstellen, dass die Quelldaten mit dem Zielschema übereinstimmen. Verwenden Sie bei Bedarf Transformationen, um die Quelldaten der Sink-Tabelle zuzuordnen.
- Standardschema: NoSQL Database Migrator bietet eine Option, um eine Tabelle mit dem Standardschema zu erstellen, ohne das Schema für die Tabelle vorab definieren zu müssen. Dies ist vor allem beim Laden von JSON-Quelldateien in Oracle NoSQL Database nützlich.
Wenn die Quelle eine JSON-Datei im MongoDB-Format ist, lautet das Standardschema für die Tabelle wie folgt:
CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))Dabei gilt:
- tablename = Wert, der für das Tabellenattribut in der Konfiguration angegeben wird.
- ID = _id-Wert aus jedem Dokument der exportierten JSON-Quelldatei mongoDB.
- DOCUMENT = Für jedes Dokument in der exportierten Datei mongoDB werden die Inhalte ohne das Feld _id in der Spalte DOCUMENT aggregiert.
Wenn die Quelle eine JSON-Datei im DynamoDB-Format ist, lautet das Standardschema für die Tabelle wie folgt:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type],DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))Dabei gilt:
- TABLE_NAME = Wert für die Sink-Tabelle in der Konfiguration
- DDBPartitionKey_name = Wert, der für den Partitionsschlüssel in der Konfiguration angegeben wird
- DDBPartitionKey_type = für den Datentyp des Partitionsschlüssels in der Konfiguration angegebener Wert
- DDBSortKey_name = Wert, der für den Sortierschlüssel in der Konfiguration angegeben wird, falls vorhanden
- DDBSortKey_type = Wert, der für den Datentyp des Sortierschlüssels in der Konfiguration angegeben wird, falls vorhanden
- DOCUMENT = Alle Attribute mit Ausnahme der Partition und des Sortierschlüssels eines Dynamo-DB-Tabellenelements, aggregiert in einer JSON-Spalte NoSQL
Wenn das Quellformat eine CSV-Datei ist, wird für die Zieltabelle kein Standardschema unterstützt. Sie können eine Schemadatei mit einer Tabellendefinition erstellen, die dieselbe Anzahl von Spalten und Datentypen wie die CSV-Quelldatei enthält. Weitere Informationen zum Erstellen von Schemadateien finden Sie unter Tabellenschema bereitstellen.
Für alle anderen Quellen lautet das Standardschema wie folgt:CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))Dabei gilt:
- tablename = Wert, der für das Tabellenattribut in der Konfiguration angegeben wird.
- ID = Ein automatisch generierter LONG-Wert.
- DOCUMENT = Der von der Quelle bereitgestellte JSON-Datensatz wird in der Spalte DOCUMENT aggregiert.Hinweis:
Wenn der _id-Wert in der MongoDB-formatierten JSON-Datei nicht als Zeichenfolge angegeben wird, konvertiert NoSQL Database Migrator ihn in eine Zeichenfolge, bevor er in das Standardschema eingefügt wird.
- Standardschema: NoSQL Database Migrator bietet eine Option, um eine Tabelle mit dem Standardschema zu erstellen, ohne das Schema für die Tabelle vorab definieren zu müssen. Dies ist vor allem beim Laden von JSON-Quelldateien in Oracle NoSQL Database nützlich.
- Tabellenschema angeben: Mit NoSQL Database Migrator kann die Quelle Schemadefinitionen für die Tabellendaten mit dem Attribut schemaInfo angeben. Das Attribut schemaInfo ist in allen Datenquellen verfügbar, für die noch kein implizites Schema definiert ist. Sink-Datenspeicher können eine der folgenden Optionen auswählen:
- Verwenden Sie das vom NoSQL Database Migrator definierte Standardschema.
- Verwenden Sie das von der Quelle bereitgestellte Schema.
- Überschreiben Sie das von der Quelle bereitgestellte Schema, indem Sie ein eigenes Schema definieren. Beispiel: Wenn Sie die Daten aus dem Quellschema in ein anderes Schema transformieren möchten, müssen Sie das von der Quelle bereitgestellte Schema außer Kraft setzen und die Transformationsfunktion des Tools NoSQL Database Migrator verwenden.
Die Tabellenschemadatei, z.B.mytable_schema.DDL, kann Tabellen-DDL-Anweisungen enthalten. Das Tool NoSQL Database Migrator führt diese Tabellenschemadatei aus, bevor die Migration gestartet wird. Das Migrator-Tool unterstützt nicht mehr als eine DDL-Anweisung pro Zeile in der Schemadatei. Beispiel:CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))Hinweis:
Die Migration verläuft nicht erfolgreich, wenn die Tabelle an der Senke vorhanden ist und die DDL inschemaPathsich von der Tabelle unterscheidet. - Sink-Tabelle erstellen: Nachdem Sie das Sink-Tabellenschema identifiziert haben, erstellen Sie die Sink-Tabelle entweder über die Admin-CLI oder mit dem Attribut
schemaInfoder Sink-Konfigurationsdatei. Siehe Sink-Konfigurationsvorlagen.Hinweis:
Wenn die Quelle eine CSV-Datei ist, erstellen Sie eine Datei mit den DDL-Befehlen für das Schema der Zieltabelle. Geben Sie den Dateipfad im Parameter schemaInfo.schemaPath der Sink-Konfigurationsdatei an.
TTL-Metadaten für Tabellenzeilen migrieren
Hinweis:
Die Migration von TTL-Metadaten für Tabellenzeilen wird nur von Oracle NoSQL Database und Oracle NoSQL Database Cloud Service unterstützt.TTL-Metadaten exportieren
_metadata für jede exportierte Zeile enthalten. Der NoSQL-Datenbankmigrator exportiert die Ablaufzeit für jede Zeile als die Anzahl der Millisekunden seit der UNIX-Epoche (1. Januar 1970). Beispiel: //Row 1
{
"id" : 1,
"name" : "xyz",
"age" : 45,
"_metadata" : {
"expiration" : 1629709200000 //Row Expiration time in milliseconds
}
}
//Row 2
{
"id" : 2,
"name" : "abc",
"age" : 52,
"_metadata" : {
"expiration" : 1629709400000 //Row Expiration time in milliseconds
}
}
//Row 3 No Metadata for below row as it will not expire
{
"id" : 3,
"name" : "def",
"age" : 15
}TTL-Metadaten werden importiert
Sie können optional TTL-Metadaten mit einem Konfigurationsparameter includeTTL importieren. Der Importvorgang verarbeitet die folgenden Anwendungsfälle beim Migrieren von Tabellenzeilen, die TTL-Metadaten enthalten. Diese Anwendungsfälle sind nur anwendbar, wenn der Konfigurationsparameter includeTTL angegeben ist.
- Anwendungsfall 1: In der Zeile der importierenden Tabelle sind keine TTL-Metadateninformationen vorhanden.
Wenn Sie eine JSON-Quelldatei importieren, die aus einer externen Quelle erstellt oder mit früheren Versionen des Migrators exportiert wurde, enthält die importierende Zeile keine TTL-Informationen. Da der Konfigurationsparameter includeTTL jedoch
trueentspricht, hat der Migrator TTL=0 für die Tabellenzeile festgelegt. Das bedeutet, dass die importierende Tabellenzeile nie abläuft. - Groß-/Kleinschreibung 2: Der TTL-Wert der Quelltabellenzeile ist relativ zur Referenzzeit abgelaufen, wenn die Tabellenzeile importiert wird.
Wenn Sie eine Tabellenzeile in eine Datei exportieren und versuchen, sie nach Ablauf der Tabellenzeile zu importieren, wird die Tabellenzeile ignoriert und nicht in den Speicher geschrieben.
- Groß-/Kleinschreibung 3: Der TTL-Wert der Quelltabellenzeile ist relativ zur Referenzzeit nicht abgelaufen, wenn die Tabellenzeile importiert wird.
Wenn Sie eine Tabellenzeile in eine Datei exportieren und versuchen, sie vor Ablauf der Tabellenzeile zu importieren, wird die Tabellenzeile mit einem TTL-Wert importiert. Der neue TTL-Wert für die Tabellenzeile darf jedoch aufgrund der Constraints für ganzzahlige Stunden- und Tagesfenster in der Klasse TimeToLive nicht mit dem exportierten TTL-Wert identisch sein. Beispiel:
Exportierte Tabellenzeile{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC } }Die Referenzzeit beim Import ist 1629707962582, was Montag, 23. August 2021 8:39:22.582 AM ist.
Importierte Tabellenzeile{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC } }
Daten in eine Sink mit einer IDENTITY-Spalte importieren
Sie können die Daten aus einer gültigen Quelle in eine Sink-Tabelle (On-Premise/Cloud Services) mit einer IDENTITY-Spalte importieren. Sie erstellen die IDENTITY-Spalte entweder als IMMER ALS IDENTITÄT GENERIERT oder durch DEFAULT AS IDENTITÄT GENERIERT. Weitere Informationen zur Tabellenerstellung mit einer IDENTITY-Spalte finden Sie unter Tabellen mit einer IDENTITY-Spalte erstellen im SQL Reference Guide.
Stellen Sie vor dem Import der Daten sicher, dass die Oracle NoSQL Database-Tabelle an der Senke leer ist, sofern vorhanden. Wenn bereits Daten in der Sink-Tabelle vorhanden sind, kann die Migration zu Problemen führen, wie dem Überschreiben vorhandener Daten in der Sink-Tabelle oder dem Überspringen von Quelldaten während des Imports.
Sink-Tabelle mit IDENTITY-Spalte als IMMER ALS IDENTITÄT GENERIERT
Betrachten Sie eine Sink-Tabelle mit der IDENTITY-Spalte, die als GENERATED ALWAYS AS IDENTITY erstellt wurde. Der Datenimport hängt davon ab, ob die Quelle die Werte für die IDENTITY-Spalte und den ignoreFields-Transformationsparameter in der Konfigurationsdatei bereitstellt.
Beispiel: Sie möchten Daten aus einer JSON-Dateiquelle als Sink in die Oracle NoSQL Database-Tabelle importieren. Das Schema der Sink-Tabelle lautet:
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Quellbedingung | Benutzeraktion | Migrationsergebnis |
|---|---|---|
|
FALL 1: Quelldaten geben keinen Wert für das IDENTITY-Feld der Sink-Tabelle an. Beispiel: JSON-Quelldatei |
Erstellen/generieren Sie die Konfigurationsdatei. |
Datenmigration erfolgreich. IDENTITY-Spaltenwerte werden automatisch generiert. Migrierte Daten in Oracle NoSQL Database-Sink-Tabelle |
|
FALL 2: Quelldaten liefern Werte für das IDENTITY-Feld der Sink-Tabelle. Beispiel: JSON-Quelldatei |
Erstellen/generieren Sie die Konfigurationsdatei. Sie geben eine ignoreFields-Transformation für die ID-Spalte in der Sink-Konfigurationsvorlage an.
|
Datenmigration erfolgreich. Die angegebenen ID-Werte werden übersprungen, und die IDENTITY-Spaltenwerte werden automatisch generiert. Migrierte Daten in Oracle NoSQL Database-Sink-Tabelle
migrateID: |
|
Sie erstellen/generieren die Konfigurationsdatei ohne die Transformation ignoreFields für die IDENTITY-Spalte. |
Die Datenmigration ist mit der folgenden Fehlermeldung nicht erfolgreich: "Cannot set value for a generated always identity column". |
Weitere Informationen zu den Konfigurationsparametern für die Transformation finden Sie im Thema Konfigurationsvorlagen für die Transformation.
Sink-Tabelle mit IDENTITY-Spalte als GENERATED BY DEFAULT AS IDENTITY
Betrachten Sie eine Sink-Tabelle mit der IDENTITY-Spalte, die als GENERATED BY DEFAULT AS IDENTITY erstellt wurde. Der Datenimport hängt davon ab, ob die Quelle die Werte für die IDENTITY-Spalte und den Transformationsparameter ignoreFields bereitstellt.
Beispiel: Sie möchten Daten aus einer JSON-Dateiquelle als Sink in die Oracle NoSQL Database-Tabelle importieren. Das Schema der Sink-Tabelle lautet:
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Quellbedingung | Benutzeraktion | Migrationsergebnis |
|---|---|---|
|
FALL 1: Quelldaten geben keinen Wert für das IDENTITY-Feld der Sink-Tabelle an. Beispiel: JSON-Quelldatei |
Erstellen/generieren Sie die Konfigurationsdatei. |
Datenmigration erfolgreich. IDENTITY-Spaltenwerte werden automatisch generiert. Migrierte Daten in Oracle NoSQL Database-Sink-Tabelle
migrateID: |
|
FALL 2: Quelldaten liefern Werte für das IDENTITY-Feld der Sink-Tabelle und sind ein Primärschlüsselfeld. Beispiel: JSON-Quelldatei |
Erstellen/generieren Sie die Konfigurationsdatei. Sie geben eine ignoreFields-Transformation für die ID-Spalte in der Sinkkonfigurationsvorlage (Empfohlen) an.
|
Datenmigration erfolgreich. Die angegebenen ID-Werte werden übersprungen, und die IDENTITY-Spaltenwerte werden automatisch generiert. Migrierte Daten in Oracle NoSQL Database-Sink-Tabelle
migrateID: |
|
Sie erstellen/generieren die Konfigurationsdatei ohne die Transformation ignoreFields für die IDENTITY-Spalte. |
Datenmigration erfolgreich. Die angegebenen Wenn Sie versuchen, eine zusätzliche Zeile in die Tabelle einzufügen, ohne einen ID-Wert anzugeben, versucht der Sequence-Generator, den ID-Wert automatisch zu generieren. Der Startwert des Sequenzgenerators ist 1. Daher kann der generierte ID-Wert möglicherweise einen der vorhandenen ID-Werte in der Sink-Tabelle duplizieren. Da dies eine Verletzung des Primärschlüssel-Constraints darstellt, wird ein Fehler zurückgegeben, und die Zeile wird nicht eingefügt. Weitere Informationen finden Sie unter Sequence Generator. Um eine Verletzung des Primärschlüssel-Constraints zu vermeiden, muss der Sequence-Generator die Sequence mit einem Wert starten, der nicht mit vorhandenen ID-Werten in der Sink-Tabelle in Konflikt steht. Im folgenden Beispiel wird beschrieben, wie Sie das Attribut START WITH verwenden, um diese Änderung vorzunehmen: Beispiel: Migrierte Daten in der Oracle NoSQL Database-Sink-Tabelle
migrateID:Um den entsprechenden Wert für den Sequence-Generator zu finden, der in die ID-Spalte eingefügt werden soll, rufen Sie den Höchstwert des Feldes
ID mit der folgenden Abfrage ab:Ausgabe:
Der maximale Wert der Spalte
ID in der Sink-Tabelle ist 3. Sie möchten, dass der Sequence-Generator die ID-Werte über 3 hinaus generiert, um eine Duplizierung zu vermeiden. Mit der folgenden Anweisung aktualisieren Sie das START WITH-Attribut des Sequence-Generators auf 4:Dadurch wird die Sequenz bei 4 gestartet. Wenn Sie nun Zeilen in die Sink-Tabelle einfügen, ohne die ID-Werte anzugeben, generiert der Sequence-Generator die ID-Werte ab 4 automatisch und verhindert so die Duplizierung der IDs. |
Weitere Informationen zu den Konfigurationsparametern für die Transformation finden Sie im Thema Konfigurationsvorlagen für die Transformation.
Führen Sie den Befehl runMigrator aus.
Die ausführbare Datei runMigrator ist in den extrahierten NoSQL Database Migrator-Dateien verfügbar. Sie müssen Java 11 oder eine höhere Version und bash auf Ihrem System installieren, um den Befehl runMigrator erfolgreich ausführen zu können.
runMigrator auf zwei Arten ausführen:
- Indem Sie die Konfigurationsdatei mit den Laufzeitoptionen des Befehls
runMigratorerstellen, wie unten gezeigt.[~]$ ./runMigrator configuration file is not provided. Do you want to generate configuration? (y/n) [n]: y ... ...- Wenn Sie das Utility
runMigratoraufrufen, stellt es eine Reihe von Laufzeitoptionen bereit und erstellt die Konfigurationsdatei basierend auf Ihren Auswahlmöglichkeiten für jede Option. - Nachdem das Utility die Konfigurationsdatei erstellt hat, können Sie die Migrationsaktivität in derselben Ausführung fortsetzen oder die Konfigurationsdatei für eine zukünftige Migration speichern.
- Unabhängig davon, ob Sie die Migrationsaktivität mit der generierten Konfigurationsdatei fortsetzen oder verschieben möchten, kann die Datei bearbeitet oder angepasst werden, um Ihre zukünftigen Anforderungen zu erfüllen. Sie können die benutzerdefinierte Konfigurationsdatei später für die Migration verwenden.
- Wenn Sie das Utility
- Durch Übergeben einer manuell erstellten Konfigurationsdatei (im JSON-Format) als Laufzeitparameter mit der Option
-coder--config. Sie müssen die Konfigurationsdatei manuell erstellen, bevor Sie den BefehlrunMigratormit der Option-coder--configausführen. Weitere Informationen zu den Quell- und Sinkkonfigurationsparametern finden Sie in der Oracle NoSQL Database-Migratorreferenz.[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
Fortschritt des Logging-Migrators
Das Tool NoSQL Database Migrator bietet Optionen, mit denen Trace-, Debugging- und Fortschrittsmeldungen in die Standardausgabe oder in eine Datei gedruckt werden können. Diese Option kann nützlich sein, um den Fortschritt des Migrationsvorgangs zu verfolgen, insbesondere bei sehr großen Tabellen oder Datasets.
- Logebenen
Um das Loggingverhalten über das Tool NoSQL Database Migrator zu steuern, übergeben Sie den Parameter --log-level oder -l Runtime an den Befehl
runMigrator. Sie können die Menge der zu schreibenden Loginformationen angeben, indem Sie den entsprechenden Logebenenwert übergeben.$./runMigrator --log-level <loglevel>Beispiel:$./runMigrator --log-level debugTabelle - Unterstützte Logebenen für NoSQL Database Migrator
Logebene Beschreibung Warnung Druckt Fehler und Warnungen. Informationen (Standard) Druckt den Fortschrittsstatus der Datenmigration, wie die Validierung der Quelle, die Validierung der Senke, das Erstellen von Tabellen und die Anzahl der migrierten Datensätze. debug Druckt zusätzliche Debuginformationen. all Druckt alles. Diese Ebene aktiviert alle Logging-Ebenen. - Logdatei:
Sie können den Namen der Logdatei mit dem Parameter --log-file oder -f angeben. Wenn --log-file als Laufzeitparameter an den Befehl
runMigratorübergeben wird, schreibt der NoSQL Database Migrator alle Logmeldungen in die andere Datei in die Standardausgabe.$./runMigrator --log-file <log file name>Beispiel:$./runMigrator --log-file nosql_migrator.log
Use Case-Demonstrationen für Oracle NoSQL Database-Migrator
Erfahren Sie, wie Sie eine Datenmigration mit dem Oracle NoSQL Database-Migrator für bestimmte Anwendungsfälle durchführen. Detaillierte systematische Anweisungen mit Codebeispielen zur Durchführung der Migration finden Sie in jedem Anwendungsfall.
Dieser Artikel enthält die folgenden Themen:
Von Oracle NoSQL Database Cloud Service in eine JSON-Datei migrieren
In diesem Beispiel wird gezeigt, wie Sie mit dem Oracle NoSQL Database-Migrator Daten und die Schemadefinition einer NoSQL-Tabelle aus Oracle NoSQL Database Cloud Service (NDCS) in eine JSON-Datei kopieren.
Anwendungsfall
Eine Organisation beschließt, ein Modell mit den Oracle NoSQL Database Cloud Service-(NDCS-)Daten zu trainieren, um zukünftiges Verhalten vorherzusagen und personalisierte Empfehlungen bereitzustellen. Sie können die Daten der NDCS-Tabellen regelmäßig in eine JSON-Datei kopieren und auf die Analyse-Engine anwenden, um das Modell zu analysieren und zu trainieren. Auf diese Weise können sie die analytischen Abfragen von den kritischen Pfaden mit geringer Latenz trennen.
Beispiel
In der Demonstration wird beschrieben, wie Sie die Daten- und Schemadefinition einer NoSQL-Tabelle mit dem NamenmyTable von NDCS in eine JSON-Datei migrieren.- Identifizieren Sie die Quelle und den Sink für die Migration.
- Quelle: Oracle NoSQL Database Cloud Service
- Sink: JSON-Datei
- Identifizieren Sie Ihre OCI-Cloud-Zugangsdaten, und erfassen Sie sie in der OCI-Konfigurationsdatei. Speichern Sie die Konfigurationsdatei in
/home/.oci/config. Siehe Zugangsdaten anfordern.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifizieren Sie den Regionsendpunkt und den Compartment-Namen für Oracle NoSQL Database Cloud Service.
- Endpunkt:
us-phoenix-1 - Compartment:
developers
- Endpunkt:
myTable von Oracle NoSQL Database Cloud Service in eine JSON-Datei:
Um die Migration zu validieren, können Sie die JSON-Sinkdateien öffnen und das Schema und die Daten anzeigen.
-- Exported myTable Data
[~/nosqlMigrator]$cat myTableJSON
{
"id" : 10,
"document" : {
"course" : "Computer Science",
"name" : "Neena",
"studentid" : 105
}
}
{
"id" : 3,
"document" : {
"course" : "Computer Science",
"name" : "John",
"studentid" : 107
}
}
{
"id" : 4,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 6,
"document" : {
"course" : "Bio-Technology",
"name" : "Rekha",
"studentid" : 104
}
}
{
"id" : 7,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 5,
"document" : {
"course" : "Journalism",
"name" : "Rani",
"studentid" : 106
}
}
{
"id" : 8,
"document" : {
"course" : "Computer Science",
"name" : "Tom",
"studentid" : 103
}
}
{
"id" : 9,
"document" : {
"course" : "Computer Science",
"name" : "Peter",
"studentid" : 109
}
}
{
"id" : 1,
"document" : {
"course" : "Journalism",
"name" : "Tracy",
"studentid" : 110
}
}
{
"id" : 2,
"document" : {
"course" : "Bio-Technology",
"name" : "Raja",
"studentid" : 108
}
}-- Exported myTable Schema
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))Von Oracle NoSQL Database On-Premise zu Oracle NoSQL Database Cloud Service migrieren
In diesem Beispiel wird gezeigt, wie Sie mit dem Oracle NoSQL Database-Migrator Daten und die Schemadefinition einer NoSQL-Tabelle von Oracle NoSQL Database in Oracle NoSQL Database Cloud Service (NDCS) kopieren.
Anwendungsfall
Als Entwickler untersuchen Sie Optionen, um den Aufwand für die Verwaltung der Ressourcen, Cluster und Garbage Collection für Ihre vorhandenen NoSQL Database KVStore-Workloads zu vermeiden. Als Lösung beschließen Sie, Ihre vorhandenen On-Premise-Workloads KVStore in Oracle NoSQL Database Cloud Service zu migrieren, da NDCS sie automatisch verwaltet.
Beispiel
In der Demonstration erfahren Sie, wie Sie die Daten- und Schemadefinition einer NoSQL-Tabelle mit dem NamenmyTable von der NoSQL-Datenbank KVStore zu NDCS migrieren. In diesem Anwendungsfall wird auch gezeigt, wie Sie das Utility runMigrator ausführen, indem Sie eine vorab erstellte Konfigurationsdatei übergeben.- Identifizieren Sie die Quelle und den Sink für die Migration.
- Quelle: Oracle NoSQL Database
- Sink: Oracle NoSQL Database Cloud Service
- Identifizieren Sie Ihre OCI-Cloud-Zugangsdaten, und erfassen Sie sie in der OCI-Konfigurationsdatei. Speichern Sie die Konfigurationsdatei in
/home/.oci/config. Siehe Zugangsdaten abrufen in Oracle NoSQL Database Cloud Service verwenden.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifizieren Sie den Regionsendpunkt und den Compartment-Namen für Oracle NoSQL Database Cloud Service.
- Endpunkt:
us-phoenix-1 - Compartment:
developers
- Endpunkt:
- Geben Sie die folgenden Details für die On-Premise-Datei KVStore an:
- storeName:
kvstore - helperHosts:
<hostname>:5000 - Tabelle:
myTable
- storeName:
myTable von der NoSQL-Datenbank KVStore zu NDCS:
Um die Migration zu validieren, können Sie sich bei der NDCS-Konsole anmelden und prüfen, ob myTable mit den Quelldaten erstellt wurde.
Von einer JSON-Dateiquelle zu Oracle NoSQL Database Cloud Service migrieren
Dieses Beispiel zeigt die Verwendung von Oracle NoSQL Database Migrator zum Kopieren von Daten aus einer JSON-Dateiquelle in Oracle NoSQL Database Cloud Service.
Nachdem mehrere Optionen ausgewertet wurden, schließt eine Organisation Oracle NoSQL Database Cloud Service als Datenbankplattform NoSQL ab. Da die Quellinhalte im JSON-Dateiformat vorliegen, suchen sie nach einer Möglichkeit, sie in Oracle NoSQL Database Cloud Service zu migrieren.
In diesem Beispiel lernen Sie, wie Sie die Daten aus einer JSON-Datei mit dem Namen SampleData.JSON migrieren. Sie führen das Utility runMigrator aus, indem Sie eine vorab erstellte Konfigurationsdatei übergeben. Wenn die Konfigurationsdatei nicht als Laufzeitparameter angegeben wird, werden Sie vom Utility runMigrator aufgefordert, die Konfiguration über eine interaktive Prozedur zu generieren.
- Identifizieren Sie die Quelle und den Sink für die Migration.
- Quelle: JSON-Quelldatei.
SampleData.jsonist die Quelldatei. Es enthält mehrere JSON-Dokumente mit einem Dokument pro Zeile, die durch ein neues Zeilenzeichen getrennt sind.{"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-03-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-02T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-02T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-02T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":7,"val_json":{"array":["a","b","c"],"date":"2023-02-20T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-01-20T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-01-22T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":4,"val_json":{"array":["j","k","l"],"date":"2023-02-03T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-03T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-02-03T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} - Sink: Oracle NoSQL Database Cloud Service.
- Quelle: JSON-Quelldatei.
- Identifizieren Sie Ihre OCI-Cloud-Zugangsdaten, und erfassen Sie sie in der Konfigurationsdatei. Speichern Sie die Konfigurationsdatei in
/home/user/.oci/config. Weitere Informationen finden Sie unter Zugangsdaten abrufen in Oracle NoSQL Database Cloud Service verwenden.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... region=us-ashburn-1 key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifizieren Sie den Regionsendpunkt und den Compartment-Namen für Oracle NoSQL Database Cloud Service.
- Endpunkt:
us-ashburn-1 - Compartment:
Training-NoSQL
- Endpunkt:
- Geben Sie die folgenden Details für die JSON-Quelldatei an:
-
schemaPath:
<absolute path to the schema definition file containing DDL statements for the NoSQL table at the sink>.In diesem Beispiel lautet die DDL-Dateischema_json.DDL.create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id));Der Oracle NoSQL Database-Migrator bietet eine Option zum Erstellen einer Tabelle mit dem Standardschema, wenn
schemaPathnicht angegeben ist. Weitere Informationen finden Sie im Thema Quelle und Sink identifizieren im Workflow für Oracle NoSQL Database-Migrator. - Datapath:
<absolute path to a file or directory containing the JSON data for migration>.
-
SampleData.JSON in Oracle NoSQL Database Cloud Service zu migrieren, führen Sie folgende Schritte aus:
Migrate_JSON mit den Quelldaten erstellt wurde. Informationen zum Zugriff auf die Konsole finden Sie im Artikel Über die Infrastructure-Konsole auf den Service zugreifen im Oracle NoSQL Database Cloud Service-Dokument.
Abbildung - Oracle NoSQL Database Cloud Service-Konsolentabellen
Abbildung - Tabellendaten der Oracle NoSQL Database Cloud Service-Konsole
Von der JSON-Datei MongoDB in Oracle NoSQL Database Cloud Service migrieren
In diesem Beispiel wird gezeigt, wie Sie mit dem Oracle NoSQL Database-Migrator formatierte Mongo-DB-Daten in Oracle NoSQL Database Cloud Service (NDCS) kopieren.
Anwendungsfall
Nachdem mehrere Optionen ausgewertet wurden, schließt eine Organisation Oracle NoSQL Database Cloud Service als Datenbankplattform NoSQL ab. Da die NoSQL-Tabellen und -Daten in MongoDB enthalten sind, suchen sie nach einer Möglichkeit, diese Tabellen und Daten in Oracle NDCS zu migrieren.
Sie können eine Datei oder ein Verzeichnis mit den MongoDB-exportierten JSON-Daten für die Migration kopieren, indem Sie die Datei oder das Verzeichnis in der Quellkonfigurationsvorlage angeben.
{"_id":0,"name":"Aimee Zank","scores":[{"score":1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}
MongoDB unterstützt zwei Arten von Erweiterungen des JSON-Format für Dateien, Kanonischer Modus und Relaxierter Modus. Sie können die MongoDB-formatierte JSON-Datei angeben, die mit dem Tool mongoexport im Canonical- oder Relaxed-Modus generiert wird. Beide Modi werden vom NoSQL Database Migrator für die Migration unterstützt.
Weitere Informationen zur MongoDB Extended JSON-(v2-)Datei finden Sie unter mongoexport_formats.
Weitere Informationen zur Generierung einer JSON-Datei im Format MongoDB finden Sie unter mongoexport.
Beispiel
Die Demonstration zeigt, wie eine MongoDB-formatierte JSON-Datei in NDCS migriert wird. In diesem Beispiel wird eine manuell erstellte Konfigurationsdatei verwendet.- Identifizieren Sie die Quelle und den Sink für die Migration.
- Quelle: MongoDB - Formatierte JSON-Datei
- Sink: Oracle NoSQL Database Cloud Service
- Extrahieren Sie die Daten mit dem Utility mongoexport aus der Mongo-DB. Weitere Informationen finden Sie unter mongoexport.
- Erstellen Sie eine NoSQL-Tabelle in der Senke mit einem Tabellenschema, das mit den Daten in der Mongo-DB-formatierten JSON-Datei übereinstimmt. Alternativ können Sie den NoSQL Database Migrator anweisen, eine Tabelle mit der Standardschemastruktur zu erstellen, indem Sie das Attribut
defaultSchemaauf "true" setzen.Hinweis:
Bei einer MongoDB-formatierten JSON-Quelle lautet das Standardschema für die Tabelle wie folgt:CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))Dabei gilt:tablename= Wert der Tabellenkonfiguration.ID=_id-Wert aus der exportierten JSON-Quelldatei mongoDB.DOCUMENT= Der gesamte Inhalt der exportierten JSON-Quelldatei mongoDB wird in der SpalteDOCUMENTmit Ausnahme des Feldes_idaggregiert.
- Identifizieren Sie Ihre OCI-Cloud-Zugangsdaten, und erfassen Sie sie in der OCI-Konfigurationsdatei. Speichern Sie die Konfiguration in
/home/.oci/config. Siehe Zugangsdaten abrufen in Oracle NoSQL Database Cloud Service verwenden.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifizieren Sie den Regionsendpunkt und den Compartment-Namen für Oracle NoSQL Database Cloud Service.
- Endpunkt:
us-phoenix-1 - Compartment:
developers
- Endpunkt:
So migrieren Sie die JSON-Daten im MongoDB-Format in Oracle NoSQL Database Cloud Service:
Um die Migration zu validieren, können Sie sich bei der NDCS-Konsole anmelden und prüfen, ob myTable mit den Quelldaten erstellt wurde.
Von JSON-Datei DynamoDB in Oracle NoSQL Database migrieren
Dieses Beispiel zeigt, wie Sie mit dem Oracle NoSQL Database-Migrator die JSON-Datei DynamoDB in Oracle NoSQL Database kopieren.
Anwendungsfall:
Nachdem mehrere Optionen ausgewertet wurden, schließt eine Organisation Oracle NoSQL Database über die Datenbank DynamoDB ab. Die Organisation möchte ihre Tabellen und Daten von DynamoDB zu Oracle NoSQL Database (On-Premises) migrieren.
Weitere Informationen finden Sie unter Zuordnung der Tabelle DynamoDB zur Tabelle NoSQL von Oracle.
Sie können eine Datei oder ein Verzeichnis mit den exportierten JSON-Daten von DynamoDB aus einem Dateisystem migrieren, indem Sie den Pfad in der Quellkonfigurationsvorlage angeben.
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"}}}
Sie kopieren die exportierten DynamoDB-Tabellendaten aus dem AWS S3-Speicher in ein lokales gemountetes Dateisystem.
Beispiel:
In dieser Demo lernen Sie, wie Sie eine JSON-Datei DynamoDB in Oracle NoSQL Database (On Premise) migrieren. In diesem Beispiel verwenden Sie eine manuell erstellte Konfigurationsdatei.
Voraussetzungen
- Identifizieren Sie die Quelle und den Sink für die Migration.
- Quelle: DynamoDB JSON-Datei
- Sink: Oracle NoSQL Database (On-Premise)
- Um DynamoDB-Tabellendaten in Oracle NoSQL Database zu importieren, müssen Sie zuerst die Tabelle DynamoDB in S3 exportieren. Weitere Informationen zum Exportieren Ihrer Tabelle finden Sie unter Exportieren von Tabellendaten aus DynamoDB in Amazon S3. Beim Exportieren wählen Sie das Format DynamoDB JSON aus. Die exportierten Daten enthalten DynamoDB-Tabellendaten in mehreren
gzip-Dateien, wie unten dargestellt./ 01639372501551-bb4dd8c3 |-- 01639372501551-bb4dd8c3 ==> exported data prefix |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started - Sie müssen die Dateien von AWS s3 herunterladen. Die Struktur der Dateien nach dem Download wird wie unten gezeigt.
download-dir/01639372501551-bb4dd8c3 |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started
Vorgehensweise
- Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit der identifizierten Quelle und der Sink details.See Quellkonfigurationsvorlagen und Sink-Konfigurationsvorlagen vor.
Sie können eine der beiden folgenden Optionen wählen.
- Option 1: Importieren Sie die Tabelle DynamoDB als JSON-Dokument mit der Standardschemakonfiguration.
Hier ist
defaultSchemaTRUE. Daher erstellt der Migrator das Standardschema an der Sink. Sie müssen denDDBPartitionKey- und den entsprechenden NoSQL-Spaltentyp angeben. Andernfalls wird ein Fehler ausgelöst.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] "schemaInfo" : { "defaultSchema" : true, "DDBPartitionKey" : "<PrimaryKey:Datatype>", }, }, "abortOnError" : true, "migratorVersion" : "1.0.0" }Bei einer JSON-Quelle DynamoDB lautet das Standardschema für die Tabelle wie folgt:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type], DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))WHERE
TABLE_NAME = Wert, der für die Sink-Tabelle in der Konfiguration angegeben wird
DDBPartitionKey_name = für den Partiiton-Schlüssel in der Konfiguration angegebener Wert
DDBPartitionKey_type = Wert, der für den Datentyp des Partitionsschlüssels in der Konfiguration angegeben wird
DDBSortKey_name = Wert, der für den Sortierschlüssel in der Konfiguration angegeben wird, sofern vorhanden
DDBSortKey_type = Wert, der für den Datentyp des Sortierschlüssels in der Konfiguration angegeben wird, sofern vorhanden
DOCUMENT = Alle Attribute mit Ausnahme der Partition und des Sortierschlüssels eines Dynamo-DB-Tabellenelements, aggregiert in einer JSON-Spalte NoSQL
- Option 2: Importieren Sie die Tabelle DynamoDB als feste Spalten mit einer vom Benutzer bereitgestellten Schemadatei.
Hier ist
defaultSchemaFALSE, und Sie geben schemaPath als Datei mit der DDL-Anweisung an. Weitere Informationen finden Sie unter DynamoDB-Typen Oracle-NoSQL-Typen zuordnen.Hinweis:
Wenn die Dynamo-DB-Tabelle einen Datentyp aufweist, der in NoSQL nicht unterstützt wird, verläuft die Migration nicht erfolgreich.Eine Beispielschemadatei ist unten dargestellt.CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, PRIMARY KEY(SHARD(AccountId)));Mit der Schemadatei wird die Tabelle an der Sink im Rahmen der Migration erstellt. Solange die Primärschlüsseldaten angegeben sind, wird der JSON-Eingabedatensatz eingefügt. Andernfalls wird ein Fehler ausgelöst.Hinweis:
Wenn die Eingabedaten keinen Wert für eine bestimmte Spalte (außer dem Primärschlüssel) enthalten, wird der Spaltenstandardwert verwendet. Der Standardwert muss bei der Erstellung der Tabelle Teil der Spaltendefinition sein. Beispiel:id INTEGER not null default 0. Wenn die Spalte keine Standarddefinition aufweist, wird SQL NULL eingefügt, wenn keine Werte für die Spalte angegeben sind.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- Option 1: Importieren Sie die Tabelle DynamoDB als JSON-Dokument mit der Standardschemakonfiguration.
- Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Datenbankmigrator-Utility NoSQL extrahiert haben.
- Führen Sie den Befehl
runMigratoraus, indem Sie die Konfigurationsdatei mit der Option--configoder-cübergeben.[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file> - Das Utility fährt mit der Datenmigration fort, wie unten dargestellt.
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
Validierung
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoredesc <table_name>
SELECT * from <table_name>Von der JSON-Datei DynamoDB in AWS S3 zu Oracle NoSQL Database Cloud Service migrieren
In diesem Beispiel wird gezeigt, wie Sie mit dem Oracle NoSQL Database-Migrator die JSON-Datei DynamoDB kopieren, die in einem AWS-S3-Speicher in Oracle NoSQL Database Cloud Service (NDCS) gespeichert ist.
Anwendungsfall:
Nachdem mehrere Optionen ausgewertet wurden, schließt eine Organisation Oracle NoSQL Database Cloud Service über die Datenbank DynamoDB ab. Die Organisation möchte ihre Tabellen und Daten von DynamoDB zu Oracle NoSQL Database Cloud Service migrieren.
Weitere Informationen finden Sie unter Zuordnung der Tabelle DynamoDB zur Tabelle NoSQL von Oracle.
Sie können eine Datei mit den exportierten JSON-Daten DynamoDB aus dem AWS-S3-Speicher migrieren, indem Sie den Pfad in der Quellkonfigurationsvorlage angeben.
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"}}}
Sie exportieren die Tabelle DynamoDB in den AWS S3-Speicher, wie unter Exportieren von Tabellendaten aus DynamoDB in Amazon S3 angegeben.
Beispiel:
In dieser Demonstration lernen Sie, wie Sie eine JSON-Datei DynamoDB in einer AWS S3-Quelle in NDCS migrieren. In diesem Beispiel verwenden Sie eine manuell erstellte Konfigurationsdatei.
Voraussetzungen
- Identifizieren Sie die Quelle und den Sink für die Migration.
- Quelle: DynamoDB JSON-Datei in AWS S3
- Sink: Oracle NoSQL Database Cloud Service
- Identifizieren Sie die Tabelle in AWS DynamoDB, die zu NDCS migriert werden muss. Melden Sie sich mit Ihren Zugangsdaten bei Ihrer AWS-Konsole an. Gehen Sie zu DynamoDB. Wählen Sie unter Tabellen die zu migrierende Tabelle aus.
- Erstellen Sie einen Objekt-Bucket, und exportieren Sie die Tabelle in S3. Gehen Sie von Ihrer AWS-Konsole zu S3. Erstellen Sie unter Buckets einen neuen Objekt-Bucket. Gehen Sie zurück zu DynamoDB, und klicken Sie auf In S3 exportieren. Geben Sie die Quelltabelle und den Ziel-Bucket S3 an, und klicken Sie auf Exportieren.
Weitere Informationen zum Exportieren Ihrer Tabelle finden Sie unter Exportieren von Tabellendaten aus DynamoDB in Amazon S3. Beim Exportieren wählen Sie das Format DynamoDB JSON aus. Die exportierten Daten enthalten DynamoDB-Tabellendaten in mehreren
gzip-Dateien, wie unten dargestellt./ 01639372501551-bb4dd8c3 |-- 01639372501551-bb4dd8c3 ==> exported data prefix |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started - Sie benötigen aws-Zugangsdaten (einschließlich Zugriffsschlüssel-ID und Secret-Zugriffsschlüssel) und Konfigurationsdateien (Zugangsdaten und optional Konfiguration), um über den Migrator auf AWS S3 zuzugreifen. Weitere Informationen zu den Konfigurationsdateien finden Sie unter Konfigurationseinstellungen festlegen und anzeigen. Weitere Informationen zum Erstellen von Zugriffsschlüsseln finden Sie unter Schlüsselpaar erstellen.
- Identifizieren Sie Ihre OCI-Cloud-Zugangsdaten, und erfassen Sie sie in der OCI-Konfigurationsdatei. Speichern Sie die Konfigurationsdatei in einem Verzeichnis
.ociunter Ihrem Home-Verzeichnis (~/.oci/config). Weitere Informationen finden Sie unter Berechtigungsnachweise anfordern.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifizieren Sie den Regionsendpunkt und den Compartment-Namen für Oracle NoSQL Database. Beispiel:
- Endpunkt: us-phoenix-1
- Compartment: Entwickler
Vorgehensweise
- Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit den identifizierten Quell- und Sinkdetails vor. Weitere Informationen finden Sie unter Quellkonfigurationsvorlagen und Sink-Konfigurationsvorlagen.
Sie können eine der beiden folgenden Optionen wählen.
- Option 1: Importieren Sie die Tabelle DynamoDB als JSON-Dokument mit der Standardschemakonfiguration.
Hier ist
defaultSchemaTRUE. Daher erstellt der Migrator das Standardschema an der Sink. Sie müssen denDDBPartitionKey- und den entsprechenden NoSQL-Spaltentyp angeben. Andernfalls wird ein Fehler ausgelöst.{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : true, "readUnits" : 100, "writeUnits" : 60, "DDBPartitionKey" : "<PrimaryKey:Datatype>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }Bei einer JSON-Quelle DynamoDB lautet das Standardschema für die Tabelle wie folgt:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type], DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))WHERE
TABLE_NAME = Wert, der für die Sink-Tabelle in der Konfiguration angegeben wird
DDBPartitionKey_name = für den Partiiton-Schlüssel in der Konfiguration angegebener Wert
DDBPartitionKey_type = Wert, der für den Datentyp des Partitionsschlüssels in der Konfiguration angegeben wird
DDBSortKey_name = Wert, der für den Sortierschlüssel in der Konfiguration angegeben wird, sofern vorhanden
DDBSortKey_type = Wert, der für den Datentyp des Sortierschlüssels in der Konfiguration angegeben wird, sofern vorhanden
DOCUMENT = Alle Attribute mit Ausnahme der Partition und des Sortierschlüssels eines Dynamo-DB-Tabellenelements, aggregiert in einer JSON-Spalte NoSQL
- Option 2: Importieren Sie die Tabelle DynamoDB als feste Spalten mit einer vom Benutzer bereitgestellten Schemadatei.
Hier ist
defaultSchemaFALSE, und Sie geben schemaPath als Datei mit der DDL-Anweisung an. Weitere Informationen finden Sie unter DynamoDB-Typen Oracle-NoSQL-Typen zuordnen.Hinweis:
Wenn die Dynamo-DB-Tabelle einen Datentyp aufweist, der in NoSQL nicht unterstützt wird, verläuft die Migration nicht erfolgreich.Eine Beispielschemadatei ist unten dargestellt.CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, PRIMARY KEY(SHARD(AccountId)));Mit der Schemadatei wird die Tabelle an der Sink im Rahmen der Migration erstellt. Solange die Primärschlüsseldaten angegeben sind, wird der JSON-Eingabedatensatz eingefügt. Andernfalls wird ein Fehler ausgelöst.Hinweis:
Wenn die Eingabedaten keinen Wert für eine bestimmte Spalte (außer dem Primärschlüssel) enthalten, wird der Spaltenstandardwert verwendet. Der Standardwert muss bei der Erstellung der Tabelle Teil der Spaltendefinition sein. Beispiel:id INTEGER not null default 0. Wenn die Spalte keine Standarddefinition aufweist, wird SQL NULL eingefügt, wenn keine Werte für die Spalte angegeben sind.{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- Option 1: Importieren Sie die Tabelle DynamoDB als JSON-Dokument mit der Standardschemakonfiguration.
- Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Datenbankmigrator-Utility NoSQL extrahiert haben.
- Führen Sie den Befehl
runMigratoraus, indem Sie die Konfigurationsdatei mit der Option--configoder-cübergeben.[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file> - Das Utility fährt mit der Datenmigration fort, wie unten dargestellt.
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
Validierung
Sie können sich bei der NDCS-Konsole anmelden und prüfen, ob die neue Tabelle mit den Quelldaten erstellt wurde.
Migration zwischen Oracle NoSQL Database Cloud Service-Regionen
Dieses Beispiel zeigt die Verwendung von Oracle NoSQL Database Migrator für die regionsübergreifende Migration.
Anwendungsfall
Eine Organisation verwendet Oracle NoSQL Database Cloud Service, um ihre Daten zu speichern und zu verwalten. Sie beschließt, Daten aus einer vorhandenen Region zu Testzwecken in eine neuere Region zu replizieren, bevor die neue Region für die Produktionsumgebung gestartet werden kann.
In diesem Anwendungsfall lernen Sie, wie Sie mit dem NoSQL Database Migrator Daten aus der Tabelle user_data in der Region Ashburn in die Region Phoenix kopieren.
Sie führen das Utility runMigrator aus, indem Sie eine vorab erstellte Konfigurationsdatei übergeben. Wenn Sie die Konfigurationsdatei nicht als Laufzeitparameter angeben, werden Sie vom Utility runMigrator aufgefordert, die Konfiguration über eine interaktive Prozedur zu generieren.
- Laden Sie Oracle NoSQL Database Migrator von der Seite Oracle NoSQL Downloads herunter, und extrahieren Sie den Inhalt auf Ihren Rechner. Weitere Informationen finden Sie unter Workflow für Oracle NoSQL Database-Migration.
- Identifizieren Sie die Quelle und den Sink für die Migration.
- Quelle: Die Tabelle
user_datain der Region Ashburn.Die Tabelleuser_dataenthält die folgenden Daten:{"id":40,"firstName":"Joanna","lastName":"Smith","otherNames":[{"first":"Joanna","last":"Smart"}],"age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085},"connections":[70,30,40],"email":"joanna.smith123@reachmail.com","communityService":"**"} {"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"Good"},{"first":"Johny2","last":"Brave"},{"first":"Johny3","last":"Kind"},{"first":"Johny4","last":"Humble"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"email":"john.smith@reachmail.com","communityService":"****"} {"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"BeGood"}],"age":22,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"email":"jane.smith201@reachmail.com","communityService":"*****"} {"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"BeGood"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"email":"adam.smith201reachmail.com","communityService":"***"}Geben Sie entweder den Regionsendpunkt oder den Serviceendpunkt und den Compartment-Namen für die Quelle an.- Endpunkt:
us-ashburn-1 - Compartment:
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- Endpunkt:
- Sink: Die Tabelle
user_dataim Bereich Phoenix.Geben Sie entweder den Regionsendpunkt oder den Serviceendpunkt und den Compartment-Namen für die Senke an.- Endpunkt:
us-phoenix-1 - Compartment:
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Geben Sie das Sink-Tabellenschema an.
Sie können denselben Tabellennamen und dasselbe Schema wie die Quelltabelle verwenden. Informationen zu anderen Schemaoptionen finden Sie unter dem Thema Quelle und Sink identifizieren in Workflow für Oracle NoSQL Database-Migrator
- Endpunkt:
- Quelle: Die Tabelle
- Identifizieren Sie Ihre OCI-Cloud-Zugangsdaten für beide Regionen, und erfassen Sie sie in der Konfigurationsdatei. Speichern Sie die Konfigurationsdatei auf Ihrem Rechner im Verzeichnis
/home/<user>/.oci/config. Weitere Informationen finden Sie unter Zugangsdaten abrufen.
Hinweis:
- Wenn sich die Regionen unter verschiedenen Mandanten befinden, müssen Sie verschiedene Profile in der Datei
/home/<user>/.OCI/configmit den entsprechenden OCI-Cloud-Zugangsdaten für jeden einzelnen Mandanten angeben. - Wenn sich die Regionen unter demselben Mandanten befinden, können Sie ein einzelnes Profil in der Datei
/home/<user>/.oci/configverwenden.
In diesem Beispiel befinden sich die Regionen unter verschiedenen Mandanten. Das DEFAULT-Profil enthält OCI-Zugangsdaten für die Region Ashburn, und DEFAULT2 enthält OCI-Zugangsdaten für die Region Phoenix.
endpoint der Migrationskonfigurationsdatei (Quell- und Sinkkonfigurationsvorlagen) können Sie entweder die Serviceendpunkt-URL oder die Regions-ID der Regionen angeben. Die Liste der für Oracle NoSQL Database Cloud Service und die zugehörigen Serviceendpunkt-URLs unterstützten Datenregionen finden Sie unter Datenregionen und zugehörige Service-URLs im Oracle NoSQL Database Cloud Service-Dokument.[DEFAULT]
user=ocid1.user.oc1....
fingerprint=fd:96:....
tenancy=ocid1.tenancy.oc1....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=abcd
[DEFAULT2]
user=ocid1.user.oc1....
fingerprint=1b:68:....
tenancy=ocid1.tenancy.oc1....
region=us-phoenix-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=23456user_data aus der Region Ashburn in die Region Phoenix zu migrieren, führen Sie die folgenden Schritte aus:
Um die Migration zu validieren, können Sie sich bei der Oracle NoSQL Database Cloud Service-Konsole in der Region Phoenix anmelden. Prüfen Sie, ob die Quelldaten aus der Tabelle user_data in der Region Ashburn in die Tabelle user_data in dieser Region kopiert werden. Die Vorgehensweise für den Zugriff auf die Konsole finden Sie im Artikel Über die Infrastructure-Konsole auf den Service zugreifen.
Von Oracle NoSQL Database Cloud Service zu OCI Object Storage migrieren
Dieses Beispiel zeigt die Verwendung von Oracle NoSQL Database-Migrator aus einer Cloud Shell.
Anwendungsfall
Ein Start-up-Unternehmen plant, Oracle NoSQL Database Cloud Service als Datenspeicherlösung zu verwenden. Das Unternehmen möchte mit dem Oracle NoSQL Database-Migrator Daten aus einer Tabelle in Oracle NoSQL Database Cloud Service in OCI Object Storage kopieren, um regelmäßige Backups seiner Daten zu erstellen. Als kosteneffektive Maßnahme möchten sie das Utility NoSQL Database Migrator über die Cloud Shell ausführen, auf die alle OCI-Benutzer zugreifen können.
In diesem Anwendungsfall lernen Sie, wie Sie das Utility NoSQL Database Migrator in eine Cloud Shell in der abonnierten Region kopieren und eine Datenmigration ausführen. Sie migrieren die Quelldaten aus der Tabelle Oracle NoSQL Database Cloud Service in eine JSON-Datei im OCI Object Storage.
Sie führen das Utility runMigrator aus, indem Sie eine vorab erstellte Konfigurationsdatei übergeben. Wenn Sie die Konfigurationsdatei nicht als Laufzeitparameter angeben, werden Sie vom Utility runMigrator aufgefordert, die Konfiguration über eine interaktive Prozedur zu generieren.
- Laden Sie Oracle NoSQL Database Migrator von der Seite Oracle NoSQL Downloads auf den lokalen Rechner herunter.
- Starten Sie Cloud Shell über das Menü Entwicklertools in Ihrer Cloud-Konsole. Der Webbrowser öffnet Ihr Home-Verzeichnis. Klicken Sie in der oberen rechten Ecke des Cloud Shell-Fensters auf das Cloud Shell-Menü, und wählen Sie in der Dropdown-Liste die Option Upload aus. Ziehen Sie im Popup-Fenster das Package Oracle NoSQL Database Migrator per Drag-and-Drop von Ihrem lokalen Rechner, oder klicken Sie auf die Option Aus Ihrem Rechner auswählen, wählen Sie das Package auf dem lokalen Rechner aus, und klicken Sie auf die Schaltfläche Hochladen. Sie können das Oracle NoSQL Database-Migrator-Package auch per Drag-and-Drop direkt von Ihrem lokalen Rechner in das Home-Verzeichnis in der Cloud Shell verschieben. Extrahieren Sie den Inhalt des Packages.
- Identifizieren Sie die Quelle und Sink für das Backup.
-
Quelle: Tabelle
NDCSuploadin der Region Oracle NoSQL Database Cloud Service Ashburn.Beachten Sie zur Demonstration die folgenden Daten in der TabelleNDCSupload:{"id":1,"name":"Jane Smith","email":"iamjane@somemail.co.us","age":30,"income":30000.0} {"id":2,"name":"Adam Smith","email":"adam.smith@mymail.com","age":25,"income":25000.0} {"id":3,"name":"Jennifer Smith","email":"jenny1_smith@mymail.com","age":35,"income":35000.0} {"id":4,"name":"Noelle Smith","email":"noel21@somemail.co.us","age":40,"income":40000.0}Geben Sie den Endpunkt und die Compartment-ID für die Quelle an. Für den Endpunkt können Sie entweder die Regions-ID oder den Serviceendpunkt angeben. Die Liste der Datenregionen, die in Oracle NoSQL Database Cloud Service unterstützt werden, finden Sie unter Datenbereiche und zugehörige Service-URLs.
- Endpunkt:
us-ashburn-1 - Compartment-ID:
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- Endpunkt:
-
Sink: JSON-Datei im OCI Object Storage-Bucket.
Identifizieren Sie den Regionsendpunkt, den Namespace, den Bucket und das Präfix für OCI Object Storage. Weitere Informationen finden Sie unter Auf Oracle Cloud Object Storage zugreifen. Die Liste der OCI Object Storage-Serviceendpunkte finden Sie unter Object Storage-Endpunkte.
- Endpunkt:
us-ashburn-1 - Bucket:
Migrate_oci - Präfix:
Delegation - Namespace: <> Wenn Sie keinen Namespace angeben, verwendet das Utility den Standard-Namespace des Mandanten.
Hinweis:
Wenn sich der Objektspeicher-Bucket in einem anderen Compartment befindet, stellen Sie sicher, dass Sie über die Berechtigungen zum Schreiben von Objekten im Bucket verfügen. Weitere Informationen zum Festlegen der Policys finden Sie unter Schreiben von Objekten in Object Storage-Buckets durch Benutzer zulassen. - Endpunkt:
-
NDCSupload mit Cloud Shell von Oracle NoSQL Database Cloud Service in einer JSON-Datei im OCI Object Storage-Bucket zu sichern, führen Sie die folgenden Schritte aus:
Um Ihr Datenbackup zu validieren, melden Sie sich bei der Oracle NoSQL Database Cloud Service-Konsole an. Navigieren Sie durch die Menüs, Storage > Object Storage & Archive Storage > Buckets. Greifen Sie über das Verzeichnis NDCSupload/Delegation im Bucket Migrate_oci auf die Dateien zu. Die Vorgehensweise für den Zugriff auf die Konsole finden Sie im Artikel Über die Infrastructure-Konsole auf den Service zugreifen.
Von CSV-Datei in Oracle NoSQL Database migrieren
Dieses Beispiel zeigt die Verwendung von Oracle NoSQL Database Migrator zum Kopieren von Daten aus einer CSV-Datei in Oracle NoSQL Database.
Beispiel
Nachdem mehrere Optionen ausgewertet wurden, schließt eine Organisation Oracle NoSQL Database als Datenbankplattform NoSQL ab. Da die Quellinhalte im CSV-Dateiformat vorliegen, suchen sie nach einer Möglichkeit, sie in Oracle NoSQL Database zu migrieren.
In diesem Beispiel lernen Sie, die Daten aus einer CSV-Datei namens course.CSV zu migrieren, die Informationen zu verschiedenen Kursen enthält, die von einer Universität angeboten werden. Sie generieren die Konfigurationsdatei aus dem Utility runMigrator.
Sie können die Konfigurationsdatei auch mit den identifizierten Quell- und Sinkdetails vorbereiten. Siehe Oracle NoSQL Database-Migrator - Referenz.
- Identifizieren Sie die Quelle und den Sink für die Migration.
- Quelle: CSV-Datei
In diesem Beispiel lautet die Quelldatei
course.csv.cat [~/nosql-migrator-1.5.0]/course.csv 1,"Computer Science", "San Francisco", "2500" 2,"Bio-Technology", "Los Angeles", "1200" 3,"Journalism", "Las Vegas", "1500" 4,"Telecommunication", "San Francisco", "2500" - Sink: Oracle NoSQL Database
- Quelle: CSV-Datei
- Die CSV-Datei muss dem Format
RFC4180entsprechen. - Erstellen Sie eine Datei mit den DDL-Befehlen für das Schema der Zieltabelle
course. Die Tabellendefinition muss mit der CSV-Datendatei in Bezug auf die Anzahl der Spalten und deren Typen übereinstimmen.In diesem Beispiel lautet die DDL-Datei
mytable_schema.DDL.cat [~/nosql-migrator-1.5.0]/mytable_schema.ddl create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
course.CSV zu Oracle NoSQL Database Service zu migrieren, führen Sie die folgenden Schritte aus:
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
sql-> select * from course;
{"id":4,"name":"Telecommunication","location":"San Francisco","fees":2500}
{"id":1,"name":"Computer Science","location":"San Francisco","fees":2500}
{"id":2,"name":"Bio-Technology","location":"Los Angeles","fees":1200}
{"id":3,"name":"Journalism","location":"Las Vegas","fees":1500}
4 rows returned
Oracle NoSQL Database-Migrator verwenden