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.

Der Oracle NoSQL Database-Migrator wurde so konzipiert, dass er in Zukunft zusätzliche Quellen und Senken unterstützen kann. Eine Liste der Quellen und Senken, die von Oracle NoSQL Database Migrator ab dem aktuellen Release unterstützt werden, finden Sie unter Unterstützte Quellen und Sinks.

Beschreibung von migrator_overview.eps folgt
Beschreibung der Abbildung migrator_overview.eps

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
    source type Y 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 type für jede Quelle finden Sie unter Unterstützte Quellen und Sinks.
    source Quellkonfiguration 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.
    sink type Y 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 type für jede Quelle finden Sie unter Unterstützte Quellen und Sinks.
    sink sink-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.
    transforms transformiert 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.
    - migratorVersion N Version des Datenmigrators NoSQL -
    - abortOnError N

    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
(Wert)

Format
(Wert)

Gültige Quelle Gültiger Sink

Oracle NoSQL Database
(nosqldb)

- Y Y

Oracle NoSQL Database Cloud Service
(nosqldb_cloud)

- Y Y

Dateisystem
(file)

JSON
(json)

Y Y

MongoDB JSON
(mongodb_json)

Y N

DynamoDB JSON
(dynamodb_json)

Y N

Parquet(parquet)

N Y

CSV
(csv)

Y N

OCI Object Storage
(object_storage_oci)

JSON
(json)

Y Y

MongoDB JSON
(mongodb_json)

Y N

Parquet(parquet)

N Y

CSV
(csv)

Y N
AWS S3

DynamoDB JSON
(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, müssen Sie zusätzliche JAR-Dateien aufnehmen, die Teil der EE-Installation sind. Weitere Informationen finden Sie unter Oracle Wallet.

Ohne die JAR-Dateien erhalten Sie die folgende Fehlermeldung:

kvstore-ee.jar und kvstore-ee-<version>.jar konnten im lib-Verzeichnis nicht gefunden werden. Kopieren Sie kvstore-ee.jar und kvstore-ee-<version>.jar in das lib-Verzeichnis

Um die oben gezeigte Ausnahme zu vermeiden, müssen Sie die Dateien kvstore-ee.jar und kvstore-ee-<version>.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.


Beschreibung von migrator_flow.eps folgt
Beschreibung der Abbildung migrator_flow.eps

Laden Sie das Datenmigrator-Utility NoSQL herunter

Das Utility Oracle NoSQL Database Migrator kann über die Seite Oracle NoSQL Downloads heruntergeladen werden. Nachdem Sie die Datei heruntergeladen und auf Ihren Rechner entpackt haben, können Sie über die Befehlszeilenschnittstelle auf den Befehl runMigrator zugreifen.

Hinweis:

Das Utility Oracle NoSQL Database Migrator erfordert die Ausführung von Java 11 oder höher.

Quelle und Sink identifizieren

Bevor Sie den Migrator verwenden, müssen Sie die Datenquelle und den Sink identifizieren. Beispiel: Wenn Sie eine NoSQL-Tabelle von Oracle NoSQL Database On Premise in eine JSON-formatierte Datei migrieren möchten, ist Ihre Quelle Oracle NoSQL Database, und die Sink ist eine JSON-Datei. Stellen Sie sicher, dass die identifizierte Quelle und die identifizierte Sink vom Oracle NoSQL Database-Migrator unterstützt werden, indem Sie auf Unterstützte Quellen und Sinks verweisen. Dies ist auch eine geeignete Phase, um das Schema für die Tabelle NoSQL im Ziel oder der Sink zu bestimmen und zu erstellen.
  • 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.
  • 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.

    Beschreibung von source_sink_schema_example.png folgt
    Beschreibung der Abbildung source_sink_schema_example.png

    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 in schemaPath sich 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 schemaInfo der 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

Die Gültigkeitsdauer (TTL) ist ein Verfahren, mit dem Sie den automatischen Ablauf von Tabellenzeilen festlegen können. Die Gültigkeitsdauer gibt an, wie lange Daten im Shop gültig sind. Daten, deren Ablauf-Timeoutwert erreicht wurde, können nicht mehr abgerufen werden und werden in keinen Speicherstatistiken angezeigt.

Bei der Migration von Oracle NoSQL Database-Tabellen können Sie die TTL-Metadaten für Tabellenzeilen zusammen mit den tatsächlichen Daten aufnehmen. Der NoSQL Database Migrator stellt Konfigurationsparameter bereit, um den Export und Import von TTL-Metadaten der Tabellenzeile für die folgenden Quelltypen zu unterstützen:

Tabelle - TTL-Metadaten migrieren

Quelltypen Quellkonfigurationsparameter Sink-Konfigurationsparameter
Oracle NoSQL Database includeTTL includeTTL
Oracle NoSQL Database Cloud Service includeTTL includeTTL
DynamoDB-formatierte JSON-Datei ttlAttributeName includeTTL
DynamoDB-formatierte JSON-Datei in AWS gespeichert S3 ttlAttributeName includeTTL

TTL-Metadaten in Oracle NoSQL Database und Oracle NoSQL Database Cloud Service exportieren

NoSQL Database Migrator stellt den Konfigurationsparameter includeTTL bereit, um den Export der TTL-Metadaten der Tabellenzeile zu unterstützen.

Wenn eine Tabelle exportiert wird, werden die TTL-Daten für die Tabellenzeilen mit einer gültigen Ablaufzeit exportiert. Wenn eine Zeile nicht abläuft, wird das JSON-Objekt _metadata nicht explizit in die exportierten Daten aufgenommen, da der Ablaufwert immer 0 ist. Der NoSQL Database Migrator 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 dem Konfigurationsparameter includeTTL in der Sink-Konfigurationsvorlage importieren.

Die Standardreferenzzeit des Importvorgangs ist die aktuelle Zeit in Millisekunden, die von System.currentTimeMillis() abgerufen wird, auf dem Rechner, auf dem das NoSQL Database Migrator-Tool ausgeführt wird. Sie können jedoch auch eine benutzerdefinierte Referenzzeit mit dem Konfigurationsparameter ttlRelativeDate festlegen, wenn Sie die Ablaufzeit verlängern und Zeilen importieren möchten, die andernfalls sofort ablaufen würden. Die Verlängerung wird wie folgt berechnet und der Ablaufzeit hinzugefügt. 

Extended time = expiration time - reference time

Der Importvorgang verarbeitet die folgenden Anwendungsfälle beim Migrieren von Tabellenzeilen mit TTL-Metadaten. Diese Anwendungsfälle sind nur anwendbar, wenn der Konfigurationsparameter includeTTL auf "true" gesetzt ist.

  • Anwendungsfall 1: In der Zeile der importierenden Tabelle sind keine TTL-Metadateninformationen vorhanden.

    Wenn die Zeile, die Sie importieren möchten, keine TTL-Informationen enthält, legt der NoSQL Database Migrator den TTL=0 für die Zeile fest.

  • Anwendungsfall 2: Der TTL-Wert der Quelltabellenzeile ist relativ zur Referenzzeit abgelaufen, wenn die Tabellenzeile importiert wird.

    Die abgelaufene Tabellenzeile wird ignoriert und nicht in den Speicher geschrieben.

  • Anwendungsfall 3: Der TTL-Wert der Quelltabellenzeile ist im Verhältnis zur Referenzzeit beim Import der Tabellenzeile nicht abgelaufen.

    Die Tabellenzeile wird mit einem TTL-Wert importiert. Der importierte TTL-Wert stimmt jedoch aufgrund der Constraints im ganzzahligen Stunden- und Tagesfenster in der Klasse TimeToLive möglicherweise nicht mit dem ursprünglichen exportierten TTL-Wert überein. Beispiel:

    Betrachten Sie eine exportierte Tabellenzeile:
    {
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
  "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC
  }
}

    Die Referenzzeit beim Import ist 1734480000000, d.h. Mittwoch, 18. Dezember 2024, 12:00:00 Uhr.

    Importierte Tabellenzeile
    {
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
    "ttl" :  1734739200000 //Saturday, December 21, 2024 12:00:00 AM
  }
}

TTL-Metadaten in DynamoDB-formatierte JSON-Datei und in AWS gespeicherte DynamoDB-formatierte JSON-Datei importieren S3

NoSQL Database Migrator stellt einen zusätzlichen Konfigurationsparameter ttlAttributeName bereit, um den Import von TTL-Metadaten aus den DynamoDB-formatierten JSON-Dateielementen zu unterstützen.

DynamoDB exportierte JSON-Dateien enthalten in jedem Element ein bestimmtes Attribut, um den TTL-Ablaufzeitstempel zu speichern. Um optional die TTL-Werte aus exportierten JSON-Dateien von DynamoDB zu importieren, müssen Sie den Namen des spezifischen Attributs als Wert für den Konfigurationsparameter ttlAttributeName in der DynamoDB-formatierten JSON-Datei oder der DynamoDB-formatierten JSON-Datei angeben, die in den AWS-Quellkonfigurationsdateien S3 gespeichert ist. Außerdem müssen Sie den Konfigurationsparameter includeTTL in der Sink-Konfigurationsvorlage festlegen. Gültige Sinks sind Oracle NoSQL Database und Oracle NoSQL Database Cloud Service. NoSQL Database Migrator speichert TTL-Informationen im JSON-Objekt _metadata für das importierte Element.

Der Importvorgang verwaltet die folgenden Anwendungsfälle beim Migrieren von Tabellenelementen der exportierten JSON-Dateien von DynamoDB:

  • Anwendungsfall 1: Der Konfigurationsparameterwert ttlAttributeName wird auf den TTL-Attributnamen gesetzt, der in der exportierten JSON-Datei DynamoDB angegeben ist.

    NoSQL Database Migrator importiert die Ablaufzeit für dieses Element als die Anzahl der Millisekunden seit der UNIX-Epoche (1. Januar 1970).

    Beispiel: Ein Element in der exportierten JSON-Datei DynamoDB:
    {
    "Item": {
        "DeptId": {
            "N": "1"
        },
        "DeptName": {
            "S": "Engineering"
        },
        "ttl": {
            "N": "1734616800"
        }
    }
}
    Hier gibt das Attribut ttl den Gültigkeitsdauerwert für das Element an. Wenn Sie den Konfigurationsparameter ttlAttributeName in der DynamoDB-formatierten JSON-Datei oder der DynamoDB-formatierten JSON-Datei, die in der AWS-Quellkonfigurationsdatei S3 gespeichert ist, als ttl festlegen, importiert NoSQL Database Migrator die Ablaufzeit für das Element wie folgt:
    {
  "DeptId": 1,
  "document": {
      "DeptName": "Engineering"
    }  
  "_metadata": {
    "expiration": 1734616800000
  }
}

    Hinweis:

    Sie können den Konfigurationsparameter ttlRelativeDate in der Sink-Konfigurationsvorlage als Referenzzeit für die Berechnung der Ablaufzeit angeben.
  • Anwendungsfall 2: Der Konfigurationsparameterwert ttlAttributeName ist festgelegt. Der Wert ist jedoch nicht als Attribut im Element der exportierten JSON-Datei DynamoDB vorhanden.

    NoSQL Database Migrator importiert die TTL-Metadateninformationen für das angegebene Element nicht.

  • Anwendungsfall 3: Der Wert des Konfigurationsparameters ttlAttributeName stimmt nicht mit dem Attributnamen im Element der exportierten JSON-Datei DynamoDB überein.
    NoSQL Database Migrator verarbeitet den Import auf eine der folgenden Arten basierend auf der Sink-Konfiguration:
    • Kopiert das Attribut als normales Feld, wenn es für den Import mit dem Standardschema konfiguriert ist.
    • Überspringt das Attribut, wenn es für den Import mit einem benutzerdefinierten Schema konfiguriert ist.

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))
Das Utility Migrator verarbeitet die Datenmigration wie in den folgenden Fällen beschrieben:
Quellbedingung Benutzeraktion Migrationsergebnis

FALL 1: Quelldaten geben keinen Wert für das IDENTITY-Feld der Sink-Tabelle an.

Beispiel: JSON-Quelldatei sample_noID.JSON

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

Erstellen/generieren Sie die Konfigurationsdatei.

Datenmigration erfolgreich. IDENTITY-Spaltenwerte werden automatisch generiert. Migrierte Daten in Oracle NoSQL Database-Sink-Tabelle migrateID: 

{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"John","course":"Computer Science"}
{"ID":1002,"name":"Tony","course":"Electronics"}

FALL 2: Quelldaten liefern Werte für das IDENTITY-Feld der Sink-Tabelle.

Beispiel: JSON-Quelldatei sampleID.JSON

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

Erstellen/generieren Sie die Konfigurationsdatei. Sie geben eine ignoreFields-Transformation für die ID-Spalte in der Sink-Konfigurationsvorlage an.

"transforms" : { "ignoreFields" : ["ID"] }

Datenmigration erfolgreich. Die angegebenen ID-Werte werden übersprungen, und die IDENTITY-Spaltenwerte werden automatisch generiert.

Migrierte Daten in Oracle NoSQL Database-Sink-Tabelle migrateID:
{"ID":2003,"name":"John","course":"Computer Science"}
{"ID":2002,"name":"Tony","course":"Electronics"}
{"ID":2001,"name":"Jane","course":"BioTechnology"}

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))
Das Utility Migrator verarbeitet die Datenmigration wie in den folgenden Fällen beschrieben:
Quellbedingung Benutzeraktion Migrationsergebnis

FALL 1: Quelldaten geben keinen Wert für das IDENTITY-Feld der Sink-Tabelle an.

Beispiel: JSON-Quelldatei sample_noID.JSON

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

Erstellen/generieren Sie die Konfigurationsdatei.
Datenmigration erfolgreich. IDENTITY-Spaltenwerte werden automatisch generiert. Migrierte Daten in Oracle NoSQL Database-Sink-Tabelle migrateID:
{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}

FALL 2: Quelldaten liefern Werte für das IDENTITY-Feld der Sink-Tabelle und sind ein Primärschlüsselfeld.

Beispiel: JSON-Quelldatei sampleID.JSON

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

Erstellen/generieren Sie die Konfigurationsdatei. Sie geben eine ignoreFields-Transformation für die ID-Spalte in der Sinkkonfigurationsvorlage (Empfohlen) an.

"transforms" : { "ignoreFields" : ["ID"] }

Datenmigration erfolgreich. Die angegebenen ID-Werte werden übersprungen, und die IDENTITY-Spaltenwerte werden automatisch generiert.

Migrierte Daten in Oracle NoSQL Database-Sink-Tabelle migrateID:
{"ID":1002,"name":"John","course":"Computer Science"}
{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"Tony","course":"Electronics"}

Sie erstellen/generieren die Konfigurationsdatei ohne die Transformation ignoreFields für die IDENTITY-Spalte.

Datenmigration erfolgreich. Die angegebenen ID-Werte aus der Quelle werden in die Spalte ID in der Sink-Tabelle kopiert.

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:
{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}
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:
SELECT max(ID) FROM migrateID
Ausgabe: 
{"Column_1":3}
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:
ALTER Table migrateID (MODIFY ID GENERATED BY DEFAULT AS IDENTITY (START WITH 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.

Sie können den Befehl runMigrator auf zwei Arten ausführen:
  1. Indem Sie die Konfigurationsdatei mit den Laufzeitoptionen des Befehls runMigrator erstellen, wie unten gezeigt. 
    [~]$ ./runMigrator
configuration file is not provided. Do you want to generate configuration? (y/n)                                                                              
 
[n]: y
...
...
    • Wenn Sie das Utility runMigrator aufrufen, 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.
  2. Durch Übergeben einer manuell erstellten Konfigurationsdatei (im JSON-Format) als Laufzeitparameter mit der Option -c oder --config. Sie müssen die Konfigurationsdatei manuell erstellen, bevor Sie den Befehl runMigrator mit der Option -c oder --config ausführen. Weitere Informationen zu den Quell- und Sinkkonfigurationsparametern finden Sie in der Oracle NoSQL Database-Migratorreferenz.
    [~]$ ./runMigrator -c </path/to/the/configuration/json/file>

Hinweis:

NoSQL Database Migrator verbraucht Leseeinheiten beim Datenexport aus der Oracle NoSQL Cloud Service-Tabelle in eine beliebige gültige Sink.

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 debug

    Tabelle - 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 Namen myTable von NDCS in eine JSON-Datei migrieren.
Voraussetzungen
  • 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
Vorgehensweise
So migrieren Sie die Daten- und Schemadefinition von myTable von Oracle NoSQL Database Cloud Service in eine JSON-Datei:
  1. Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Utility NoSQL Database Migrator extrahiert haben.
  2. Um die Konfigurationsdatei mit dem NoSQL Database Migrator zu generieren, führen Sie den Befehl runMigrator ohne Laufzeitparameter aus.
    [~/nosqlMigrator]$./runMigrator
  3. Da Sie die Konfigurationsdatei nicht als Laufzeitparameter angegeben haben, werden Sie vom Utility aufgefordert, die Konfiguration jetzt zu generieren. Geben Sie y ein.
    Configuration file is not provided. Do you want to generate
configuration? (y/n) [n]: y

Generating a configuration file interactively.
  4. Wählen Sie auf Basis der Eingabeaufforderungen des Utilitys die Optionen für die Quellkonfiguration aus.
    Enter a location for your config [./migrator-config.json]: /home/<user>/nosqlMigrator/NDCS2JSON
Select the source: 
1) nosqldb
2) nosqldb_cloud
3) file
4) object_storage_oci
5) aws_s3
#? 2

Configuration for source type=nosqldb_cloud
Enter endpoint URL or region ID of the Oracle NoSQL Database Cloud: us-phoenix-1
Select the authentication type: 
1) credentials_file
2) instance_principal
3) delegation_token
#? 1
Enter path to the file containing OCI credentials [/home/<user>/.oci/config]:
Enter the profile name in OCI credentials file [DEFAULT]: 
Enter the compartment name or id of the table []: developers
Enter table name: myTable
Include TTL data? If you select 'yes' TTL of rows will also 
be included in the exported data.(y/n) [n]: 
Enter percentage of table read units to be used for migration operation. (1-100) [90]:
Enter store operation timeout in milliseconds. (1-30000) [5000]:
  5. Wählen Sie auf Basis der Eingabeaufforderungen des Dienstprogramms Ihre Optionen für die Sink-Konfiguration aus. 
    Select the sink:
1) nosqldb
2) nosqldb_cloud
3) file
#? 3
Configuration for sink type=file
Enter path to a directory to store JSON data: /home/<user>/nosqlMigrator
would you like to export data to multiple files for each source?(y/n) [y]: n
Would you like to store JSON in pretty format? (y/n) [n]: y
Would you like to migrate the table schema also? (y/n) [y]: y
Enter path to a file to store table schema: /home/<user>/nosqlMigrator/myTableSchema
  6. Wählen Sie basierend auf den Eingabeaufforderungen aus dem Utility Ihre Optionen für die Quelldatentransformationen aus. Der Standardwert ist n.
    Would you like to add transformations to source data? (y/n) [n]:
  7. Geben Sie Ihre Auswahl ein, um zu bestimmen, ob die Migration fortgesetzt werden soll, falls ein Datensatz nicht migriert werden kann.
    Would you like to continue migration in case of any record/row is failed to migrate?: (y/n) [n]:
  8. Das Utility zeigt die generierte Konfiguration auf dem Bildschirm an. 
    generated configuration is:
{
  "source": {
    "type": "nosqldb_cloud",
    "endpoint": "us-phoenix-1",
    "table": "myTable",
    "compartment": "developers",
    "credentials": "/home/<user>/.oci/config",
    "credentialsProfile": "DEFAULT",
    "readUnitsPercent": 90,
    "requestTimeoutMs": 5000
  },
  "sink": {
    "type": "file",
    "format": "json",
    "useMultiFiles" : false,
    "schemaPath": "/home/<user>/nosqlMigrator/myTableSchema",
    "pretty": true,
    "dataPath": "/home/<user>/nosqlMigrator"
  },
  "abortOnError": true,
  "migratorVersion": "1.6.5"
}
  9. Abschließend fordert das Utility Sie auf, zu entscheiden, ob Sie mit der Migration mit der generierten Konfigurationsdatei fortfahren möchten. Die Standardoption ist y.

    Hinweis:

    Wenn Sie n auswählen, können Sie die Migration mit der Option ./runMigrator -c oder ./runMigrator --config mit der generierten Konfigurationsdatei ausführen. 
    would you like to run the migration with above configuration?
If you select no, you can use the generated configuration file to run the migration using
./runMigrator --config /home/<user>/nosqlMigrator/NDCS2JSON
(y/n) [y]:
  10. Der NoSQL-Datenbankmigrator migriert Ihre Daten und Ihr Schema von NDCS in die JSON-Datei.
    Records provided by source=10,Records written to sink=10,Records failed=0,Records skipped=0.
Elapsed time: 0min 1sec 277ms
Migration completed.
Validierung

Um die Migration zu validieren, können Sie zum angegebenen Sink-Verzeichnis navigieren und das Schema und die Daten anzeigen. 

-- Exported myTable Data. JSON files are created in the supplied data path
 
[~/nosqlMigrator]$cat myTable_1_5.json
{
  "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 Namen myTable 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.
Voraussetzungen
  • 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
  • Geben Sie die folgenden Details für die On-Premise-Datei KVStore an:
    • storeName: kvstore
    • helperHosts: <hostname>:5000
    • Tabelle: myTable
Vorgehensweise
So migrieren Sie die Daten- und Schemadefinition von myTable von der NoSQL-Datenbank KVStore zu NDCS:
  1. Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit den identifizierten Quell- und Sink-Details vor. Siehe Quellkonfigurationsvorlagen und Sink-Konfigurationsvorlagen.
    {
  "source" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "myTable",
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "myTable",
    "compartment" : "developers",
    "schemaInfo" : {
      "schemaPath" : "<complete/path/to/the/JSON/file/with/DDL/commands/for/the/schema/definition>",
      "readUnits" : 100,
      "writeUnits" : 100,
      "storageSize" : 1
    },
    "credentials" : "<complete/path/to/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.0.0"
}
  2. Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Utility NoSQL Database Migrator extrahiert haben.
  3. Führen Sie den Befehl runMigrator aus, indem Sie die Konfigurationsdatei mit der Option --config oder -c übergeben.
    [~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. Das Utility fährt mit der Datenmigration fort, wie unten dargestellt.
    Records provided by source=10, Records written to sink=10, Records failed=0.
Elapsed time: 0min 10sec 426ms
Migration completed.
Validierung

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.

Voraussetzungen
  • Identifizieren Sie die Quelle und den Sink für die Migration.
    • Quelle: JSON-Quelldatei.
      SampleData.json ist 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.
  • 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
  • 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-Datei schema_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 schemaPath nicht 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>.
Vorgehensweise
Um die JSON-Quelldatei von SampleData.JSON in Oracle NoSQL Database Cloud Service zu migrieren, führen Sie folgende Schritte aus:
  1. Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit den identifizierten Quell- und Sinkdetails vor. Siehe Quellkonfigurationsvorlagen und Sink-Konfigurationsvorlagen.
    {
  "source" : {
    "type" : "file",
    "format" : "json",
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.5.0]/schema_json.ddl"
    },
    "dataPath" : "[~/nosql-migrator-1.5.0]/SampleData.json"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "Migrate_JSON",
    "compartment" : "Training-NoSQL",
    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "/home/user/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.5.0"
}
  2. Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Utility Oracle NoSQL Database Migrator extrahiert haben.
  3. Führen Sie den Befehl runMigrator aus, indem Sie die Konfigurationsdatei mit der Option --config oder -c übergeben.
    [~/nosql-migrator-1.5.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. Das Utility fährt mit der Datenmigration fort, wie unten gezeigt. Die Tabelle Migrate_JSON wird an der Senke mit dem in schemaPath angegebenen Schema erstellt.
    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id)),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
[cloud sink] : start loading records
[json file source] : start parsing JSON records from file: SampleData.json
[INFO] migration completed.
Records provided by source=4, Records written to sink=4, Records failed=0, Records skipped=0.
Elapsed time: 0min 5sec 778ms
Migration completed.
Validierung
Um die Migration zu validieren, können Sie sich bei der Oracle NoSQL Database Cloud Service-Konsole anmelden und prüfen, ob die Tabelle 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


Beschreibung von Abbildung - folgt
Beschreibung von "Abbildung - Oracle NoSQL Database Cloud Service-Konsolentabellen"

Abbildung - Tabellendaten der Oracle NoSQL Database Cloud Service-Konsole


Beschreibung von Abbildung - folgt
Beschreibung von "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.

Eine JSON-Beispieldatei im Format MongoDB lautet wie folgt:
{"_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.
Voraussetzungen
  • 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 Tabelle NoSQL in der Sink mit einem Tabellenschema, das mit den Daten in der mongo-DB-formatierten JSON-Datei übereinstimmt. Alternativ können Sie den NoSQL-Datenbankmigrator anweisen, eine Tabelle mit der Standardschemastruktur zu erstellen, indem Sie das Attribut defaultSchema auf "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 Spalte DOCUMENT mit Ausnahme des Feldes _id aggregiert.
  • 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
Vorgehensweise

So migrieren Sie die JSON-Daten im MongoDB-Format in Oracle NoSQL Database Cloud Service:

  1. Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit den angegebenen Quell- und Sinkdetails vor. Siehe Quellkonfigurationsvorlagen und Sink-Konfigurationsvorlagen.
    {
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "mongoImport",
    "compartment" : "developers",
    "schemaInfo" : {
      "defaultSchema" : true,
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.0.0"
}
  2. Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Utility NoSQL Database Migrator extrahiert haben.
  3. Führen Sie den Befehl runMigrator aus, indem Sie die Konfigurationsdatei mit der Option --config oder -c übergeben.
    [~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. Das Utility fährt mit der Datenmigration fort, wie unten dargestellt.
    Records provided by source=29,353, Records written to sink=29,353, Records failed=0.
Elapsed time: 9min 9sec 630ms
Migration completed.
Validierung

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

In diesem Beispiel wird gezeigt, wie Sie mit Oracle NoSQL Database Migrator die JSON-Datei DynamoDB in die NoSQL-Datenbank kopieren.

Anwendungsfall:

Nachdem mehrere Optionen ausgewertet wurden, schließt eine Organisation die Datenbank Oracle NoSQL Database über 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.

Eine JSON-Beispieldatei im Format DynamoDB lautet wie folgt:
{"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"},"ttl": {"N": "1734616800"}}}
{"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"},"ttl": {"N": "1734616800"}}}

Sie kopieren die exportierten DynamoDB-Tabellendaten aus dem AWS S3-Speicher in ein lokales gemountetes Dateisystem.

Beispiel:

In dieser Demonstration lernen Sie, wie Sie eine JSON-Datei DynamoDB in Oracle NoSQL Database (On-Premises) migrieren. Sie verwenden für dieses Beispiel 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-Premises)
  • Um die Tabellendaten DynamoDB in Oracle NoSQL Database zu importieren, müssen Sie zuerst die Tabelle DynamoDB in S3 exportieren. Informationen zum Exportieren der Tabelle finden Sie in den Schritten unter DynamoDB-Tabellendaten in Amazon S3 exportieren. Beim Exportieren wählen Sie das Format als DynamoDB JSON aus. Die exportierten Daten enthalten die Tabellendaten DynamoDB in mehreren gzip-Dateien, wie unten gezeigt.
    / 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

So migrieren Sie die JSON-Daten DynamoDB in die Oracle NoSQL Database:
  1. Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit den identifizierten Quell- und Sink-Details vor. Weitere Informationen finden Sie unter Quellkonfigurationsvorlagen und Sinkkonfigurationsvorlagen.

    Hinweis:

    Wenn die exportierten JSON-Tabellenelemente von DynamoDB das TTL-Attribut enthalten, geben Sie zum optionalen Importieren der TTL-Werte das Attribut im Konfigurationsparameter ttlAttributeName der Quellkonfigurationsvorlage an, und setzen Sie den Konfigurationsparameter includeTTL in der Sink-Konfigurationsvorlage auf "true".
    Sie können eine der beiden folgenden Optionen wählen.
    • Option 1: Die Tabelle DynamoDB wird mit der Standardschemakonfiguration als JSON-Dokument importiert.

      Hier setzen Sie den Konfigurationsparameter defaultSchema auf "true". Daher erstellt der NoSQL Database Migrator das Standardschema an der Senke. Sie müssen den Spaltentyp DDBPartitionKey und den entsprechenden Spaltentyp NoSQL angeben. Andernfalls wird ein Fehler angezeigt.

      Details zum Standardschema für eine exportierte JSON-Quelle von DynamoDB finden Sie unter dem Thema Quelle und Sink identifizieren in Workflow für Oracle NoSQL Database Migrator. 
      {
  "source" : {
    "type" : "file",
    "format" : "dynamodb_json",
    "ttlAttributeName" : "ttl",
    "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "sampledynDBImp",
    "includeTTL" : true,
    "schemaInfo" : {
      "DDBPartitionKey" : "Id:INTEGER",
      "defaultSchema" : true
    },
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.6.5"
}
      In diesem Beispiel wird das folgende Standardschema verwendet:
      CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
    • Option 2: Importieren Sie die Tabelle DynamoDB als feste Spalten mit einer vom Benutzer bereitgestellten Schemadatei.

      Hier legen Sie den Konfigurationsparameter defaultSchema auf "false" fest. Daher geben Sie die Datei mit der DDL-Anweisung der Sink-Tabelle im Parameter schemaPath an. Weitere Informationen finden Sie unter Zuordnung von DynamoDB-Typen zu Oracle-NoSQL-Typen .

      In diesem Beispiel wird das folgende benutzerdefinierte Schema verwendet:
      CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))

      NoSQL Database Migrator verwendet die Schemadatei, um die Tabelle an der Sink im Rahmen der Migration zu erstellen. Solange die Primärschlüsseldaten angegeben sind, wird der Eingabe-JSON-Datensatz eingefügt. Andernfalls wird ein Fehler angezeigt.

      Hinweis:

      • Wenn die Dynamo-DB-Tabelle einen Datentyp aufweist, der in der NoSQL-Datenbank nicht unterstützt wird, verläuft die Migration nicht erfolgreich.
      • Wenn die Eingabedaten keinen Wert für eine bestimmte Spalte (mit Ausnahme des Primärschlüssels) enthalten, wird der Spaltenstandardwert verwendet. Der Standardwert muss beim Erstellen der Tabelle Teil der Spaltendefinition sein. Beispiel: id INTEGER not null default 0. Wenn die Spalte keine Standarddefinition enthält, wird SQL NULL eingefügt, wenn keine Werte für die Spalte angegeben werden.
      • Wenn Sie die Tabelle DynamoDB als JSON-Dokument modellieren, stellen Sie sicher, dass Sie die Transformation AggregateFields verwenden, um nicht-primäre Schlüsseldaten in eine JSON-Spalte zu aggregieren. Details finden Sie unter aggregateFields . 
      {
  "source" : {
    "type" : "file",
    "format" : "dynamodb_json",
    "ttlAttributeName" : "ttl",
    "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "sampledynDBImp",
    "includeTTL" : true,
    "schemaInfo" : {
      "schemaPath" : "<full path of the schema file with the DDL statement>"
    },
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "transforms": {
    "aggregateFields" : {
      "fieldName" : "document",
      "skipFields" : ["Id"]
    }
  },
  "abortOnError" : true,
  "migratorVersion" : "1.6.5"
}
  2. Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Utility NoSQL Database Migrator extrahiert haben.
  3. Führen Sie den Befehl runMigrator aus, indem Sie separate Konfigurationsdateien für die Optionen 1 und 2 übergeben. Verwenden Sie die Option --config oder -c.
    ./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. Das Utility fährt mit der Datenmigration fort, wie im folgenden Beispiel dargestellt:
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [nosqldb sink] : start loading DDLs
[INFO] [nosqldb sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
[INFO] [nosqldb sink] : completed loading DDLs
[INFO] migration started
[INFO] Start writing data to OnDB Sink
[INFO] executing for source:DynamoSample
[INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz
[INFO] Writing data to OnDB Sink completed.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 45ms
Migration completed.

Validierung

Starten Sie die SQL-Eingabeaufforderung in Ihrem Datenspeicher.
 java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
Prüfen Sie, ob die neue Tabelle mit den Quelldaten erstellt wird:
SELECT * FROM sampledynDBImp

Ausgabe

Beachten Sie, dass die TTL-Informationen für jedes importierte Element im JSON-Objekt _metadata enthalten sind.
{"Id":102,"document":{"Address":{"City":"Wales","DoorNum":1024,"Street":"32 main","Zip":560014},"Age":48,"FavColors":["Blue"],"FavNumbers":[10],"FirstName":"John","LastName":"White","Phones":[["222-222"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}
{"Id":101,"document":{"Address":{"City":"London","DoorNum":201,"Street":"21 main","Zip":570004},"Age":22,"FavColors":["Red","Green"],"FavNumbers":[10],"FirstName":"Fred","LastName":"Smith","Phones":[["555-222","123-567"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}

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.

Eine JSON-Beispieldatei im Format DynamoDB lautet wie folgt:
{"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 .oci unter 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

So migrieren Sie die JSON-Daten DynamoDB in Oracle NoSQL Database:
  1. Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit den identifizierten Quell- und Sink-Details vor. Weitere Informationen finden Sie unter Quellkonfigurationsvorlagen und Sinkkonfigurationsvorlagen.

    Hinweis:

    Wenn die Elemente in der JSON-Datei DynamoDB in AWS S3 das TTL-Attribut enthalten, geben Sie zum optionalen Importieren der TTL-Werte das Attribut im Konfigurationsparameter ttlAttributeName der Quellkonfigurationsvorlage an, und setzen Sie den Konfigurationsparameter includeTTL in der Sink-Konfigurationsvorlage auf "true". Weitere Informationen finden Sie unter TTL-Metadaten für Tabellenzeilen migrieren.
    Sie können eine der beiden folgenden Optionen wählen.
    • Option 1: Die Tabelle DynamoDB wird mit der Standardschemakonfiguration als JSON-Dokument importiert.
      Hier ist defaultSchema TRUE. Daher erstellt der Migrator das Standardschema an der Senke. Sie müssen den Spaltentyp DDBPartitionKey und den entsprechenden Spaltentyp NoSQL 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.6.5"
}
      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 = Wert, der für den Partitionsschlüssel in der Konfiguration angegeben wird

      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 defaultSchema FALSE, und Sie geben schemaPath als Datei mit Ihrer DDL-Anweisung an. Weitere Informationen finden Sie unter Zuordnung von DynamoDB-Typen zu Oracle-NoSQL-Typen .

      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.
      • Wenn Sie die Tabelle DynamoDB als JSON-Dokument modellieren, stellen Sie sicher, dass Sie die Transformation AggregateFields verwenden, um nicht-primäre Schlüsseldaten in eine JSON-Spalte zu aggregieren. Details finden Sie unter aggregateFields . 
      {
 "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
 },
  "transforms": {
    "aggregateFields" : {
      "fieldName" : "document",
      "skipFields" : ["AccountId"]
    }
  },
 "abortOnError" : true,
 "migratorVersion" : "1.6.5"
}
  2. Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Datenbankmigrator-Utility NoSQL extrahiert haben.
  3. Führen Sie den Befehl runMigrator aus, indem Sie die Konfigurationsdatei mit der Option --config oder -c übergeben.
    [~/nosqlMigrator]$./runMigrator 
--config <complete/path/to/the/JSON/config/file>
  4. 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.

Voraussetzungen
  • 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_data in der Region Ashburn.
      Die Tabelle user_data enthä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
    • Sink: Die Tabelle user_data im 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

  • 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/config mit 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/config verwenden.

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.

Im Parameter 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=23456
Vorgehensweise
Um die Tabelle user_data aus der Region Ashburn in die Region Phoenix zu migrieren, führen Sie die folgenden Schritte aus:
  1. Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit den identifizierten Quell- und Sinkdetails vor. Siehe Quellkonfigurationsvorlagen und Sink-Konfigurationsvorlagen.
    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "user_data",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "readUnitsPercent" : 100,
    "includeTTL" : false,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "user_data",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma",
    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT2",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.5.0"
}
  2. Navigieren Sie auf Ihrem Rechner zu dem Verzeichnis, in das Sie das Utility NoSQL Database Migrator extrahiert haben. Sie können den Befehl runMigrator über die Befehlszeilenschnittstelle aufrufen.
  3. Führen Sie den Befehl runMigrator aus, indem Sie die Konfigurationsdatei mit der Option --config oder -c übergeben.
    [~/nosql-migrator-1.5.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. Das Utility fährt mit der Datenmigration fort, wie unten gezeigt. Die Tabelle user_data wird an der Senke mit demselben Schema wie die Quelltabelle erstellt, wie Sie den Parameter useSourceSchema in der Senkekonfigurationsvorlage als "true" konfiguriert haben. 
    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS user_data (id INTEGER, firstName STRING, lastName STRING, otherNames ARRAY(RECORD(first STRING, last STRING)), age INTEGER, income INTEGER, address JSON, connections ARRAY(INTEGER), email STRING, communityService STRING, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
[cloud sink] : start loading records
migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
Elapsed time: 0min 5sec 603ms
Migration completed.

    Hinweis:

    • Wenn die Tabelle bereits in der Senke mit demselben Schema wie die Quelltabelle vorhanden ist, werden die Zeilen mit denselben Primärschlüsseln überschrieben, da Sie den Parameter overwrite in der Konfigurationsvorlage als "true" angegeben haben.
    • Wenn die Tabelle bereits in der Sink mit einem anderen Schema als der Quelltabelle vorhanden ist, verläuft die Migration nicht erfolgreich.
Validierung

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.

Voraussetzungen
  • 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 NDCSupload in der Region Oracle NoSQL Database Cloud Service Ashburn.

      Beachten Sie zur Demonstration die folgenden Daten in der Tabelle NDCSupload:
      {"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

    • 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 Objekte in Object Storage schreiben.
Vorgehensweise
Um die Tabelle 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:
  1. Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit den identifizierten Quell- und Sinkdetails vor. Siehe Quellkonfigurationsvorlagen und Sink-Konfigurationsvorlagen. Stellen Sie sicher, dass Sie den Parameter useDelegationToken in Quell- und Sinkkonfigurationsvorlagen auf true setzen.
    In diesem Anwendungsfall wird die folgende Konfigurationsvorlage verwendet:
    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "NDCSupload",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
    "useDelegationToken" : true,
    "readUnitsPercent" : 90,
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "",
    "bucket" : "Migrate_oci",
    "prefix" : "Delegation",
    "chunkSize" : 32,
    "compression" : "",
    "useDelegationToken" : true
  },
  "abortOnError" : true,
  "migratorVersion" : "1.6.0"
}
  2. Navigieren Sie in der Cloud Shell zu dem Verzeichnis, in das Sie das Utility NoSQL Database Migrator extrahiert haben.
  3. Führen Sie den Befehl runMigrator aus, indem Sie die Konfigurationsdatei mit der Option --config oder -c übergeben.
    [~/nosql-migrator-1.6.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. Das Utility NoSQL Database Migrator fährt mit der Datenmigration fort. Wenn Sie den Parameter useDelegationToken auf true gesetzt haben, authentifiziert sich die Cloud Shell automatisch mit dem Delegationstoken, während das Utility NoSQL Database Migrator ausgeführt wird. Der NoSQL Database Migrator kopiert Ihre Daten aus der Tabelle NDCSupload in eine JSON-Datei im Objektspeicher-Bucket Migrate_oci. Prüfen Sie die Logs auf eine erfolgreiche Datensicherung.
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] migration started
[INFO] [OCI OS sink] : writing table schema to Delegation/Schema/schema.ddl
[INFO] [OCI OS sink] : start writing records with prefix Delegation
[INFO] migration completed.
Records provided by source=4,Records written to sink=4,Records failed=0.
Elapsed time: 0min 0sec 486ms
Migration completed.

    Hinweis:

    Daten werden in die Datei kopiert: Migrate_oci/NDCSupload/Delegation/Data/000000.json

    Je nach Parameter chunkSize in der Senken-Konfigurationsvorlage können die Quelldaten in mehrere JSON-Dateien im selben Verzeichnis aufgeteilt werden.

    Das Schema wird in die Datei Migrate_oci/NDCStable1/Delegation/Schema/schema.ddl kopiert.

Validierung

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.

Mit OKE-Authentifizierung von OCI Object Storage zu Oracle NoSQL Database Cloud Service migrieren

In diesem Beispiel wird gezeigt, wie Sie den Oracle NoSQL Database-Migrator mit der OKE-Workload-Identitätsauthentifizierung verwenden, um Daten aus einer JSON-Datei im OCI Object Storage in die Tabelle Oracle NoSQL Database Cloud Service zu kopieren.

Anwendungsfall

Als Entwickler untersuchen Sie eine Option, mit der Sie Daten aus einer JSON-Datei im OCI Object Storage-(OCI OS-)Bucket mit NoSQL Database Migrator in einer containerisierten Anwendung in die Oracle NoSQL Database Cloud Service-(NDCS-)Tabelle zurückschreiben können. Eine Container-Anwendung ist eine virtualisierte Umgebung, in der die Anwendung und alle ihre Abhängigkeiten (wie Bibliotheken, Binärdateien und Konfigurationsdateien) in einem Package gebündelt werden. Dadurch kann die Anwendung unabhängig von der zugrunde liegenden Infrastruktur konsistent in verschiedenen Umgebungen ausgeführt werden.

Sie möchten NoSQL Database Migrator in einem Oracle Cloud Infrastructure Container Engine for Kubernetes-(OKE-)Pod ausführen. Um über den OKE-Pod sicher auf OCI-BS- und NDCS-Services zuzugreifen, verwenden Sie die Workload Identity Authentication-(WIA-)Methode.

In dieser Demonstration erstellen Sie ein Docking-Image für NoSQL Database Migrator, kopieren das Image in ein Repository in der Container Registry, erstellen ein OKE-Cluster, und stellen das Migrator-Image im OKE-Clusterpod bereit, um das Utility Migrator auszuführen. Hier geben Sie eine manuell erstellte NoSQL Database Migrator-Konfigurationsdatei an, um das Migrator-Utility als containerisierte Anwendung auszuführen.

Voraussetzungen
  • Identifizieren Sie die Quelle und den Sink für die Migration.
    • Quelle: JSON-Dateien und Schemadatei im OCI-BS-Bucket.
      Identifizieren Sie den Regionsendpunkt, den Namespace, den Bucket und das Präfix für den OCI-BS-Bucket, in dem die Quell-JSON-Dateien und das Quellschema verfügbar sind. Weitere Informationen finden Sie unter Auf Oracle Cloud Object Storage zugreifen. Die Liste der OCI-BS-Serviceendpunkte finden Sie unter Object Storage-Endpunkte.
      • Endpunkt: us-ashburn-1
      • Bucket: Migrate_oci
      • Präfix: userSession
      • Namespace: idhkv1iewjzj
        Der Namespace-Name für einen Bucket stimmt mit dem Namespace des Mandanten überein und wird beim Erstellen Ihres Mandanten automatisch generiert. Sie können den Namespace-Namen wie folgt abrufen:
        • Navigieren Sie in der Oracle NoSQL Database Cloud Service-Konsole zu Speicher > Buckets.
        • Wählen Sie im Listengeltungsbereich das Compartment aus, und wählen Sie den Bucket aus. Auf der Seite Bucket-Details wird der Name im Parameter Namespace angezeigt.

        Wenn Sie keinen OCI-BS-Namespace-Namen angeben, verwendet das Migrator-Utility den Standard-Namespace des Mandanten.

    • Sink: Tabelle users in Oracle NoSQL Database Cloud Service.

      Geben Sie entweder den Regionsendpunkt oder den Serviceendpunkt und den Compartment-Namen für die Sink an:

      • Endpunkt: us-ashburn-1
      • Compartment: ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma

      Geben Sie das Schema der Sink-Tabelle an:

      Um den Tabellennamen und das im OCI-BS-Bucket gespeicherte Schema zu verwenden, setzen Sie den Parameter useSourceSchema auf "true". Weitere Informationen zu anderen Schemaoptionen finden Sie im Thema Quelle und Sink identifizieren in Workflow für Oracle NoSQL Database-Migrator.

      Hinweis:

      Stellen Sie sicher, dass Sie über die Schreibberechtigungen für das Compartment verfügen, in dem Sie Daten in der NDCS-Tabelle wiederherstellen. Weitere Details finden Sie unter Compartments verwalten.
  • Bereiten Sie ein Docker-Image für NoSQL Database Migrator vor, und verschieben Sie es in Container Registry.
    1. Rufen Sie den Mandanten-Namespace über die OCI-Konsole ab.

      Melden Sie sich bei der Oracle NoSQL Database Cloud Service-Konsole an. Wählen Sie in der Navigationsleiste das Menü Profil und dann Mandant: <Mandantenname> aus.

      Kopieren Sie den Object Storage-Namespace-Namen (den Mandanten-Namespace) in die Zwischenablage.

    2. Erstellen Sie ein Docker-Image für das Migrator-Utility.
      Navigieren Sie zu dem Verzeichnis, in das Sie das Utility NoSQL Database Migrator extrahiert haben. Das Migrator-Package enthält eine Docker-Datei namens Dockerfile. Verwenden Sie über eine Befehlsschnittstelle den folgenden Befehl, um ein Docker-Image des Migrator-Utilitys zu erstellen: 
      #Command:
docker build -t nosqlmigrator:<tag> .
      #Example:
docker build -t nosqlmigrator:1.0 .
      Sie können eine Versions-ID für das Docker-Image in der Option tag angeben. Prüfen Sie Ihr Docker-Image mit dem folgenden Befehl:
      #Command:
Docker images
      #Example output
------------------------------------------------------------------------------------------

REPOSITORY                 TAG          IMAGE ID         CREATED         SIZE
localhost/nosqlmigrator    1.0          e1dcec27a5cc     10 seconds ago  487 MB
quay.io/podman/hello       latest       83fc7ce1224f     10 months ago   580 kB
docker.io/library/openjdk  17-jdk-slim  8a3a2ffec52a     2 years ago     406 MB

------------------------------------------------------------------------------------------
    3. Generieren Sie ein Autorisierungstoken.

      Sie benötigen ein Authentifizierungstoken, um sich bei der Container Registry anzumelden und das Migrator-Docker-Image zu speichern. Wenn Sie noch kein Authentifizierungstoken haben, müssen Sie eines generieren. Weitere Informationen finden Sie unter Authentifizierungstoken abrufen.

    4. Speichern Sie das Migrator-Docker-Image in Container Registry.

      Um über den Kubernetes-Pod auf das Migrator-Docker-Image zuzugreifen, müssen Sie das Image in einer öffentlichen oder privaten Registry speichern. Beispiel: Docker, Artifact Hub, OCI Container Registry usw. sind einige Registrys. In dieser Demonstration verwenden wir Container Registry. Weitere Informationen finden Sie unter Überblick über Container Registry.

      1. Erstellen Sie in der OCI-Konsole ein Repository in der Container Registry. Weitere Informationen finden Sie unter Repository erstellen.

        Für diese Demonstration erstellen Sie das Repository okemigrator.

        Abbildung - Repository in Container Registry


        Beschreibung von Abbildung - folgt
        Beschreibung von "Figure - Repository in Container Registry"

      2. Melden Sie sich über die Befehlsschnittstelle mit dem folgenden Befehl bei der Container Registry an:
        #Command:
docker login <region-key>.ocir.io -u <tenancy-namespace>/<user name>password: <Auth token>
        #Example:
docker login iad.ocir.io -u idhx..xxwjzj/rx..xxxxh@oracle.com
password: <Auth token>
        #Output:
Login Succeeded!

        Im obigen Befehl gilt:

        region-key: Gibt den Schlüssel für die Region an, in der Sie Container Registry verwenden. Weitere Informationen finden Sie unter Verfügbarkeit nach Region.

        tenancy-namespace: Gibt den Mandanten-Namespace an, den Sie aus der OCI-Konsole kopiert haben.

        user name: Gibt den Benutzernamen der OCI-Konsole an.

        password: Gibt das Authentifizierungstoken an.

      3. Taggen und übertragen Sie Ihr Migrator-Docker-Image mit den folgenden Befehlen in Container Registry:
        #Command:
docker tag <Migrator Docker image> <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>
docker push <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>
        #Example:
docker tag localhost/nosqlmigrator:1.0 iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
docker push iad.ocir.io/idhx..xxwjzj/okemigrator:1.0

        Im obigen Befehl gilt Folgendes:

        repo: Gibt den Namen des Repositorys an, das Sie in Container Registry erstellt haben.

        tag: Gibt die Versions-ID für das Docker-Image an. 

        #Output:
Getting image source signatures
Copying blob 0994dbbf9a1b done   | 
Copying blob 37849399aca1 done   | 
Copying blob 5f70bf18a086 done   | 
Copying blob 2f263e87cb11 done   | 
Copying blob f941f90e71a8 done   | 
Copying blob c82e5bf37b8a done   | 
Copying blob 2ad58b3543c5 done   | 
Copying blob 409bec9cdb8b done   | 
Copying config e1dcec27a5 done   | 
Writing manifest to image destination
  • Konfigurieren Sie ein OKE-Cluster mit WIA zu NDCS und OCI OS.
    1. Erstellen Sie ein Kubernetes-Cluster mit OKE.

      Definieren und erstellen Sie über die OCI-Konsole ein Kubernetes-Cluster basierend auf der Verfügbarkeit von Netzwerkressourcen mit OKE. Sie benötigen ein Kubernetes-Cluster, um das Migrator-Utility als containerisierte Anwendung auszuführen. Details zur Clustererstellung finden Sie unter Kubernetes-Cluster mit Konsolenworkflows erstellen.

      Für diese Demonstration können Sie ein auf einem Knoten verwaltetes Cluster mit dem Workflow Schnellerstellung erstellen, der im obigen Link beschrieben ist.

      Abbildung - Kubernetes-Cluster für Migratorcontainer


      Beschreibung von Abbildung - folgt
      Beschreibung von "Abbildung - Kubernetes-Cluster für Migrator Container"

    2. Richten Sie WIA über die OCI-Konsole ein, um über das Kubernetes-Cluster auf andere OCI-Ressourcen zuzugreifen.

      Um Migrator-Utilityzugriff auf NDCS- und OCI-BS-Bucket bei der Ausführung über die Kubernetes-Clusterpods zu erteilen, müssen Sie WIA einrichten. Gehen Sie wie folgt vor:

      1. Richten Sie die kubeconfig-Konfigurationsdatei des Clusters ein.
        • Öffnen Sie in der OCI-Konsole das von Ihnen erstellte Kubernetes-Cluster, und klicken Sie auf die Schaltfläche Auf Cluster zugreifen.
        • Klicken Sie im Dialogfeld Auf Cluster zugreifen auf Cloud Shell-Zugriff.
        • Klicken Sie auf Cloud Shell starten, um das Cloud Shell-Fenster anzuzeigen.
        • Führen Sie den Oracle Cloud Infrastructure-CLI-Befehl zum Einrichten der kubeconfig-Datei aus. Sie können den Befehl im Dialogfeld Auf Cluster zugreifen kopieren. Sie können die folgende Ausgabe erwarten:
          #Example:  
oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aaa...muqzq --file $HOME/.kube/config --region us-ashburn-1 --token-version 2.0.0  --kube-endpoint PUBLIC_ENDPOINT
          #Output:
New config written to the Kubeconfig file /home/<user>/.kube/config
      2. Kopieren Sie die OCID des Clusters aus der Option cluster-id im obigen Befehl, und speichern Sie sie, um sie in weiteren Schritten zu verwenden.
        ocid1.cluster.oc1.iad.aaa...muqzq
      3. Erstellen Sie einen Namespace für den Kubernetes-Serviceaccount mit dem folgenden Befehl im Cloud-Shellfenster:
        #Command:
kubectl create namespace <namespace-name>
        #Example:
kubectl create namespace migrator
        #Output:
namespace/migrator created
      4. Erstellen Sie einen Kubernetes-Serviceaccount für die Migrator-Anwendung in einem Namespace mit dem folgenden Befehl im Cloud-Shellfenster:
        #Command:
kubectl create serviceaccount <service-account-name> --namespace <namespace-name>
        #Example:
kubectl create serviceaccount migratorsa --namespace migrator
        #Output:
serviceaccount/migratorsa created
      5. Definieren Sie eine IAM-Policy über die OCI-Konsole, damit die Workload über das Kubernetes-Cluster auf die OCI-Ressourcen zugreifen kann.

        Navigieren Sie in der OCI-Konsole durch die Menüs Identität und Sicherheit > Identität > Policys. Erstellen Sie die folgenden Policys, um den Zugriff auf nosql-family- und object-family-Ressourcen zuzulassen. Verwenden Sie die OCID der Cluster-, Namespace- und Serviceaccountwerte aus den vorherigen Schritten. 

        #Command:
Allow <subject> to <verb> <resource-type> in <location> where <conditions>
        #Example:
Allow any-user to manage nosql-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}

Allow any-user to manage object-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}

        Weitere Informationen zum Erstellen von Policys finden Sie unter Policy mit der Konsole erstellen.

Vorgehensweise

Um aus der JSON-Datei im OCI-BS-Bucket in die NDCS-Tabelle zu migrieren, führen Sie im Cloud Shell-Fenster Folgendes aus:

  1. Bereiten Sie eine Migrator-Konfigurationsdatei, migrator-config.json, mit der OCI-BS-Quelle und der NDCS-Senke vor. Informationen zu Vorlagen finden Sie unter Quellkonfigurationsvorlagen und Sinkkonfigurationsvorlagen.

    Um OKE WIA für den Zugriff auf OCI-BS-Bucket und NDCS zu verwenden, setzen Sie den Parameter useOKEWorkloadIdentity sowohl in Quell- als auch in Sink-Konfigurationsvorlagen auf "true". Hier verwenden Sie das Quellschema aus der Schema-DDL-Datei im OCI-BS-Bucket. Setzen Sie daher den Parameter useSourceSchema in der Sink-Konfigurationsvorlage auf "true".

    Hinweis:

    Wenn Sie OKE WIA verwenden, können Sie die Migrationskonfigurationsdatei nicht interaktiv generieren. Sie müssen die Konfigurationsdatei manuell vorbereiten, indem Sie sich auf die Vorlagen für die Quell- und Sink-Konfiguration beziehen. 
    {
  "source" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "useOKEWorkloadIdentity" : true
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "compartment" : "Training-NoSQL",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "useOKEWorkloadIdentity" : true,
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. Erstellen Sie eine Konfigurationszuordnungsressource (configmap), um die migrator-config.json-Konfigurationseingabedatei zur Laufzeit im Kubernetes-Pod an den Migrator-Container zu übergeben. Die Konfigurationsdatei Migrator wird im Dateisystem des Containers als Mount-Volume gemountet.
    #Command:
kubectl create configmap oci-migrator-config --from-file=<Migrator configuration file> -n <namespace-name>
    #Example:
kubectl create configmap oci-migrator-config --from-file=migrator-config.json -n migrator
    #Output:
configmap/oci-migrator-config created
  3. Erstellen Sie ein Docker-Registry Secret, das die OCI-Zugangsdaten enthält, die beim Abrufen des Migrator-Docker-Images aus Container Registry in den Kubernetes-Pod verwendet werden sollen.
    #Command:
kubectl create secret docker-registry ocirsecret --docker-server=<region-key>.ocir.io --docker-username='tenancy-namespace/username' --docker-password='auth token' --docker-email='<user Email>' -n <namespace-name>
    #Example:
kubectl create secret docker-registry ocirsecret --docker-server=iad.ocir.io --docker-username='idhx..xxwjzj/rx..xxxxh@oracle.com' --docker-password='<Auth token>' --docker-email='rx..xxxxh@oracle.com' -n migrator
    #Output:
secret/ocirsecret created
  4. Erstellen Sie eine Manifestdatei, mit der Sie das Migrator-Docker-Image angeben. Stellen Sie sicher, dass Sie die Werte aus den vorherigen Schritten für Namespace, Kubernetes-Serviceaccountname, Docker-Imagename, Docker-Registry Secret und configmap angeben. Sie können sich auf die folgende Beispielmanifestdatei beziehen:
    #migrator-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nosql-migrator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nosql-migrator
  template:
    metadata:
      labels:
        app: nosql-migrator
    spec:
      serviceAccountName: migratorsa
      automountServiceAccountToken: true
      containers:
        - name: nosqlmigrator
          image: iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
          imagePullPolicy: Always
          args: ["--config", "/config/migrator-config.json", "--log-level", "DEBUG"]
          volumeMounts:
            - name: config-volume
              mountPath: /config  # Mount the file here
      imagePullSecrets:
        - name: ocirsecret
      volumes:
        - name: config-volume
          configMap:
            name: oci-migrator-config
  5. Stellen Sie das Docker-Image des Migrators im Kubernetes-Pod mit dem folgenden Befehl bereit. OKE führt das Utility Migrator in einem Container auf einem der Knoten des Kubernetes-Clusters aus.
    #Command:
kubectl create -f <manifest file> -n <namespace-name>
    #Example:
kubectl create -f migrator-deployment.yaml -n migrator
    #Output:
deployment.apps/nosql-migrator created
  6. Sie können die Logs mit den folgenden Befehlen prüfen:
    1. Rufen Sie den Podnamen ab, auf dem das Migrator-Utility ausgeführt wird.
      #Command:
kubectl get pods -n <namespace-name>
      #Example:
kubectl get pods -n migrator
      #Output:
NAME                            READY   STATUS    RESTARTS   AGE
nosql-migrator-ccdbf549-6sjjg   1/1     Running   0          56s
    2. Verwenden Sie den Podnamen, um die Migratorlogs abzurufen.
      #Command:
kubectl logs -f <kubernetes cluster pod name> -n <namespace-name>
      #Example:
kubectl logs -f nosql-migrator-ccdbf549-6sjjg -n migrator
      #Output:
SLF4J(I): Connected with provider of type [org.apache.logging.slf4j.SLF4JServiceProvider]
[INFO] Configuration for migration:
{
  "source" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "idhkv1iewjzj",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "useOKEWorkloadIdentity" : true
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "compartment" : "Training-NoSQL",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "useOKEWorkloadIdentity" : true,
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
[INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] migration started
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : completed loading DDLs
[INFO] [cloud sink] : start loading records
[INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_1_5_0.json
[INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_6_10_0.json
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
Elapsed time: 0min 1sec 15ms
Migration completed.

    Hinweis:

    Sie können die Datenmigration wie folgt iterativ ausführen:

    1. Löschen Sie den Container nosql-migrator mit dem folgenden Befehl:
      #Command:
kubectl delete -f <manifest file> -n <namespace-name>
      #Example:
kubectl delete -f migrator-deployment.yaml -n migrator
      #Output:
deployment.apps "nosql-migrator" deleted
    2. Aktualisieren Sie die Konfigurationseingabedatei migrator-config.json.
    3. Löschen und erstellen Sie die configmap mit den Befehlen aus Schritt 2 neu.

      Es ist nicht erforderlich, das Docker-Registry Secret und die Manifestdatei erneut zu erstellen.

    4. Stellen Sie das Docker-Image des Migrators im Kubernetes-Pod mit der Manifestdatei bereit (Schritt 5).
Verifizierung

Um die Datenwiederherstellung zu prüfen, melden Sie sich bei der Oracle NoSQL Database Cloud Service-Konsole an. Gehen Sie in der Navigationsleiste zu Datenbanken > NoSQL-Datenbank. Wählen Sie Ihr Compartment in der Dropdown-Liste aus, um die Tabelle users anzuzeigen. Informationen zum Zugriff auf die Konsole finden Sie unter Über die Infrastructure-Konsole auf den Service zugreifen.

Mit Sessiontokenauthentifizierung von Oracle NoSQL Database zu OCI Object Storage migrieren

In diesem Beispiel wird gezeigt, wie Sie Oracle NoSQL Database Migrator mit Sessiontokenauthentifizierung verwenden, um Daten aus der Oracle NoSQL Database-Tabelle in eine JSON-Datei in einem OCI Object Storage-Bucket zu kopieren.

Anwendungsfall

Als Entwickler untersuchen Sie eine Option, um Oracle NoSQL Database-Tabellendaten in OCI Object Storage (OCI OS) zu sichern. Sie möchten die tokenbasierte Sessionauthentifizierung verwenden.

In dieser Demonstration verwenden Sie die OCI Command Line Interface-Befehle (CLI), um ein Sessiontoken zu erstellen. Sie erstellen manuell eine Migrator-Konfigurationsdatei und führen die Datenmigration aus.

Voraussetzungen
  • Identifizieren Sie Quelle und Sink für die Migration.
    • Quelle: Tabelle users in Oracle NoSQL Database.
    • Sink: JSON-Datei im OCI-BS-Bucket

      Identifizieren Sie den Regionsendpunkt, Namespace, Bucket und das Präfix für das OCI-BS. Weitere Informationen finden Sie unter Auf Oracle Cloud Object Storage zugreifen. Die Liste der OCI-BS-Serviceendpunkte finden Sie unter Object Storage-Endpunkte.

      • Endpunkt: us-ashburn-1
      • Bucket: Migrate_oci
      • Präfix: userSession
      • Namespace: idhkv1iewjzj
        Der Namespace-Name für einen Bucket stimmt mit dem Namespace des Mandanten überein und wird beim Erstellen Ihres Mandanten automatisch generiert. Sie können den Namespace-Namen wie folgt abrufen:
        • Navigieren Sie in der Oracle NoSQL Database Cloud Service-Konsole zu Storage > Buckets.
        • Wählen Sie im Listengeltungsbereich das Compartment aus, und wählen Sie den Bucket aus. Auf der Seite Bucket-Details wird der Name im Parameter Namespace angezeigt.

        Wenn Sie keinen OCI-BS-Namespace-Namen angeben, verwendet das Migrator-Utility den Standard-Namespace des Mandanten.

      Hinweis:

      Stellen Sie sicher, dass Sie über die Berechtigungen zum Schreiben von Objekten im OCI-BS-Bucket verfügen. Weitere Informationen zum Festlegen der Policys finden Sie unter In Object Storage schreiben.
  • Generieren Sie ein Sessiontoken wie folgt:
    • OCI-CLI installieren und konfigurieren Siehe Schnellstart.
    • Verwenden Sie einen der folgenden OCI-CLI-Befehle, um ein Sessiontoken zu generieren. Weitere Informationen zu den verfügbaren Optionen finden Sie unter Tokenbasierte Authentifizierung für die CLI.
      #Create a session token using OCI CLI from a web browser:
oci session authenticate --region <region_name> --profile-name <profile_name>
      #Example:
oci session authenticate --region us-ashburn-1 --profile-name SESSIONPROFILE

      oder

      #Create a session token using OCI CLI without a web browser:
oci session authenticate --no-browser --region <region_name> --profile-name <profile_name>
      #Example:
oci session authenticate --no-browser --region us-ashburn-1 --profile-name SESSIONPROFILE

      Im obigen Befehl gilt Folgendes:

      region_name: Gibt den Regionsendpunkt für Ihr OCI-BS an. Eine Liste der in Oracle NoSQL Database Cloud Service unterstützten Datenregionen finden Sie unter Datenregionen und zugehörige Service-URLs.

      profile_name: Gibt das Profil an, mit dem der OCI-CLI-Befehl ein Sessiontoken generiert.

      Der OCI-CLI-Befehl erstellt einen Eintrag in der OCI-Konfigurationsdatei unter dem Pfad $HOME/.oci/config, wie im folgenden Beispiel dargestellt:
      [SESSIONPROFILE]
fingerprint=f1:e9:b7:e6:25:ff:fe:05:71:be:e8:aa:cc:3d:0d:23
key_file=$HOME/.oci/sessions/SESSIONPROFILE/oci_api_key.pem
tenancy=ocid1.tenancy.oc1..aaaaa ... d6zjq
region=us-ashburn-1
security_token_file=$HOME/.oci/sessions/SESSIONPROFILE/token

      Die security_token_file verweist auf den Pfad des Sessiontokens, das Sie mit dem oben angegebenen OCI-CLI-Befehl generiert haben.

      Hinweis:

      • Wenn das Profil bereits in der OCI-Konfigurationsdatei vorhanden ist, überschreibt der OCI-CLI-Befehl das Profil bei der Generierung des Sessiontokens mit der Sessiontoken-Konfiguration.
      • Geben Sie Folgendes in der Sink-Konfigurationsvorlage an:
        • Der Pfad zur OCI-Konfigurationsdatei im Parameter credentials.
        • Das Profil, das beim Generieren des Sessiontokens im Parameter credentialsProfile verwendet wird. 
        "credentials" : "$HOME/.oci/config"
"credentialsProfile" : "SESSIONPROFILE"

        Das Migrator-Utility ruft automatisch die Details des Sessiontokens ab, das mit den oben genannten Parametern generiert wurde. Wenn Sie den Parameter credentials nicht angeben, sucht das Migrator-Utility im Pfad $HOME/.oci nach der Zugangsdatendatei. Wenn Sie den Parameter credentialsProfile nicht angeben, verwendet das Migrator-Utility den Standardprofilnamen (DEFAULT) aus der OCI-Konfigurationsdatei.

      • Das Sessiontoken ist 60 Minuten lang gültig. Um die Sessiondauer zu verlängern, können Sie die Session aktualisieren. Weitere Informationen finden Sie unter Token aktualisieren.
Vorgehensweise

So migrieren Sie von der Oracle NoSQL Database-Tabelle in eine JSON-Datei im OCI-BS-Bucket:

  1. Bereiten Sie die Konfigurationsdatei (im JSON-Format) mit der Oracle NoSQL Database-Quelle und der JSON-Datei in der OCI-BS-Bucket-Senke vor. Informationen zu Vorlagen finden Sie unter Quellkonfigurationsvorlagen und Konfigurationsvorlagen verknüpfen.
    Um die Sessiontokenauthentifizierung für den Zugriff auf den OCI-BS-Bucket zu verwenden, setzen Sie den Parameter useSessionToken in der Sink-Konfigurationsvorlage auf "true". Geben Sie entsprechend den Konfigurationspfad im Parameter credentials und den Profilnamen im Parameter credentialsProfile an. 
    {
  "source" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:<port>"],
    "table" : "users",
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "idhkv1iewjzj",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "chunkSize" : 32,
    "compression" : "",
    "useSessionToken" : true,
    "credentials" : "$/home/.oci/config",
    "credentialsProfile" : "SESSIONPROFILE"
  },
  "abortOnError" : true,
  "migratorVersion" : "<latest>"
}
  2. Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Utility NoSQL Database Migrator extrahiert haben.
  3. Führen Sie den Befehl runMigrator aus, indem Sie die Option "Konfigurationsdatei" übergeben. Übergeben Sie die Konfigurationsdatei mit der Option --config oder -c wie folgt:
    ./runMigrator --config ./migrator-config.json
  4. Das Migrator-Utility fährt mit der Datenmigration fort. Eine Beispielausgabe ist unten dargestellt.
    Wenn der Parameter useSessionToken auf "true" gesetzt ist, authentifiziert das Migratorutility automatisch mit dem Sessiontoken. Das Migrator-Utility kopiert Ihre Daten aus der Tabelle users in eine JSON-Datei im OCI-BS-Bucket Migrate_oci. Prüfen Sie die Logs auf ein erfolgreiches Datenbackup. 
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [OCI OS sink] : writing table schema to userSession/Schema/schema.ddl
[INFO] migration started
[INFO] Migration success for source users_6_10. read=2,written=2,failed=0
[INFO] Migration success for source users_1_5. read=3,written=3,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 982ms
Migration completed.

    Hinweis:

    Je nach Parameter chunkSize in der Sink-Konfigurationsvorlage teilt das Migrator-Utility die Quelldaten in mehrere JSON-Dateien im selben Verzeichnis auf. In diesem Beispiel kopiert das Migrator-Utility Daten in die Dateien users_1_5_0.json und users_6_10_0.json im Verzeichnis Migrate_oci/userSession/Data.

    Das Quelltabellenschema wird in die Datei schema.ddl im Verzeichnis Migrate_oci/userSession/Schema kopiert.

Verifizierung

Um das Datenbackup zu prüfen, 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 userSession im Bucket Migrate_oci auf die Dateien zu. Informationen zum Zugriff auf die Konsole finden Sie unter Ü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.

Voraussetzungen
  • Identifizieren Sie Quelle und 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
  • Die CSV-Datei muss dem Format RFC4180 entsprechen.
  • 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));
Vorgehensweise
Um die CSV-Dateidaten von course.CSV zu Oracle NoSQL Database Service zu migrieren, führen Sie die folgenden Schritte aus:
  1. Öffnen Sie die Eingabeaufforderung, und navigieren Sie zu dem Verzeichnis, in das Sie das Utility Oracle NoSQL Database Migrator extrahiert haben.
  2. Um die Konfigurationsdatei mit Oracle NoSQL Database-Migrator zu generieren, führen Sie den Befehl runMigrator ohne Laufzeitparameter aus.
    [~/nosql-migrator-1.5.0]$./runMigrator
  3. Da Sie die Konfigurationsdatei nicht als Laufzeitparameter angegeben haben, werden Sie vom Utility aufgefordert, die Konfiguration jetzt zu generieren. Geben Sie y ein.
    Sie können einen Speicherort für die Konfigurationsdatei auswählen oder den Standardspeicherort beibehalten, indem Sie Enter key drücken. 
    
Configuration file is not provided. Do you want to generate
configuration? (y/n) [n]: y
Generating a configuration file interactively.

Enter a location for your config [./migrator-config.json]: 
./migrator-config.json already exist. Do you want to overwrite?(y/n) [n]: y
  4. Wählen Sie auf Basis der Eingabeaufforderungen des Utilitys die Optionen für die Quellkonfiguration aus.
    
Select the source: 
1) nosqldb
2) nosqldb_cloud
3) file
4) object_storage_oci
5) aws_s3
#? 3

Configuration for source type=file
Select the source file format: 
1) json
2) mongodb_json
3) dynamodb_json
4) csv
#? 4
  5. Geben Sie den Pfad zur CSV-Quelldatei an. Außerdem können Sie basierend auf den Eingabeaufforderungen des Utilitys die Spaltennamen neu anordnen, die Codierungsmethode auswählen und die Anpassungsbereiche aus der Zieltabelle abschneiden. 
    
Enter path to a file or directory containing csv data: [~/nosql-migrator-1.5.0]/course.csv
Does the CSV file contain a headerLine? (y/n) [n]: n
Do you want to reorder the column names of NoSQL table with respect to
CSV file columns? (y/n) [n]: n
Provide the CSV file encoding. The supported encodings are:
UTF-8,UTF-16,US-ASCII,ISO-8859-1. [UTF-8]: 
Do you want to trim the tailing spaces? (y/n) [n]: n
  6. Wählen Sie auf Basis der Eingabeaufforderungen des Dienstprogramms Ihre Optionen für die Sink-Konfiguration aus. 
    
Select the sink:
1) nosqldb
2) nosqldb_cloud
#? 1
Configuration for sink type=nosqldb
Enter store name of the Oracle NoSQL Database: mystore
Enter comma separated list of host:port of Oracle NoSQL Database: <hostname>:5000
  7. Geben Sie basierend auf den Eingabeaufforderungen des Utilitys den Namen der Zieltabelle an. 
    
Enter fully qualified table name: course
  8. Geben Sie Ihre Auswahl ein, um den TTL-Wert festzulegen. Der Standardwert ist n. 
    
Include TTL data? If you select 'yes' TTL value provided by the
source will be set on imported rows. (y/n) [n]: n
  9. Geben Sie basierend auf den Prompts des Utilitys an, ob die Zieltabelle mit dem Oracle NoSQL Database-Migrator-Tool erstellt werden muss. Wenn die Tabelle bereits erstellt wurde, wird empfohlen, n anzugeben. Wenn die Tabelle nicht erstellt wird, fordert das Utility den Pfad für die Datei mit den DDL-Befehlen für das Schema der Zieltabelle an. 
    
Would you like to create table as part of migration process?
Use this option if you want to create table through the migration tool.
If you select yes, you will be asked to provide a file that contains
table DDL or to use schema provided by the source or default schema.
(y/n) [n]: y
Enter path to a file containing table DDL: [~/nosql-migrator-1.5.0]/mytable_schema.ddl
Is the store secured? (y/n) [y]: n
would you like to overwrite records which are already present?
If you select 'no' records with same primary key will be skipped [y/n] [y]: y
Enter store operation timeout in milliseconds. [5000]:
Would you like to add transformations to source data? (y/n) [n]: n
  10. Geben Sie Ihre Auswahl ein, um zu bestimmen, ob die Migration fortgesetzt werden soll, falls ein Datensatz nicht migriert werden kann. 
    
Would you like to continue migration if any data fails to be migrated? 
(y/n) [n]: n
  11. Das Utility zeigt die generierte Konfiguration auf dem Bildschirm an. 
    
Generated configuration is:
{
  "source" : {
    "type" : "file",
    "format" : "csv",
    "dataPath" : "[~/nosql-migrator-1.5.0]/course.csv",
    "hasHeader" : false,
    "csvOptions" : {
      "encoding" : "UTF-8",
      "trim" : false
    }
  },
  "sink" : {
    "type" : "nosqldb",
    "storeName" : "mystore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "migrated_table",
    "query" : "",
    "includeTTL" : false,
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.5.0]/mytable_schema.ddl"
    },
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.5.0"
}
  12. Abschließend werden Sie vom Utility aufgefordert, anzugeben, ob Sie mit der Migration mit der generierten Konfigurationsdatei fortfahren möchten. Die Standardoption ist y.
    Hinweis: Wenn Sie n auswählen, können Sie die Migration mit der generierten Konfigurationsdatei ausführen. Geben Sie die Option ./runMigrator -c oder ./runMigrator --config an. 
    
Would you like to run the migration with above configuration?
If you select no, you can use the generated configuration file to
run the migration using:
./runMigrator --config ./migrator-config.json
(y/n) [y]: y
  13. Der NoSQL-Datenbankmigrator kopiert Ihre Daten aus der CSV-Datei in Oracle NoSQL Database.
    
creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[nosqldb sink] : start loading DDLs
[nosqldb sink] : executing DDL: create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id))
[nosqldb sink] : completed loading DDLs
[nosqldb sink] : start loading records
[csv file source] : start parsing CSV records from file: course.csv
migration completed. Records provided by source=4, Records written to sink=4, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 559ms
Migration completed.
Validierung
Starten Sie die SQL-Eingabeaufforderung in KVStore.
 java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
Prüfen Sie, ob die neue Tabelle mit den Quelldaten erstellt wird:

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