Oracle NoSQL Database-Migrator - Referenz

Erfahren Sie mehr über die für den Oracle NoSQL Database-Migrator verfügbaren Vorlagenparameter für Quell-, Sink- und Transformationskonfiguration.

Dieser Artikel enthält die folgenden Themen:

Parameter

Der NoSQL-Datenbankmigrator erfordert eine Konfigurationsdatei, in der Sie alle Parameter zur Ausführung der Migrationsaktivität definieren. Einige Parameter sind über mehrere Quellen und Senken hinweg üblich. Dieses Thema enthält eine Liste dieser allgemeinen Parameter. Die Liste der anderen Parameter, die für einzelne Quellen oder Senken eindeutig sind, finden Sie in den entsprechenden Konfigurationsvorlagenabschnitten.

Allgemeine Konfigurationsparameter

Im Folgenden werden die allgemeinen Konfigurationsparameter aufgeführt. Beispiele finden Sie in den einzelnen Konfigurationsvorlagenabschnitten.

bucket

• Zweck: Gibt den Namen des OCI Object Storage-Buckets an, der die Quell-/Sinkobjekte enthält.

  Stellen Sie sicher, dass der erforderliche Bucket bereits in der OCI Object Storage-Instanz vorhanden ist und über Lese-/Schreibberechtigungen verfügt.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J

chunkSize

• Zweck: Gibt die maximale Größe einer chunk der Tabellendaten an, die auf der Senke gespeichert werden sollen. Der Wert ist in MB angegeben. Während der Migration wird eine Tabelle in chunkSize Chunks aufgeteilt, und jeder Chunk wird als separate Datei in die Sink geschrieben. Eine neue Datei wird erstellt, wenn die zu migrierenden Quelldaten den Wert chunkSize überschreiten.

  Wenn keine Angabe gemacht wird, wird standardmäßig 32 MB verwendet. Der gültige Wert ist eine Ganzzahl zwischen 1 und 1024.

• Datentyp: Ganzzahl
• Erforderlich (J/N): N

credentials

• Zweck: Gibt den absoluten Pfad zu einer Datei an, die OCI-Zugangsdaten enthält. Der NoSQL-Datenbankmigrator verwendet diese Datei für die Verbindung zum OCI-Service, wie Oracle NoSQL Database Cloud Service, OCI Object Storage usw.

  Der Standardwert ist $HOME/.oci/config.

  Ein Beispiel für die Zugangsdatendatei finden Sie unter Beispielkonfiguration.

  Hinweis:

  Die Authentifizierungsparameter credentials, useInstancePrincipal und useDelegationToken schließen sich gegenseitig aus. Geben Sie nur einen dieser Parameter in der Konfigurationsvorlage an.
• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

credentialsProfile

• Zweck: Gibt den Namen des Konfigurationsprofils an, das für die Verbindung zum OCI-Service wie Oracle NoSQL Database Cloud Service, OCI Object Storage usw. verwendet werden soll. Die Zugangsdaten des Benutzeraccounts werden als Profil bezeichnet.

  Wenn Sie diesen Wert nicht angeben, verwendet der NoSQL Database Migrator das Profil DEFAULT.

  Hinweis:

  Dieser Parameter ist nur gültig, wenn der Parameter credentials angegeben ist.
• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

endpoint

• Zweck: Gibt eine der folgenden Optionen an:
  • Die Serviceendpunkt-URL oder die Regions-ID für den OCI Object Storage-Service.

    Die Liste der OCI Object Storage-Serviceendpunkte finden Sie unter Object Storage-Endpunkte.

  • Die Serviceendpunkt-URL oder die Regions-ID für Oracle NoSQL Database Cloud Service.

    Sie können entweder die vollständige URL oder die Regions-ID allein angeben. Die Liste der Datenregionen, die für Oracle NoSQL Database Cloud Service unterstützt werden, finden Sie unter Data Regions und zugehörige Service-URLs im Oracle NoSQL Database Cloud Service-Dokument.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J

Format

• Zweck: Gibt das Quell-/Sinkformat an.
• Datentyp: Zeichenfolge
• Erforderlich (J/N): J

Namespace

• Zweck: Gibt den Namespace des OCI Object Storage-Service an. Dies ist ein optionaler Parameter. Wenn Sie diesen Parameter nicht angeben, wird der Standard-Namespace des Mandanten verwendet.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

Präfix

• Zweck: Das Präfix fungiert als logischer Container oder Verzeichnis zum Speichern von Daten im OCI Object Storage-Bucket.

  • Quellkonfigurationsvorlage: Wenn der angegebene Parameter prefix angegeben ist, werden alle Objekte aus dem Verzeichnis migriert, das im Parameter prefix benannt ist. Andernfalls werden alle im Bucket vorhandenen Objekte migriert.
  • Sinkkonfigurationsvorlage: Wenn der Parameter prefix angegeben wird, wird ein Verzeichnis mit dem angegebenen Präfix im Bucket erstellt und die Objekte in dieses Verzeichnis migriert. Andernfalls wird der Tabellenname aus der Quelle als Präfix verwendet. Wenn bereits ein Objekt mit demselben Namen im Bucket vorhanden ist, wird es überschrieben.

  Weitere Informationen zu Präfixen finden Sie unter Object Naming Using Prefixes and Hierarchies.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

requestTimeoutMs

• Zweck: Gibt an, wie lange auf den Abschluss jedes Lese-/Schreibvorgangs vom/zum Speicher gewartet wird. Dieser Wert wird in Millisekunden angegeben. Der Standardwert ist 5000. Der Wert kann eine beliebige positive Ganzzahl sein.

• Datentyp: Ganzzahl
• Erforderlich (J/N): N

security

• Zweck: Gibt den absoluten Pfad zur Sicherheitsanmeldedatei an, die Ihre Speicherzugangsdaten enthält, wenn Ihr Speicher ein sicherer Speicher ist. Weitere Informationen zur Sicherheitsanmeldedatei finden Sie unter Configuring Security with Remote Access im Administrator's Guide.

  Sie können entweder eine kennwortdateibasierte Authentifizierung oder eine Wallet-basierte Authentifizierung verwenden. Die Wallet-basierte Authentifizierung wird jedoch nur in der Enterprise Edition (EE) von Oracle NoSQL Database unterstützt. Weitere Informationen zur Wallet-basierten Authentifizierung finden Sie unter Quell- und Sinksicherheit.

  Die Community Edition-(CE-)Edition unterstützt nur die kennwortdateibasierte Authentifizierung.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): Y für einen sicheren Speicher

type

• Zweck: Gibt den Quell-/Sinktyp an.
• Datentyp: Zeichenfolge
• Erforderlich (J/N): J

useDelegationToken

• Zweck: Gibt an, ob das NoSQL Database Migrator-Tool eine Delegationstokenauthentifizierung verwendet, um eine Verbindung zu den OCI-Services herzustellen. Sie müssen die Delegationstokenauthentifizierung verwenden, um das Utility "Migrator" aus der Cloud Shell auszuführen. Das Delegationstoken wird automatisch für den Benutzer erstellt, wenn Cloud Shell aufgerufen wird.

  Der Standardwert ist false.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

  Hinweis:

  • Die Authentifizierung mit Delegationstoken wird nur unterstützt, wenn das Tool NoSQL Database Migrator über eine Cloud Shell ausgeführt wird.
  • Die Authentifizierungsparameter credentials, useInstancePrincipal und useDelegationToken schließen sich gegenseitig aus. Geben Sie nur einen dieser Parameter in der Konfigurationsvorlage an.
  • Die Cloud Shell unterstützt die Migration nur zwischen den folgenden Quellen und Senken:

    Typ	Gültige Quelle	Gültige Senke
    Oracle NoSQL Database Cloud Service (nosqldb_cloud)	Y	Y
    Datei (JSON-Datei im Home-Verzeichnis)	Y	Y
    OCI Object Storage (JSON-Datei) (object_storage_oci)	Y	Y
    OCI Object Storage (Parquet-Datei) (object_storage_oci)	N	Y

useInstancePrincipal

• Zweck: Gibt an, ob das NoSQL Database Migrator-Tool die Instanz-Principal-Authentifizierung verwendet, um eine Verbindung zum OCI-Service herzustellen, wie Oracle NoSQL Database Cloud Service, OCI Object Storage usw. Weitere Informationen zur Authentifizierungsmethode des Instanz-Principals finden Sie unter Quell- und Sinksicherheit.

  Der Standardwert ist false.

  Hinweis:

  • Die Authentifizierung mit Instanz-Principals wird nur unterstützt, wenn das Tool NoSQL Database Migrator in einer OCI-Compute-Instanz ausgeführt wird. Beispiel: Das Tool NoSQL Database Migrator, das in einer auf OCI gehosteten VM ausgeführt wird.
  • Die Authentifizierungsparameter credentials, useInstancePrincipal und useDelegationToken schließen sich gegenseitig aus. Geben Sie nur einen dieser Parameter in der Konfigurationsvorlage an.
• Datentyp: boolescher Wert
• Erforderlich (J/N): N

Quellkonfigurationsvorlagen

Erfahren Sie mehr über die Dateiformate der Quellkonfiguration für jede gültige Quelle und den Zweck der einzelnen Konfigurationsparameter.

Informationen zur Konfigurationsdateivorlage finden Sie unter Konfigurationsdatei in Terminologie mit NoSQL-Datenmigrator.

Einzelheiten zu gültigen Sink-Formaten für jede Quelle finden Sie unter Sinkkonfigurationsvorlagen.

Themen

In den folgenden Themen werden die Quellkonfigurationsvorlagen beschrieben, die von Oracle NoSQL Database Migrator zum Kopieren der Daten aus der angegebenen Quelle in eine gültige Senke referenziert werden.

• JSON-Dateiquelle

  Angegebene Datei oder Verzeichnis mit den JSON-Daten.

• JSON-Datei in OCI Object Storage-Bucket

  Angegebene JSON-Datei im OCI Object Storage-Bucket.

• MongoDB - Formatierte JSON-Datei

  Angegebene Datei oder Verzeichnis mit den JSON-Daten im Format MongoDB.

• MongoDB - Formatierte JSON-Datei im OCI Object Storage-Bucket

  Angegebene exportierte JSON-Datei MongoDB, die im OCI Object Storage-Bucket gespeichert ist.

• DynamoDB - Formatierte JSON-Datei in AWS S3 gespeichert

  Angegebene exportierte JSON-Datei DynamoDB, die im AWS S3-Speicher gespeichert ist.

• DynamoDB - Formatierte JSON-Datei

  Angegebene DynamoDB exportierte JSON-Datei aus einem Dateisystem.

• Oracle NoSQL Database

  Angegebene Tabelle in Oracle NoSQL Database.

• Oracle NoSQL Database Cloud Service

  Angegebene Tabelle in Oracle NoSQL Database Cloud Service.

• CSV-Dateiquelle

  Angegebene Datei oder Verzeichnis mit den CSV-Daten.

• CSV-Datei in OCI Object Storage-Bucket

  Angegebene CSV-Datei im OCI Object Storage-Bucket.

JSON-Dateiquelle

Das Konfigurationsdateiformat für die JSON-Datei als Quelle von NoSQL Database Migrator wird unten angezeigt.

Sie können eine JSON-Quelldatei migrieren, indem Sie den Dateipfad oder ein Verzeichnis in der Quellkonfigurationsvorlage angeben.

Eine JSON-Beispielquelldatei lautet wie folgt:

{"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"}}

Quellkonfigurationsvorlage

"source": {
  "type": "file",
  "format": "json",
  "dataPath": "<path/to/JSON/[file|dir]>",
  "schemaInfo": {
    "schemaPath": "<path/to/schema/file>"
  }
},

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "file"

• Format

  Verwenden Sie "format" : "json"

Eindeutige Konfigurationsparameter

• dataPath
• schemaInfo
• schemaInfo.schemaPath

dataPath

• Zweck: Gibt den absoluten Pfad zu einer Datei oder einem Verzeichnis mit den JSON-Daten für die Migration an.

  Sie müssen sicherstellen, dass diese Daten mit dem Tabellenschema NoSQL übereinstimmen, das auf der Sink definiert ist. Wenn Sie ein Verzeichnis angeben, identifiziert der NoSQL Database Migrator alle Dateien mit der Erweiterung .json in diesem Verzeichnis für die Migration. Unterordner werden nicht unterstützt.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  • Angeben einer JSON-Datei

    "dataPath" : "/home/user/sample.json"

  • Angeben eines Verzeichnisses

    "dataPath" : "/home/user"

schemaInfo

• Zweck: Gibt das Schema der zu migrierenden Quelldaten an. Dieses Schema wird an die NoSQL-Sink übergeben.

• Datentyp: Objekt
• Erforderlich (J/N): N

schemaInfo.schemaPath

• Zweck: Gibt den absoluten Pfad zur Schemadefinitionsdatei an, die DDL-Anweisungen für die zu migrierende Tabelle NoSQL enthält.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  "schemaInfo": {
    "schemaPath": "<path to the schema file>"
  }

JSON-Datei in OCI Object Storage-Bucket

Das Konfigurationsdateiformat für die JSON-Datei im OCI Object Storage-Bucket als Quelle des NoSQL Database Migrator wird unten angezeigt.

Sie können eine JSON-Datei im OCI Object Storage-Bucket migrieren, indem Sie den Namen des Buckets in der Quellkonfigurationsvorlage angeben.

Eine JSON-Beispielquelldatei im OCI Object Storage-Bucket lautet wie folgt:

{"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"}}

Hinweis:

Die gültigen Sink-Typen für den OCI Object Storage-Quelltyp sind nosqldb und nosqldb_cloud.

Quellkonfigurationsvorlage

"source" : {
  "type" : "object_storage_oci",
  "format" : "json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "schemaInfo" : {
     "schemaObject" : "<object name>"
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>
}

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "object_storage_oci"

• Format

  Verwenden Sie "format" : "json"

• endpoint
  Beispiel:

  • Regions-ID: "endpoint" : "us-ashburn-1"

  • URL-Format: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• Namespace

  Beispiel: "namespace" : "my-namespace"

• bucket

  Beispiel: "bucket" : "my-bucket"

• Präfix
  Beispiel:

  1. "prefix" : "my_table/Data/000000.json" (migriert nur 000000.json)
  2. "prefix" : "my_table/Data" (migriert alle Objekte mit dem Präfix my_table/Data)
• Zugangsdaten
  Beispiel:

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Beispiel:

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Beispiel: "useInstancePrincipal" : true

• useDelegationToken

  Beispiel: "useDelegationToken" : true

  Hinweis:

  Die Authentifizierung mit Delegationstoken wird nur unterstützt, wenn der NoSQL-Datenbankmigrator über eine Cloud Shell ausgeführt wird.

Eindeutige Konfigurationsparameter

• schemaInfo
• schemaInfo.schemaObject

schemaInfo

• Zweck: Gibt das Schema der zu migrierenden Quelldaten an. Dieses Schema wird an die NoSQL-Sink übergeben.

• Datentyp: Objekt
• Erforderlich (J/N): N

schemaInfo.schemaObject

• Zweck: Gibt den Namen des Objekts im Bucket an, in dem NoSQL-Tabellenschemadefinitionen für die zu migrierenden Daten gespeichert werden.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  "schemaInfo": {
    "schemaObject": "mytable/Schema/schema.ddl"
  },

MongoDB - Formatierte JSON-Datei

Das Konfigurationsdateiformat für die JSON-Datei im Format MongoDB als Quelle von NoSQL Database Migrator wird unten angezeigt.

Sie können exportierte JSON-Daten von MongoDB migrieren, indem Sie die Datei oder das Verzeichnis in der Quellkonfigurationsvorlage angeben.

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.

Eine JSON-Beispieldatei im MongoDB-Format für den Relaxed-Modus 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"}]}

Quellkonfigurationsvorlage

"source": {
  "type": "file",
  "format": "mongodb_json",
  "dataPath": "</path/to/json/[file|dir]>",
  "schemaInfo": {
    "schemaPath": "</path/to/schema/file>"
  }
}

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "file"

• Format

  Verwenden Sie "format" : "mongodb_json"

Eindeutige Konfigurationsparameter

• dataPath
• schemaInfo
• schemaInfo.schemaPath

dataPath

• Zweck: Gibt den absoluten Pfad zu einer Datei oder einem Verzeichnis mit den exportierten JSON-Daten MongoDB für die Migration an.

  Sie können die JSON-Datei im Format MongoDB angeben, die mit dem Mongoexport-Tool generiert wird.

  Wenn Sie ein Verzeichnis angeben, identifiziert der NoSQL Database Migrator alle Dateien mit der Erweiterung .json in diesem Verzeichnis für die Migration. Unterordner werden nicht unterstützt. Sie müssen sicherstellen, dass diese Daten mit dem Tabellenschema NoSQL übereinstimmen, das auf der Sink definiert ist.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  • JSON-Datei im Format MongoDB angeben

    "dataPath" : "/home/user/sample.json"

  • Angeben eines Verzeichnisses

    "dataPath" : "/home/user"

schemaInfo

• Zweck: Gibt das Schema der zu migrierenden Quelldaten an. Dieses Schema wird an die NoSQL-Sink übergeben.

• Datentyp: Objekt
• Erforderlich (J/N): N

schemaInfo.schemaPath

• Zweck: Gibt den absoluten Pfad zur Schemadefinitionsdatei an, die DDL-Anweisungen für die zu migrierende Tabelle NoSQL enthält.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  "schemaInfo" : {
    "schemaPath" : "/home/user/mytable/Schema/schema.ddl"
  }

MongoDB - Formatierte JSON-Datei im OCI Object Storage-Bucket

Das Konfigurationsdateiformat für die MongoDB-formatierte JSON-Datei im OCI Object Storage-Bucket als Quelle von NoSQL Database Migrator wird unten angezeigt.

Sie können die exportierten JSON-Daten MongoDB im OCI Object Storage-Bucket migrieren, indem Sie den Namen des Buckets in der Quellkonfigurationsvorlage angeben.

Extrahieren Sie die Daten mit dem Utility mongoexport aus MongoDB, und laden Sie sie in den OCI Object Storage-Bucket hoch. Weitere Informationen finden Sie unter mongoexport. MongoDB unterstützt zwei Arten von Erweiterungen des JSON-Format für Dateien, Kanonischer Modus und Relaxierter Modus. Beide Formate werden im OCI Object Storage-Bucket unterstützt.

Eine JSON-Datei im MongoDB-Beispielformat für den Relaxed-Modus 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"}]}

Hinweis:

Die gültigen Sink-Typen für den OCI Object Storage-Quelltyp sind nosqldb und nosqldb_cloud.

Quellkonfigurationsvorlage

"source" : {
  "type" : "object_storage_oci",
  "format" : "mongodb_json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "schemaInfo" : {
     "schemaObject" : "<object name>"
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>
}

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "object_storage_oci"

• Format

  Verwenden Sie "format" : "mongodb_json"

• endpoint
  Beispiel:

  • Regions-ID: "endpoint" : "us-ashburn-1"

  • URL-Format: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• Namespace

  Beispiel: "namespace" : "my-namespace"

• bucket

  Beispiel: "bucket" : "my-bucket"

• Präfix
  Beispiel:

  1. "prefix" : "mongo_export/Data/table.json" (migriert nur table.json)
  2. "prefix" : "mongo_export/Data" (migriert alle Objekte mit dem Präfix mongo_export/Data)

  Hinweis:

  Wenn Sie keinen Wert angeben, werden alle im Bucket vorhandenen Objekte migriert.
• Zugangsdaten
  Beispiel:

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Beispiel:

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Beispiel: "useInstancePrincipal" : true

Eindeutige Konfigurationsparameter

• schemaInfo
• schemaInfo.schemaObject

schemaInfo

• Zweck: Gibt das Schema der zu migrierenden Quelldaten an. Dieses Schema wird an die NoSQL-Sink übergeben.

• Datentyp: Objekt
• Erforderlich (J/N): N

schemaInfo.schemaObject

• Zweck: Gibt den Namen des Objekts im Bucket an, in dem NoSQL-Tabellenschemadefinitionen für die zu migrierenden Daten gespeichert werden.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  "schemaInfo": {
    "schemaObject": "mytable/Schema/schema.ddl"
  }

DynamoDB - Formatierte JSON-Datei in AWS S3 gespeichert

Das Konfigurationsdateiformat für die DynamoDB-formatierte JSON-Datei in AWS S3 als Quelle von NoSQL Database Migrator wird unten angezeigt.

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 müssen die Tabelle DynamoDB in den AWS S3-Speicher exportieren, wie unter Exportieren von Tabellendaten von DynamoDB in Amazon S3 angegeben.

Die gültigen Sink-Typen für DynamoDB-formatierte JSON, die in AWS S3 gespeichert sind, sind nosqldb und nosqldb_cloud.

Quellkonfigurationsvorlage

"source" : {
  "type" : "aws_s3",
  "format" : "dynamodb_json",
  "s3URL" : "<S3 object url>",
  "credentials" : "</path/to/aws/credentials/file>",
  "credentialsProfile" : <"profile name in aws credentials file">
}

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "aws_s3"

• Format

  Verwenden Sie "format" : "dynamodb_json"

  Hinweis:

  Wenn der Wert des Parameters type aws_s3 lautet, muss das Format dynamodb_json lauten.

Eindeutige Konfigurationsparameter

• s3URL
• Zugangsdaten
• credentialsProfile

s3URL

• Zweck: Gibt die URL einer exportierten DynamoDB-Tabelle an, die in AWS S3 gespeichert ist. Sie können diese URL über die AWS-Konsole S3 abrufen. Das gültige URL-Format ist https://<bucket-name>.<s3_endpoint>/<prefix>. Der NoSQL-Datenbankmigrator sucht beim Import nach json.gz-Dateien im Präfix.

  Hinweis:

  Sie müssen die Tabelle DynamoDB wie unter Exportieren von Tabellendaten der Tabelle DynamoDB in Amazon S3 angegeben exportieren.
• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel: https://my-bucket.s3.ap-south-1.amazonaws.com/AWSDynamoDB/01649660790057-14f642be

credentials

• Zweck: Gibt den absoluten Pfad zu einer Datei mit den AWS-Zugangsdaten an. Wenn keine Angabe gemacht wird, wird standardmäßig $HOME/.aws/credentials verwendet. Weitere Informationen zur Zugangsdatendatei finden Sie unter Einstellungen für Konfiguration und Zugangsdatendatei .
• Datentyp: Zeichenfolge
• Erforderlich (J/N): N
• Beispiel:

  "credentials" : "/home/user/.aws/credentials"
  "credentials" : "/home/user/security/credentials

  Hinweis:

  Der NoSQL-Datenbankmigrator protokolliert keine Zugangsdateninformationen. Sie müssen die Zugangsdatendatei ordnungsgemäß vor unbefugtem Zugriff schützen.

credentialsProfile

• Zweck: Name des Profils in der AWS-Anmeldedatei, die für die Verbindung mit AWS S3 verwendet werden soll. Die Zugangsdaten des Benutzeraccounts werden als Profil bezeichnet. Wenn Sie diesen Wert nicht angeben, verwendet NoSQL Database Migrator das Profil default. Weitere Informationen zur Zugangsdatendatei finden Sie unter Einstellungen für Konfiguration und Zugangsdatendatei .
• Datentyp: Zeichenfolge
• Erforderlich (J/N): N
• Beispiel:

  "credentialsProfile" : "default"
  "credentialsProfile" : "test"

DynamoDB - Formatierte JSON-Datei

Das Konfigurationsdateiformat für die JSON-Datei im Format DynamoDB als Quelle von NoSQL Database Migrator wird unten angezeigt.

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"}}}
{"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 müssen die exportierten DynamoDB-Tabellendaten aus dem AWS S3-Speicher in ein lokales gemountetes Dateisystem kopieren.

Die gültigen Sink-Typen für die JSON-Datei DynamoDB sind nosqldb und nosqldb_cloud.

Quellkonfigurationsvorlage

"source" : {
  "type" : "file",
  "format" : "dynamodb_json",
  "dataPath" : "<path/to/[file|dir]/containing/exported/DDB/tabledata>"   
}

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "file"

• Format

  Verwenden Sie "format" : "dynamodb_json"

Eindeutiger Konfigurationsparameter

dataPath

• Zweck: Gibt den absoluten Pfad zu einer Datei oder einem Verzeichnis an, das die exportierten Tabellendaten der Tabelle DynamoDB enthält. Sie müssen exportierte DynamoDB-Tabellendaten aus AWS S3 in ein lokales gemountetes Dateisystem kopieren. Sie müssen sicherstellen, dass diese Daten mit dem Tabellenschema NoSQL übereinstimmen, das auf der Sink definiert ist. Wenn Sie ein Verzeichnis angeben, identifiziert der NoSQL Database Migrator alle Dateien mit der Erweiterung .json.gz in diesem Verzeichnis und dem Unterverzeichnis data.
• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:
  • Datei angeben

    "dataPath" : "/home/user/AWSDynamoDB/01639372501551-bb4dd8c3/data/zclclwucjy6v5mkefvckxzhfvq.json.gz"

  • Angeben eines Verzeichnisses

    "dataPath" : "/home/user/AWSDynamoDB/01639372501551-bb4dd8c3"

Oracle NoSQL Database

Das Konfigurationsdateiformat für Oracle NoSQL Database als Quelle von NoSQL Database Migrator wird unten angezeigt.

Sie können eine Tabelle aus Oracle NoSQL Database migrieren, indem Sie den Tabellennamen in der Quellkonfigurationsvorlage angeben.

Beispiel für eine Oracle NoSQL Database-Tabelle:

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"teacher"}],"age":25,"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],"expenses":null}
{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"chef"}],"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],"expenses":null}
{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"handyman"}],"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],"expenses":null}

Quellkonfigurationsvorlage

"source" : {
  "type": "nosqldb",
  "storeName" : "<store name>",
  "helperHosts" : ["hostname1:port1","hostname2:port2,..."],
  "table" : "<fully qualified table name>", 
  "includeTTL": <true|false>,    
  "security" : "</path/to/store/security/file>",
  "requestTimeoutMs" : 5000
}

Quellparameter

Allgemeiner Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "nosqldb"

• Sicherheit

  Beispiel:

  "security" : "/home/user/client.credentials"

  Beispielinhalt der Sicherheitsdatei für die kennwortdateibasierte Authentifizierung:

  oracle.kv.password.noPrompt=true
  oracle.kv.auth.username=admin
  oracle.kv.auth.pwdfile.file=/home/nosql/login.passwd
  oracle.kv.transport=ssl
  oracle.kv.ssl.trustStore=/home/nosql/client.trust
  oracle.kv.ssl.protocols=TLSv1.2
  oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL)

  Beispielinhalt der Sicherheitsdatei für die Wallet-basierte Authentifizierung:

  oracle.kv.password.noPrompt=true
  oracle.kv.auth.username=admin
  oracle.kv.auth.wallet.dir=/home/nosql/login.wallet
  oracle.kv.transport=ssl
  oracle.kv.ssl.trustStore=/home/nosql/client.trust
  oracle.kv.ssl.protocols=TLSv1.2
  oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL)

• requestTimeoutMs

  Beispiel: "requestTimeoutMs" : 5000

Eindeutige Konfigurationsparameter

• storeName
• helperHosts
• Tabelle
• includeTTL

storeName

• Zweck: Der Name des Oracle NoSQL Database-Speichers.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel: "storeName" : "kvstore"

helperHosts

• Zweck: Eine Liste der Host- und Registry-Portpaare im Format hostname:port. Trennen Sie jedes Element in der Liste durch ein Komma. Sie müssen mindestens einen Helper-Host angeben.

• Datentyp: Array von Zeichenfolgen
• Erforderlich (J/N): J
• Beispiel: "helperHosts" : ["localhost:5000","localhost:6000"]

Tabelle

• Zweck: Vollqualifizierter Tabellenname für die Migration der Daten.

  Format: [namespace_name:]<table_name>

  Wenn sich die Tabelle im Namespace DEFAULT befindet, können Sie namespace_name weglassen. Die Tabelle muss in der Filiale vorhanden sein.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  • Mit dem DEFAULT-Namespace "table" :"mytable"

  • Mit einem Nicht-Standard-Namespace "table" : "mynamespace:mytable"

  • So geben Sie eine untergeordnete Tabelle an: "table" : "mytable.child"

includeTTL

• Zweck: Gibt an, ob beim Exportieren von Oracle NoSQL Database-Tabellen TTL-Metadaten für Tabellenzeilen eingeschlossen werden sollen. Bei 'Wahr' werden die TTL-Daten für Zeilen auch in die von der Quelle angegebenen Daten aufgenommen. TTL ist im JSON-Objekt _metadata vorhanden, das mit jeder Zeile verknüpft ist. Die Ablaufzeit für jede Zeile wird als Anzahl der Millisekunden seit der UNIX-Epoche exportiert (1. Januar 1970).

  Wenn Sie diesen Parameter nicht angeben, wird er standardmäßig auf false gesetzt.

  Nur die Zeilen mit einem positiven Ablaufwert für TTL werden als Teil der exportierten Zeilen aufgenommen. Wenn eine Zeile nicht abläuft, d.h. TTL=0, werden ihre TTL-Metadaten nicht explizit eingeschlossen. Beispiel: Wenn ROW1 um 2021-10-19 00:00:00 abläuft und ROW2 nicht abläuft, sehen die exportierten Daten wie folgt aus:

  //ROW1
  {
    "id" : 1,
    "name" : "abc",
    "_metadata" : {
      "expiration" : 1634601600000
    }
  }
  
  //ROW2
  {
    "id" : 2,
    "name" : "xyz"
  }

• Datentyp: boolescher Wert
• Erforderlich (J/N): N
• Beispiel: "includeTTL" : true

Oracle NoSQL Database Cloud Service

Das Konfigurationsdateiformat für Oracle NoSQL Database Cloud Service als Quelle von NoSQL Database Migrator wird unten angezeigt.

Sie können eine Tabelle aus Oracle NoSQL Database Cloud Service migrieren, indem Sie den Namen oder die OCID des Compartments angeben, in dem sich die Tabelle in der Quellkonfigurationsvorlage befindet.

Oracle NoSQL Database Cloud Service-Beispieltabelle:

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"teacher"}],"age":25,"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],"expenses":null}
{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"chef"}],"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],"expenses":null}
{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"handyman"}],"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],"expenses":null}

Quellkonfigurationsvorlage

"source" : {
  "type" : "nosqldb_cloud",
  "endpoint" : "<Oracle NoSQL Cloud Service endpoint URL or region ID>",
  "table" : "<table name>",
  "compartment" : "<OCI compartment name or id>",
  "credentials" : "<path/to/oci/credential/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "readUnitsPercent" : <table readunits percent>,
  "includeTTL": <true|false>,
  "requestTimeoutMs" : <timeout in milli seconds>
}

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "nosqldb_cloud"

• endpoint
  Beispiel:

  • Regions-ID: "endpoint" : "us-ashburn-1"

  • URL-Format: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• Zugangsdaten
  Beispiel:

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Beispiel:

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Beispiel: "useInstancePrincipal" : true

• useDelegationToken

  Beispiel: "useDelegationToken" : true

  Hinweis:

  Die Authentifizierung mit Delegationstoken wird nur unterstützt, wenn der NoSQL-Datenbankmigrator über eine Cloud Shell ausgeführt wird.
• requestTimeoutMs

  Beispiel: "requestTimeoutMs" : 5000

Eindeutige Konfigurationsparameter

• Tabelle
• Compartment
• readUnitsPercent
• includeTTL

Tabelle

• Zweck: Name der Tabelle, aus der die Daten migriert werden sollen.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:
  • So geben Sie eine Tabelle an: "table" : "myTable"
  • So geben Sie eine untergeordnete Tabelle an: "table" : "mytable.child"

Compartment

• Zweck: Gibt den Namen oder die OCID des Compartments an, in dem sich die Tabelle befindet.

  Wenn Sie keinen Wert angeben, wird standardmäßig das root-Compartment verwendet.

  Sie finden die OCID Ihres Compartments im Compartment Explorer-Fenster unter "Governance" in der OCI Cloud-Konsole.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J, wenn sich die Tabelle nicht im Root Compartment des Mandanten befindet ODER wenn der Parameter useInstancePrincipal auf "true" gesetzt ist.

  Hinweis:

  Wenn der Parameter useInstancePrincipal auf "true" gesetzt ist, muss das Compartment die Compartment-OCID und nicht den Namen angeben.
• Beispiel:

  • Compartment Name

    "compartment" : "mycompartment"

  • Compartment-Name mit übergeordnetem Compartment qualifiziert

    "compartment" : "parent.childcompartment"

  • Kein Wert angegeben. Wird standardmäßig auf das Root Compartment gesetzt.

    "compartment": ""

  • Compartment-OCID

    "compartment" : "ocid1.tenancy.oc1...4ksd"

readUnitsPercent

• Zweck: Prozentsatz der Tabellenleseeinheiten, die bei der Migration der Tabelle NoSQL verwendet werden sollen.

  Der Standardwert ist 90. Der gültige Bereich ist eine Ganzzahl zwischen 1 und 100. Die für die Migration von Daten erforderliche Zeit ist direkt proportional zu diesem Attribut. Es ist besser, den Lesedurchsatz der Tabelle für die Migrationsaktivität zu erhöhen. Sie können den Lesedurchsatz nach Abschluss des Migrationsprozesses reduzieren.

  Informationen zu den täglichen Limits für Durchsatzänderungen finden Sie unter Cloud-Limits im Oracle NoSQL Database Cloud Service-Dokument.

  Informationen zur Verwendung dieses Attributs zur Verbesserung der Datenmigrationsgeschwindigkeit finden Sie unter Fehlerbehebung bei Oracle NoSQL Database-Migrator.

• Datentyp: Ganzzahl
• Erforderlich (J/N): N
• Beispiel: "readUnitsPercent" : 90

includeTTL

• Zweck: Gibt an, ob beim Exportieren von Oracle NoSQL Database Cloud Service-Tabellen TTL-Metadaten für Tabellenzeilen eingeschlossen werden sollen. Bei 'Wahr' werden die TTL-Daten für Zeilen auch in die von der Quelle angegebenen Daten aufgenommen. TTL ist im JSON-Objekt _metadata vorhanden, das mit jeder Zeile verknüpft ist. Die Ablaufzeit für jede Zeile wird als Anzahl der Millisekunden seit der UNIX-Epoche exportiert (1. Januar 1970).

  Wenn Sie diesen Parameter nicht angeben, wird er standardmäßig auf false gesetzt.

  Nur die Zeilen mit einem positiven Ablaufwert für TTL werden als Teil der exportierten Zeilen aufgenommen. Wenn eine Zeile nicht abläuft, d.h. TTL=0, werden ihre TTL-Metadaten nicht explizit eingeschlossen. Beispiel: Wenn ROW1 um 2021-10-19 00:00:00 abläuft und ROW2 nicht abläuft, sehen die exportierten Daten wie folgt aus:

  //ROW1
  {
    "id" : 1,
    "name" : "abc",
    "_metadata" : {
      "expiration" : 1634601600000
    }
  }
  
  //ROW2
  {
    "id" : 2,
    "name" : "xyz"
  }

• Datentyp: boolescher Wert
• Erforderlich (J/N): N
• Beispiel: "includeTTL" : true

CSV-Dateiquelle

Das Konfigurationsdateiformat für die CSV-Datei als Quelle von NoSQL Database Migrator wird unten angezeigt. Die CSV-Datei muss dem Format RFC4180 entsprechen.

Sie können eine CSV-Datei oder ein Verzeichnis mit den CSV-Daten migrieren, indem Sie den Dateinamen oder das Verzeichnis in der Quellkonfigurationsvorlage angeben.

Eine CSV-Beispieldatei lautet wie folgt:

1,"Computer Science","San Francisco","2500"
2,"Bio-Technology","Los Angeles","1200"
3,"Journalism","Las Vegas","1500"
4,"Telecommunication","San Francisco","2500"

Quellkonfigurationsvorlage

"source" : {
  "type" : "file",
  "format" : "csv",
  "dataPath": "</path/to/a/csv/[file|dir]>",
  "hasHeader" : <true | false>,
  "columns" : ["column1", "column2", ....],
  "csvOptions": {
    "encoding": "<character set encoding>",
    "trim": "<true | false>"
 }
}

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "file"

• Format

  Verwenden Sie "format" : "csv"

Eindeutige Konfigurationsparameter

• dataPath

• hasHeader

• Spalten

• csvOptions

• csvOptions.encoding

• csvOptions.trim

Datenpfad

• Zweck: Gibt den absoluten Pfad zu einer Datei oder einem Verzeichnis mit den CSV-Daten für die Migration an. Wenn Sie ein Verzeichnis angeben, importiert NoSQL Database Migrator alle Dateien mit der Erweiterung .csv oder .CSV in dieses Verzeichnis. Alle CSV-Dateien werden in eine einzelne Tabelle kopiert, jedoch nicht in einer bestimmten Reihenfolge.

  CSV-Dateien müssen dem Standard RFC4180 entsprechen. Sie müssen sicherstellen, dass die Daten in jeder CSV-Datei mit dem Tabellenschema NoSQL Database übereinstimmen, das in der Sink-Tabelle definiert ist. Unterordner werden nicht unterstützt.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  • Angeben einer CSV-Datei

    "dataPath" : "/home/user/sample.csv"

  • Angeben eines Verzeichnisses

    "dataPath" : "/home/user"

Hinweis:

Die CSV-Dateien dürfen nur skalare Werte enthalten. Das Importieren von CSV-Dateien mit komplexen Typen wie MAP, RECORD, ARRAY und JSON wird nicht unterstützt. Das Tool NoSQL Database Migrator prüft nicht auf die Richtigkeit der Daten in der eingegebenen CSV-Datei. Das Tool NoSQL Database Migrator unterstützt den Import von CSV-Daten, die dem Format RFC4180 entsprechen. CSV-Dateien, die Daten enthalten, die nicht dem Standard RFC4180 entsprechen, werden möglicherweise nicht korrekt kopiert oder führen zu einem Fehler. Wenn die Eingabedaten beschädigt sind, parst das Tool NoSQL Database Migrator die CSV-Datensätze nicht. Wenn während der Migration Fehler auftreten, protokolliert das Tool NoSQL Database Migrator die Informationen zu den nicht erfolgreichen Eingabedatensätzen für Debugging- und Informationszwecke. Weitere Informationen finden Sie unter Logging-Migratorfortschritt in Oracle NoSQL-Datenmigrator verwenden.

hasHeader

• Zweck: Gibt an, ob die CSV-Datei einen Header enthält. Wenn dies auf true gesetzt ist, wird die erste Zeile ignoriert. Wenn sie auf false gesetzt ist, wird die erste Zeile als CSV-Datensatz betrachtet. Der Standardwert ist false.

• Datentyp: Boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "hasHeader" : "false"

Spalten

• Zweck: Gibt die Liste der Tabellenspaltennamen der NoSQL-Datenbank an. Die Reihenfolge der Spaltennamen gibt die Zuordnung der Felder der CSV-Datei zu den entsprechenden Spalten der NoSQL-Datenbank an. Wenn die Reihenfolge der Spalten der CSV-Eingabedatei nicht mit den vorhandenen oder neu erstellten Tabellenspalten der Datenbank NoSQL übereinstimmt, können Sie die Reihenfolge mit diesem Parameter zuordnen. Außerdem können Sie beim Import in eine Tabelle mit einer Identitätsspalte den Identitätsspaltennamen im Parameter columns überspringen.

  Hinweis:

  • Wenn die Tabelle NoSQL Database zusätzliche Spalten enthält, die in der CSV-Datei nicht verfügbar sind, werden die Werte der fehlenden Spalten mit dem Standardwert aktualisiert, der in der Tabelle NoSQL Database definiert ist. Wenn kein Standardwert angegeben wird, wird während der Migration ein Nullwert eingefügt. Weitere Informationen zu Standardwerten finden Sie im Abschnitt Datentypdefinitionen in der SQL-Referenzdokumentation.
  • Wenn die CSV-Datei zusätzliche Spalten enthält, die nicht in der Tabelle NoSQL-Datenbank definiert sind, werden die zusätzlichen Spalteninformationen ignoriert.
  • Wenn ein Wert im CSV-Datensatz leer ist, wird er auf den Standardwert der entsprechenden Spalten in der Tabelle NoSQL Database gesetzt. Wenn kein Standardwert angegeben wird, wird während der Migration ein Nullwert eingefügt.
• Datentyp: Zeichenfolgenarray
• Erforderlich (J/N): N

• Beispiel: "columns" : ["table_column_1", "table_column_2"]

csvOptions

• Zweck: Gibt die Formatierungsoptionen für eine CSV-Datei an. Geben Sie das Zeichensatzcodierungsformat der CSV-Datei an, und wählen Sie, ob die Leerzeichen abgeschnitten werden sollen.

• Datentyp: Objekt
• Erforderlich (J/N): N

csvOptions.encoding

• Zweck: Gibt den Zeichensatz zur Decodierung der CSV-Datei an. Der Standardwert ist UTF-8. Die unterstützten Zeichensätze sind US-ASCII, ISO-8859-1, UTF-8, und UTF-16.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

• Beispiel: "encoding" : "UTF-8"

csvOptions.trim

• Zweck: Gibt an, ob die vor- und nachgestellten Leerzeichen eines CSV-Feldwertes abgeschnitten werden müssen. Der Standardwert ist false.

• Datentyp: Boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "trim" : "true"

CSV-Datei in OCI Object Storage-Bucket

Das Konfigurationsdateiformat für die CSV-Datei im OCI Object Storage-Bucket als Quelle von NoSQL Database Migrator wird unten angezeigt. Die CSV-Datei muss dem Format RFC4180 entsprechen.

Sie können eine CSV-Datei im OCI Object Storage-Bucket migrieren, indem Sie den Namen des Buckets in der Quellkonfigurationsvorlage angeben.

Eine Beispiel-CSV-Datei im OCI Object Storage-Bucket lautet wie folgt:

1,"Computer Science","San Francisco","2500"
2,"Bio-Technology","Los Angeles","1200"
3,"Journalism","Las Vegas","1500"
4,"Telecommunication","San Francisco","2500"

Hinweis:

Die gültigen Sink-Typen für den OCI Object Storage-Quelltyp sind nosqldb und nosqldb_cloud.

Quellkonfigurationsvorlage

"source" : {
  "type" : "object_storage_oci",
  "format" : "csv",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
   "hasHeader" : <true | false>,
   "columns" : ["column1", "column2", ....],
   "csvOptions" : {         
     "encoding" : "<character set encoding>",
     "trim" : <true | false>
   }
 }

Quellparameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "object_storage_oci"

• Format

  Verwenden Sie "format" : "csv"

• endpoint
  Beispiel:

  • Regions-ID: "endpoint" : "us-ashburn-1"

  • URL-Format: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• Namespace

  Beispiel: "namespace" : "my-namespace"

• bucket

  Beispiel: "bucket" : "my-bucket"

  Hinweis:

  • Der NoSQL Database Migrator importiert alle Dateien mit der Erweiterung .csv oder .CSV objektweise und kopiert sie in derselben Reihenfolge in eine einzelne Tabelle.

  • Die CSV-Dateien dürfen nur skalare Werte enthalten. Das Importieren von CSV-Dateien mit komplexen Typen wie MAP, RECORD, ARRAY und JSON wird nicht unterstützt. Das Tool NoSQL Database Migrator prüft nicht auf die Richtigkeit der Daten in der eingegebenen CSV-Datei. Das Tool NoSQL Database Migrator unterstützt den Import von CSV-Daten, die dem Format RFC4180 entsprechen. CSV-Dateien, die Daten enthalten, die nicht dem Standard RFC4180 entsprechen, werden möglicherweise nicht korrekt kopiert oder führen zu einem Fehler. Wenn die Eingabedaten beschädigt sind, parst das Tool NoSQL Database Migrator die CSV-Datensätze nicht. Wenn während der Migration Fehler auftreten, protokolliert das Tool NoSQL Database Migrator die Informationen zu den nicht erfolgreichen Eingabedatensätzen für Debugging- und Informationszwecke. Weitere Informationen finden Sie unter Logging-Migratorfortschritt in Oracle NoSQL-Datenmigrator verwenden.

• Präfix
  Beispiel:

  1. "prefix" : "my_table/Data/000000.csv" (migriert nur 000000.csv)
  2. "prefix" : "my_table/Data" (migriert alle Objekte mit dem Präfix my_table/Data)
• Zugangsdaten
  Beispiel:

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Beispiel:

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Beispiel: "useInstancePrincipal" : true

Eindeutige Konfigurationsparameter

• hasHeader
• Spalten
• csvOptions
• csvOptions.encoding
• csvOptions.trim

hasHeader

• Zweck: Gibt an, ob die CSV-Datei einen Header enthält. Wenn dies auf true gesetzt ist, wird die erste Zeile ignoriert. Wenn sie auf false gesetzt ist, wird die erste Zeile als CSV-Datensatz betrachtet. Der Standardwert ist false.

• Datentyp: Boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "hasHeader" : "false"

Spalten

• Zweck: Gibt die Liste der Tabellenspaltennamen der NoSQL-Datenbank an. Die Reihenfolge der Spaltennamen gibt die Zuordnung der Felder der CSV-Datei zu den entsprechenden Spalten der NoSQL-Datenbank an. Wenn die Reihenfolge der Spalten der CSV-Eingabedatei nicht mit den vorhandenen oder neu erstellten Tabellenspalten der Datenbank NoSQL übereinstimmt, können Sie die Reihenfolge mit diesem Parameter zuordnen. Außerdem können Sie beim Import in eine Tabelle mit einer Identitätsspalte den Identitätsspaltennamen im Parameter columns überspringen.

  Hinweis:

  • Wenn die Tabelle NoSQL Database zusätzliche Spalten enthält, die in der CSV-Datei nicht verfügbar sind, werden die Werte der fehlenden Spalten mit dem Standardwert aktualisiert, der in der Tabelle NoSQL Database definiert ist. Wenn kein Standardwert angegeben wird, wird während der Migration ein Nullwert eingefügt. Weitere Informationen zu Standardwerten finden Sie im Abschnitt Datentypdefinitionen in der SQL-Referenzdokumentation.
  • Wenn die CSV-Datei zusätzliche Spalten enthält, die nicht in der Tabelle NoSQL-Datenbank definiert sind, werden die zusätzlichen Spalteninformationen ignoriert.
  • Wenn ein Wert im CSV-Datensatz leer ist, wird er auf den Standardwert der entsprechenden Spalten in der Tabelle NoSQL Database gesetzt. Wenn kein Standardwert angegeben wird, wird während der Migration ein Nullwert eingefügt.
• Datentyp: Zeichenfolgenarray
• Erforderlich (J/N): N

• Beispiel: "columns" : ["table_column_1", "table_column_2"]

csvOptions

• Zweck: Gibt die Formatierungsoptionen für eine CSV-Datei an. Geben Sie das Zeichensatzcodierungsformat der CSV-Datei an, und wählen Sie, ob die Leerzeichen abgeschnitten werden sollen.

• Datentyp: Objekt
• Erforderlich (J/N): N

csvOptions.encoding

• Zweck: Gibt den Zeichensatz zur Decodierung der CSV-Datei an. Der Standardwert ist UTF-8. Die unterstützten Zeichensätze sind US-ASCII, ISO-8859-1, UTF-8, und UTF-16.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

• Beispiel: "encoding" : "UTF-8"

csvOptions.trim

• Zweck: Gibt an, ob die vor- und nachgestellten Leerzeichen eines CSV-Feldwertes abgeschnitten werden müssen. Der Standardwert ist false.

• Datentyp: Boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "trim" : "true"

Sink Konfigurationsvorlagen

Erfahren Sie mehr über die Dateiformate der Sink-Konfiguration für jede gültige Sink und den Zweck jedes Konfigurationsparameters.

Informationen zur Konfigurationsdateivorlage finden Sie unter Konfigurationsdatei in Terminologie mit NoSQL-Datenmigrator.

Weitere Informationen zu gültigen Quellformaten für jede Senken finden Sie unter Quellkonfigurationsvorlagen.

Themen

In den folgenden Themen werden die Sink-Konfigurationsvorlagen beschrieben, die von Oracle NoSQL Database Migrator zum Kopieren der Daten aus einer gültigen Quelle in die angegebene Sink referenziert werden.

• JSON-Dateisink

  Angegebene JSON-Datei.

• Parquet-Datei

  Parquet-Datei im angegebenen Verzeichnis.

• JSON-Datei in OCI Object Storage-Bucket

  JSON-Datei im angegebenen OCI Object Storage-Bucket.

• Parquet-Datei in OCI Object Storage-Bucket

  Parquet-Datei im angegebenen OCI Object Storage-Bucket.

• Oracle NoSQL Database

  Angegebene Tabelle in Oracle NoSQL Database.

• Oracle NoSQL Database Cloud Service

  Angegebene Tabelle in Oracle NoSQL Database Cloud Service.

JSON-Dateisink

Das Konfigurationsdateiformat für die JSON-Datei als Sink von NoSQL Database Migrator wird unten angezeigt.

Sinkkonfigurationsvorlage

"sink" : {
  "type" : "file",
  "format" : "json",
  "dataPath": "</path/to/a/file>",
  "schemaPath" : "<path/to/a/file>",
  "pretty" : <true|false>,
  "useMultiFiles" : <true|false>,
  "chunkSize" : <size in MB>
}

Sink-Parameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "file"

• Format

  Verwenden Sie "format" : "json"

• chunkSize

  Beispiel: "chunkSize" : 40

  Hinweis:

  Dieser Parameter ist NUR anwendbar, wenn der Parameter useMultiFiles auf "true" gesetzt ist.

Eindeutige Konfigurationsparameter

• dataPath
• schemaPath
• hübsch
• useMultiFiles

dataPath

• Zweck: Gibt den absoluten Pfad zu einer Datei an, in die die Quelldaten im JSON-Format kopiert werden.

  Wenn die Datei nicht im angegebenen Datenpfad vorhanden ist, wird sie vom NoSQL Database Migrator erstellt. Wenn er vorhanden ist, überschreibt der NoSQL-Datenbankmigrator seinen Inhalt mit den Quelldaten.

  Sie müssen sicherstellen, dass das übergeordnete Verzeichnis im Datenpfad für die angegebene Datei gültig ist.

  Hinweis:

  Wenn der Parameter useMultiFiles auf "true" gesetzt ist, geben Sie den Pfad zu einem Verzeichnis an. Andernfalls geben Sie den Pfad zur Datei an.
• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  • Wenn der Parameter useMultiFiles auf "true" gesetzt ist

    "dataPath" :"/home/user/data"

  • Wenn der Parameter useMultiFiles nicht angegeben oder auf "false" gesetzt ist

    "dataPath" :"/home/user/sample.json"

schemaPath

• Zweck: Gibt den absoluten Pfad zu einer Datei zum Schreiben von Tabellenschemainformationen an, die von der Quelle angegeben werden.

  Wenn dieser Wert nicht definiert ist, werden die Quellschemainformationen nicht in die Sink migriert. Wenn dieser Wert angegeben ist, schreibt das Utility migrator das Schema der Quelltabelle in die hier angegebene Datei.

  Die Schemainformationen werden in dieser Datei als ein DDL-Befehl pro Zeile geschrieben. Wenn die Datei nicht im angegebenen Datenpfad vorhanden ist, erstellt NoSQL Database Migrator sie. Wenn er bereits vorhanden ist, überschreibt NoSQL Database Migrator seinen Inhalt mit den Quelldaten. Sie müssen sicherstellen, dass das übergeordnete Verzeichnis im Datenpfad für die angegebene Datei gültig ist.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

• Beispiel: "schemaPath" : "/home/user/schema_file"

hübsch

• Zweck: Gibt an, ob die JSON-Ausgabe verschönert werden soll, um die Lesbarkeit zu erhöhen.

  Wenn nicht angegeben, wird standardmäßig "false" verwendet.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "pretty" : true

useMultiFiles

• Zweck: Gibt an, ob die Tabellendaten der Tabelle NoSQL bei der Migration von Quelldaten in eine Datei in mehrere Dateien aufgeteilt werden sollen.

  Wenn nicht angegeben, wird standardmäßig "false" verwendet.

  Wenn diese Option auf "true" gesetzt ist, werden bei der Migration von Quelldaten in eine Datei die Tabellendaten NoSQL in mehrere kleinere Dateien aufgeteilt. Beispiel: <chunk>.json, wobei chunk=000000, 000001, 000002 usw. ist.

  dataPath
           |--000000.json
           |--000001.json

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "useMultiFiles" : true

Parquet-Datei

Das Konfigurationsdateiformat für die Parquet-Datei als Sink von NoSQL Database Migrator wird unten angezeigt.

Sinkkonfigurationsvorlage

"sink" : {
  "type" : "file",
  "format" : "parquet",
  "dataPath": "</path/to/a/dir>",
  "chunkSize" : <size in MB>,
  "compression": "<SNAPPY|GZIP|NONE>",
  "parquetOptions": {
    "useLogicalJson": <true|false>,
    "useLogicalEnum": <true|false>,
    "useLogicalUUID": <true|false>,     
    "truncateDoubleSpecials": <true|false>
  }
}

Sink-Parameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "file"

• Format

  Verwenden Sie "format" : "parquet"

• chunkSize

  Beispiel: "chunkSize" : 40

Eindeutige Konfigurationsparameter

• dataPath
• Komprimierung
• parquetOptions
• parquetOptions.useLogicalJson
• parquetOptions.useLogicalEnum
• parquetOptions.useLogicalUUID
• parquetOptions.truncateDoubleSpecials

dataPath

• Zweck: Gibt den Pfad zu einem Verzeichnis zum Speichern der migrierten NoSQL-Tabellendaten an. Stellen Sie sicher, dass das Verzeichnis bereits vorhanden ist und über Lese- und Schreibberechtigungen verfügt.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J

• Beispiel: "dataPath" : "/home/user/migrator/my_table"

Komprimierung

• Zweck: Gibt den Komprimierungstyp an, mit dem die Parquet-Daten komprimiert werden. Gültige Werte sind SNAPPY, GZIP und NONE.

  Wenn keine Angabe gemacht wird, wird standardmäßig SNAPPY verwendet.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

• Beispiel: "compression" : "GZIP"

parquetOptions

• Zweck: Gibt die Optionen zum Auswählen logischer Parquet-Typen für die Spalten NoSQL ENUM, JSON und UUID an.

  Wenn Sie diesen Parameter nicht angeben, schreibt der NoSQL Database Migrator die Daten der ENUM-, JSON- und UUID-Spalten als Zeichenfolge.

• Datentyp: Objekt
• Erforderlich (J/N): N

parquetOptions.useLogicalJson

• Zweck: Gibt an, ob NoSQL-JSON-Spaltendaten als logischer Parquet-JSON-Typ geschrieben werden sollen. Weitere Informationen finden Sie unter Definitionen für logische Parketttypen.

  Wenn nicht angegeben oder auf "false" gesetzt, schreibt NoSQL Database Migrator die JSON-Spaltendaten NoSQL als Zeichenfolge.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "useLogicalJson" : true

parquetOptions.useLogicalEnum

• Zweck: Gibt an, ob NoSQL ENUM-Spaltendaten als logischer Parquet-ENUM-Typ geschrieben werden sollen. Weitere Informationen finden Sie unter Definitionen für logische Parketttypen.

  Wenn nicht angegeben oder auf "false" gesetzt, schreibt NoSQL Database Migrator die NoSQL ENUM-Spaltendaten als Zeichenfolge.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "useLogicalEnum" : true

parquetOptions.useLogicalUUID

• Zweck: Gibt an, ob NoSQL UUID-Spaltendaten als logischer Parquet-UUID-Typ geschrieben werden sollen. Weitere Informationen finden Sie unter Definitionen für logische Parketttypen.

  Wenn nicht angegeben oder auf "false" gesetzt, schreibt NoSQL Database Migrator die UUID-Spaltendaten NoSQL als Zeichenfolge.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "useLogicalUUID" : true

parquetOptions.truncateDoubleSpecials

• Zweck: Gibt an, ob die doppelten Werte +Infinity, -Infinity und NaN abgeschnitten werden sollen.

  Standardmäßig ist sie auf false gesetzt. Wenn auf true gesetzt,

  • Positive_Infinity wird auf Double.MAX_VALUE abgeschnitten.
  • NEGATIVE_INFINITY wird auf -Double.MAX_VALUE gekürzt.
  • NaN wird auf 9.9999999999999990E307 abgeschnitten.
• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "truncateDoubleSpecials" : true

JSON-Datei in OCI Object Storage-Bucket

Das Konfigurationsdateiformat für die JSON-Datei im OCI Object Storage-Bucket als Sink von NoSQL Database Migrator wird unten angezeigt.

Hinweis:

Die gültigen Quelltypen für OCI Object Storage als Sink sind nosqldb und nosqldb_cloud.

Sinkkonfigurationsvorlage

"sink" : {
  "type" : "object_storage_oci",
  "format" : "json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "chunkSize" : <size in MB>,
  "pretty" : <true|false>,
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,  
  "useDelegationToken" : <true|false>
}

Sink-Parameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "object_storage_oci"

• Format

  Verwenden Sie "format" : "json"

• endpoint
  Beispiel:

  • Regions-ID: "endpoint" : "us-ashburn-1"

  • URL-Format: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• Namespace

  Beispiel: "namespace" : "my-namespace"

• bucket

  Beispiel: "bucket" : "my-bucket"

• Präfix

  Das Schema wird in die Datei <prefix>/Schema/schema.ddl migriert, und die Quelldaten werden in die Dateien <prefix>/Data/<chunk>.json migriert, wobei chunk=000000.json, 000001.json usw. gilt.

  Beispiel:

  1. "prefix" : "my_export"
  2. "prefix" : "my_export/2021-04-05/"
• chunkSize

  Beispiel: "chunkSize" : 40

• Zugangsdaten
  Beispiel:

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Beispiel:

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Beispiel: "useInstancePrincipal" : true

• useDelegationToken

  Beispiel: "useDelegationToken" : true

  Hinweis:

  Die Authentifizierung mit Delegationstoken wird nur unterstützt, wenn der NoSQL-Datenbankmigrator über eine Cloud Shell ausgeführt wird.

Eindeutiger Konfigurationsparameter

ziemlich

• Zweck: Gibt an, ob die JSON-Ausgabe verschönert werden soll, um die Lesbarkeit zu erhöhen.

  Wenn nicht angegeben, wird standardmäßig "false" verwendet.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "pretty" : true

Parquet-Datei in OCI Object Storage-Bucket

Das Konfigurationsdateiformat für die Parquet-Datei im OCI Object Storage-Bucket als Sink von NoSQL Database Migrator wird unten angezeigt.

Hinweis:

Die gültigen Quelltypen für den OCI Object Storage-Quelltyp sind nosqldb und nosqldb_cloud.

Sinkkonfigurationsvorlage

"sink" : {
  "type" : "object_storage_oci",
  "format" : "parquet",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "chunkSize" : <size in MB>,
  "compression": "<SNAPPY|GZIP|NONE>",
  "parquetOptions": {
    "useLogicalJson": <true|false>,
    "useLogicalEnum": <true|false>,
    "useLogicalUUID": <true|false>,
    "truncateDoubleSpecials": <true|false>
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>
}

Sink-Parameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "object_storage_oci"

• Format

  Verwenden Sie "format" : "parquet"

• endpoint
  Beispiel:

  • Regions-ID: "endpoint" : "us-ashburn-1"

  • URL-Format: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• Namespace

  Beispiel: "namespace" : "my-namespace"

• bucket

  Beispiel: "bucket" : "my-bucket"

• Präfix

  Quelldaten werden in die <prefix>/Data/<chunk>.parquet-Dateien migriert, wobei chunk=000000.parquet, 000001.parquet usw. gilt.

  Beispiel:

  1. "prefix" : "my_export"
  2. "prefix" : "my_export/2021-04-05/"
• chunkSize

  Beispiel: "chunkSize" : 40

• Zugangsdaten
  Beispiel:

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Beispiel:

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Beispiel: "useInstancePrincipal" : true

• useDelegationToken

  Beispiel: "useDelegationToken" : true

  Hinweis:

  Die Authentifizierung mit Delegationstoken wird nur unterstützt, wenn der NoSQL-Datenbankmigrator über eine Cloud Shell ausgeführt wird.

Eindeutiger Konfigurationsparameter

• Komprimierung
• parquetOptions
• parquetOptions.useLogicalJson
• parquetOptions.useLogicalEnum
• parquetOptions.useLogicalUUID
• parquetOptions.truncateDoubleSpecials

Komprimierung

• Zweck: Gibt den Komprimierungstyp an, mit dem die Parquet-Daten komprimiert werden. Gültige Werte sind SNAPPY, GZIP und NONE.

  Wenn keine Angabe gemacht wird, wird standardmäßig SNAPPY verwendet.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): N

• Beispiel: "compression" : "GZIP"

parquetOptions

• Zweck: Gibt die Optionen zum Auswählen logischer Parquet-Typen für die Spalten NoSQL ENUM, JSON und UUID an.

  Wenn Sie diesen Parameter nicht angeben, schreibt der NoSQL Database Migrator die Daten der ENUM-, JSON- und UUID-Spalten als Zeichenfolge.

• Datentyp: Objekt
• Erforderlich (J/N): N

parquetOptions.useLogicalJson

• Zweck: Gibt an, ob NoSQL-JSON-Spaltendaten als logischer Parquet-JSON-Typ geschrieben werden sollen. Weitere Informationen finden Sie unter Definitionen für logische Parketttypen.

  Wenn nicht angegeben oder auf "false" gesetzt, schreibt NoSQL Database Migrator die JSON-Spaltendaten NoSQL als Zeichenfolge.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "useLogicalJson" : true

parquetOptions.useLogicalEnum

• Zweck: Gibt an, ob NoSQL ENUM-Spaltendaten als logischer Parquet-ENUM-Typ geschrieben werden sollen. Weitere Informationen finden Sie unter Definitionen für logische Parketttypen.

  Wenn nicht angegeben oder auf "false" gesetzt, schreibt NoSQL Database Migrator die NoSQL ENUM-Spaltendaten als Zeichenfolge.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "useLogicalEnum" : true

parquetOptions.useLogicalUUID

• Zweck: Gibt an, ob NoSQL UUID-Spaltendaten als logischer Parquet-UUID-Typ geschrieben werden sollen. Weitere Informationen finden Sie unter Definitionen für logische Parketttypen.

  Wenn nicht angegeben oder auf "false" gesetzt, schreibt NoSQL Database Migrator die UUID-Spaltendaten NoSQL als Zeichenfolge.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "useLogicalUUID" : true

parquetOptions.truncateDoubleSpecials

• Zweck: Gibt an, ob die doppelten Werte +Infinity, -Infinity und NaN abgeschnitten werden sollen.

  Standardmäßig ist sie auf false gesetzt. Wenn auf true gesetzt,

  • Positive_Infinity wird auf Double.MAX_VALUE abgeschnitten.
  • NEGATIVE_INFINITY wird auf -Double.MAX_VALUE gekürzt.
  • NaN wird auf 9.9999999999999990E307 abgeschnitten.
• Datentyp: boolescher Wert
• Erforderlich (J/N): N

• Beispiel: "truncateDoubleSpecials" : true

Oracle NoSQL Database

Das Konfigurationsdateiformat für Oracle NoSQL Database als Sink von NoSQL Database Migrator wird unten angezeigt.

Sinkkonfigurationsvorlage

"sink" : {
  "type": "nosqldb",
  "storeName" : "<store name>",
  "helperHosts" : ["hostname1:port1","hostname2:port2,..."],
  "security" : "</path/to/store/credentials/file>",
  "table" : "<fully qualified table name>",
  "includeTTL": <true|false>,
  "ttlRelativeDate": "<date-to-use in UTC>",
  "schemaInfo" : {
    "schemaPath" : "</path/to/a/schema/file>",
    "defaultSchema" : <true|false>,
    "useSourceSchema" : <true|false>,
    "DDBPartitionKey" : <"name:type">,
    "DDBSortKey" : "<name:type>"
  },
  "overwrite" : <true|false>,
  "requestTimeoutMs" : <timeout in milli seconds>
}

Sink-Parameter

Allgemeiner Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "nosqldb"

• Sicherheit

  Beispiel:

  "security" : "/home/user/client.credentials"

  Beispielinhalt der Sicherheitsdatei für die kennwortdateibasierte Authentifizierung:

  oracle.kv.password.noPrompt=true
  oracle.kv.auth.username=admin
  oracle.kv.auth.pwdfile.file=/home/nosql/login.passwd
  oracle.kv.transport=ssl
  oracle.kv.ssl.trustStore=/home/nosql/client.trust
  oracle.kv.ssl.protocols=TLSv1.2
  oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL)

  Beispielinhalt der Sicherheitsdatei für die Wallet-basierte Authentifizierung:

  oracle.kv.password.noPrompt=true
  oracle.kv.auth.username=admin
  oracle.kv.auth.wallet.dir=/home/nosql/login.wallet
  oracle.kv.transport=ssl
  oracle.kv.ssl.trustStore=/home/nosql/client.trust
  oracle.kv.ssl.protocols=TLSv1.2
  oracle.kv.ssl.hostnameVerifier=dnmatch(CN\=NoSQL)

• requestTimeoutMs

  Beispiel: "requestTimeoutMs" : 5000

Eindeutiger Konfigurationsparameter

• storeName
• helperHosts
• Tabelle
• includeTTL
• ttlRelativeDate
• schemaInfo
• schemaInfo.schemaPath
• schemaInfo.defaultSchema
• schemaInfo.useSourceSchema
• schemaInfo.DDBPartitionKey
• schemaInfo.DDBSortKey
• overwrite

storeName

• Zweck: Der Name des Oracle NoSQL Database-Speichers.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel: "storeName" : "kvstore"

helperHosts

• Zweck: Eine Liste der Host- und Registry-Portpaare im Format hostname:port. Trennen Sie jedes Element in der Liste durch ein Komma. Sie müssen mindestens einen Helper-Host angeben.

• Datentyp: Array von Zeichenfolgen
• Erforderlich (J/N): J
• Beispiel: "helperHosts" : ["localhost:5000","localhost:6000"]

Tabelle

• Zweck: Gibt den Tabellennamen zum Speichern der migrierten Daten an.

  Format: [namespace_name:]<table_name>

  Wenn sich die Tabelle im Namespace DEFAULT befindet, können Sie namespace_name weglassen. Die Tabelle muss während der Migration im Speicher vorhanden sein, und ihr Schema muss mit den Quelldaten übereinstimmen.

  Wenn die Tabelle in der Senke nicht verfügbar ist, können Sie den Parameter schemaInfo verwenden, um den NoSQL Database Migrator anzuweisen, die Tabelle in der Senke zu erstellen.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:

  • Mit dem DEFAULT-Namespace "table" :"mytable"

  • Mit einem Nicht-Standard-Namespace "table" : "mynamespace:mytable"

  • So geben Sie eine untergeordnete Tabelle an: "table" : "mytable.child"

    Hinweis:

    Sie können die untergeordneten Tabellen von einer gültigen Datenquelle in Oracle NoSQL Database migrieren. Der NoSQL-Datenbankmigrator kopiert nur eine einzelne Tabelle in jeder Ausführung. Stellen Sie sicher, dass die übergeordnete Tabelle vor der untergeordneten Tabelle migriert wird.

includeTTL

• Zweck: Gibt an, ob TTL-Metadaten für Tabellenzeilen einbezogen werden sollen, die von der Quelle beim Importieren von Oracle NoSQL Database-Tabellen bereitgestellt werden.

  Wenn Sie diesen Parameter nicht angeben, wird er standardmäßig auf false gesetzt. In diesem Fall enthält der NoSQL Database Migrator keine TTL-Metadaten für Tabellenzeilen, die von der Quelle beim Importieren von Oracle NoSQL Database-Tabellen bereitgestellt werden.

  Wenn diese Option auf "true" gesetzt ist, führt das Tool NoSQL Database Migrator beim Importieren einer Tabellenzeile die folgenden Prüfungen der TTL-Metadaten aus:

  • Wenn Sie eine Zeile ohne _metadata-Definition importieren, setzt das Tool NoSQL Database Migrator die TTL auf 0. Das bedeutet, dass die Zeile nie abläuft.
  • Wenn Sie eine Zeile mit der Definition _metadata importieren, vergleicht das Tool NoSQL Database Migrator den TTL-Wert mit einer Referenzzeit, wenn eine Zeile importiert wird. Wenn die Zeile relativ zur Referenzzeit bereits abgelaufen ist, wird sie übersprungen. Wenn die Zeile nicht abgelaufen ist, wird sie zusammen mit dem TTL-Wert importiert. Standardmäßig ist die Referenzzeit des Importvorgangs die aktuelle Zeit in Millisekunden, die aus System.currentTimeMillis() des Rechners abgerufen wird, auf dem das Datenbankmigrator-Tool NoSQL 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 Formel zur Berechnung der Ablaufzeit eines Datensatzes lautet wie folgt:

    expiration = (TTL value of source row in milliseconds - Reference Time in milliseconds)
    if (expiration <= 0) then it indicates that row has expired.

    Hinweis:

    Da die TTL-Grenzen von Oracle NoSQL in Stunden und Tagen angegeben sind, kann die TTL der importierten Zeile in einigen Fällen auf die nächste Stunde oder den nächsten Tag angepasst werden. Beispiel: Eine Zeile mit dem Ablaufwert 1629709200000 (2021-08-23 09:00:00) und dem Referenzzeitwert 1629707962582 (2021-08-23 08:39:22). Auch wenn die Zeile beim Import dieser Daten relativ zur Referenzzeit nicht abgelaufen ist, lautet die neue TTL für die Zeile 1629712800000 (2021-08-23 10:00:00).
• Datentyp: boolescher Wert
• Erforderlich (J/N): N
• Beispiel: "includeTTL" : true

ttlRelativeDate

• Zweck: Geben Sie ein UTC-Datum im Format JJJJ-MM-TT hh:mm:ss an, mit dem der TTL-Ablauf von Tabellenzeilen beim Import in Oracle NoSQL Database festgelegt wird.

  Wenn eine Tabellenzeile in den Daten, die Sie exportieren, abgelaufen ist, können Sie den Parameter ttlRelativeDate auf ein Datum setzen, das vor der Ablaufzeit der Tabellenzeile in den exportierten Daten liegt.

  Wenn Sie diesen Parameter nicht angeben, wird standardmäßig die aktuelle Zeit in Millisekunden verwendet, die aus System.currentTimeMillis() des Rechners abgerufen wird, auf dem das NoSQL Database Migrator-Tool ausgeführt wird.

• Datentyp: Datum
• Erforderlich (J/N): N
• Beispiel: "ttlRelativeDate" : "2021-01-03 04:31:17"

  Betrachten wir ein Szenario, in dem Tabellenzeilen nach sieben Tagen ab dem 1. Januar 2021 ablaufen. Nach dem Export dieser Tabelle treten am 7. Januar 2021 Probleme mit der Tabelle auf und Sie entscheiden, die Daten zu importieren. Die Tabellenzeilen laufen an einem Tag ab (Datenablaufdatum minus dem Standardwert des Konfigurationsparameters ttlRelativedate, dem aktuellen Datum). Wenn Sie jedoch das Ablaufdatum von Tabellenzeilen auf fünf Tage anstatt auf einen Tag erweitern möchten, verwenden Sie den Parameter ttlRelativeDate, und wählen Sie ein früheres Datum aus. Wenn Sie also in diesem Szenario die Ablaufzeit der Tabellenzeilen um fünf Tage verlängern möchten, setzen Sie den Wert der Konfigurationsparameter ttlRelativeDate auf den 3. Januar 2021. Dieser Wert wird beim Import von Tabellenzeilen als Referenzzeitpunkt verwendet.

schemainfo

• Zweck: Gibt das Schema für die zu migrierenden Daten an. Wenn dies nicht angegeben ist, geht der NoSQL Database Migrator davon aus, dass die Tabelle bereits im Speicher der Senke vorhanden ist.

• Datentyp: Objekt
• Erforderlich (J/N): N

schemaInfo.schemaPath

• Zweck: Gibt den absoluten Pfad zu einer Datei an, die DDL-Anweisungen für die Tabelle NoSQL enthält.

  Der NoSQL Database Migrator führt die in dieser Datei aufgeführten DDL-Befehle aus, bevor die Daten migriert werden.

  Der NoSQL Database Migrator unterstützt nicht mehr als eine DDL-Anweisung pro Zeile in der Datei schemaPath.

• Datentyp: Zeichenfolge

• Erforderlich (J/N): N

  Hinweis:

  defaultSchema und schemaPath schließen sich gegenseitig aus.

• Beispiel: "schemaPath" : "/home/user/schema_file"

schemaInfo.defaultSchema

• Zweck: Wenn dieser Parameter auf true gesetzt wird, wird der NoSQL Database Migrator angewiesen, eine Tabelle mit dem Standardschema zu erstellen. Das Standardschema wird vom Migrator selbst definiert. Weitere Informationen zu Standardschemadefinitionen finden Sie unter Standardschema in Oracle NoSQL Data Migrator verwenden.

• Datentyp: Boolescher Wert

• Erforderlich (J/N): N

  Hinweis:

  defaultSchema und schemaPath schließen sich gegenseitig aus.

schemaInfo.useSourceSchema

• Zweck: Gibt an, ob die Sink die Tabellenschemadefinition verwendet, die von der Quelle bei der Migration von NoSQL-Tabellen angegeben wird.

• Datentyp: Boolescher Wert

• Erforderlich (J/N): N

  Hinweis:

  Die Parameter defaultSchema, schemaPath und useSourceSchema schließen sich gegenseitig aus. Geben Sie nur einen dieser Parameter an.
• Beispiel:
  • Mit Standardschema:

    "schemaInfo" : {
      "defaultSchema" : true
    }

  • Mit einem vordefinierten Schema:

    "schemaInfo" : {
     "schemaPath" : "<complete/path/to/the/schema/definition/file>"
    }

  • Mit dem Quellschema:

    "schemaInfo" : {
      "useSourceSchema" : true
    }

schemaInfo.DDBPartitionKey

• Zweck: Gibt den Partitionsschlüssel DynamoDB und den entsprechenden Oracle NoSQL Database-Typ an, der in der Oracle NoSQL Database-Sinktabelle verwendet werden soll. Dieser Schlüssel wird als Shard-Schlüssel der DB-Tabelle NoSQL verwendet. Dies gilt nur, wenn defaultSchema auf "true" gesetzt ist und das Quellformat dynamodb_json ist. Weitere Informationen finden Sie unter DynamoDB-Typen Oracle-NoSQL-Typen zuordnen.
• Erforderlich (J/N): J, wenn defaultSchema wahr ist und die Quelle dynamodb_json ist.
• Beispiel: "DDBPartitionKey" : "PersonID:INTEGER"

  Hinweis:

  Wenn der Partitionsschlüssel Bindestrich (-) oder Punkt () enthält, wird er vom Migrator durch Unterstrich (_) ersetzt, da der Spaltenname NoSQL keinen Punkt und Bindestrich unterstützt.

schemaInfo.DDBSortKey

• Zweck: Gibt den Sortierschlüssel DynamoDB und den entsprechenden Oracle NoSQL Database-Typ an, der in der Oracle NoSQL Database-Zieltabelle verwendet werden soll. Wenn die importierende Tabelle DynamoDB keinen Sortierschlüssel enthält, darf dieses Attribut nicht festgelegt werden. Dieser Schlüssel wird als Nicht-Shard-Teil des Primärschlüssels in der DB-Tabelle NoSQL verwendet. Dies gilt nur, wenn defaultSchema auf "true" gesetzt ist und die Quelle dynamodb_json ist. Weitere Informationen finden Sie unter DynamoDB-Typen Oracle-NoSQL-Typen zuordnen.
• Erforderlich (J/N): N
• Beispiel: "DDBSortKey" : "Skey:STRING"

  Hinweis:

  Wenn der Sortierschlüssel Bindestriche (-) oder Punkte () enthält, ersetzt ihn der Migrator durch Unterstriche (_), da der Spaltenname NoSQL keinen Punkt und Bindestrich unterstützt.

overwrite

• Zweck: Gibt das Verhalten von NoSQL Database Migrator an, wenn der aus der Quelle migrierte Datensatz bereits in der Senke vorhanden ist.

  Wenn der Wert auf "false" gesetzt ist, überspringt der NoSQL Database Migrator beim Migrieren von Tabellen die Datensätze, für die bereits derselbe Primärschlüssel in der Senke vorhanden ist.

  Wenn der Wert auf "true" gesetzt ist, überschreibt der NoSQL Database Migrator bei der Migration von Tabellen die Datensätze, für die bereits derselbe Primärschlüssel in der Senke vorhanden ist.

  Wenn keine Angabe gemacht wird, wird standardmäßig "true" verwendet.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N
• Beispiel: "overwrite" : false

Oracle NoSQL Database Cloud Service

Das Konfigurationsdateiformat für Oracle NoSQL Database Cloud Service als Sink von NoSQL Database Migrator wird unten angezeigt.

Sinkkonfigurationsvorlage

"sink" : {
  "type" : "nosqldb_cloud",
  "endpoint" : "<Oracle NoSQL Cloud Service Endpoint>",
  "table" : "<table name>",
  "compartment" : "<OCI compartment name or id>",
  "includeTTL": <true|false>,
  "ttlRelativeDate" : "<date-to-use in UTC>",  
  "schemaInfo" : {
    "schemaPath" : "</path/to/a/schema/file>",
    "defaultSchema" : <true|false>,
    "useSourceSchema" : <true|false>,
    "DDBPartitionKey" : <"name:type">,
    "DDBSortKey" : "<name:type>",
    "onDemandThroughput" : <true|false>,
    "readUnits" : <table read units>,
    "writeUnits" : <table write units>,
    "storageSize" : <storage size in GB>
   },
  "credentials" : "</path/to/oci/credential/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "writeUnitsPercent" : <table writeunits percent>,
  "requestTimeoutMs" : <timeout in milli seconds>,
  "overwrite" : <true|false>
}

Sink-Parameter

Allgemeine Konfigurationsparameter

• Typ

  Verwenden Sie "type" : "nosqldb_cloud"

• endpoint
  Beispiel:

  • Regions-ID: "endpoint" : "us-ashburn-1"

  • URL-Format: "endpoint" : "https://objectstorage.us-ashburn-1.oraclecloud.com"

• Zugangsdaten
  Beispiel:

  1. "credentials" : "/home/user/.oci/config"
  2. "credentials" : "/home/user/security/config"
• credentialsProfile
  Beispiel:

  1. "credentialsProfile" : "DEFAULT"
  2. "credentialsProfile" : "ADMIN_USER"
• useInstancePrincipal

  Beispiel: "useInstancePrincipal" : true

• useDelegationToken

  Beispiel: "useDelegationToken" : true

  Hinweis:

  Die Authentifizierung mit Delegationstoken wird nur unterstützt, wenn der NoSQL-Datenbankmigrator über eine Cloud Shell ausgeführt wird.
• requestTimeoutMs

  Beispiel: "requestTimeoutMs" : 5000

Eindeutiger Konfigurationsparameter

• Tabelle
• Compartment
• includeTTL
• ttlRelativeDate
• schemaInfo
• schemaInfo.schemaPath
• schemaInfo.defaultSchema
• schemaInfo.useSourceSchema
• schemaInfo.DDBPartitionKey
• schemaInfo.DDBSortKey
• schemaInfo.onDemandThroughput
• schemaInfo.readUnits
• schemaInfo.writeUnits
• schemaInfo.storageSize
• writeUnitsPercent
• overwrite

Tabelle

• Zweck: Gibt den Tabellennamen zum Speichern der migrierten Daten an.

  Sie müssen sicherstellen, dass diese Tabelle in Oracle NoSQL Database Cloud Service vorhanden ist. Andernfalls müssen Sie das Objekt schemaInfo in der Sink-Konfiguration verwenden, um den NoSQL Database Migrator anzuweisen, die Tabelle zu erstellen.

  Das Schema dieser Tabelle muss mit den Quelldaten übereinstimmen.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J
• Beispiel:
  • So geben Sie eine Tabelle an: "table" : "mytable"
  • So geben Sie eine untergeordnete Tabelle an: "table" : "mytable.child"

    Hinweis:

    Sie können die untergeordneten Tabellen von einer gültigen Datenquelle in Oracle NoSQL Database Cloud Service migrieren. Der NoSQL-Datenbankmigrator kopiert nur eine einzelne Tabelle in jeder Ausführung. Stellen Sie sicher, dass die übergeordnete Tabelle vor der untergeordneten Tabelle migriert wird.

Compartment

• Zweck: Gibt den Namen oder die OCID des Compartments an, in dem sich die Tabelle befindet.

  Wenn Sie keinen Wert angeben, wird standardmäßig das root-Compartment verwendet.

  Sie finden die OCID Ihres Compartments im Compartment Explorer-Fenster unter "Governance" in der OCI Cloud-Konsole.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J, wenn sich die Tabelle nicht im Root Compartment des Mandanten befindet ODER wenn der Parameter useInstancePrincipal auf "true" gesetzt ist.

  Hinweis:

  Wenn der Parameter useInstancePrincipal auf "true" gesetzt ist, muss das Compartment die Compartment-OCID und nicht den Namen angeben.
• Beispiel:

  • Compartment Name

    "compartment" : "mycompartment"

  • Compartment-Name mit übergeordnetem Compartment qualifiziert

    "compartment" : "parent.childcompartment"

  • Kein Wert angegeben. Wird standardmäßig auf das Root Compartment gesetzt.

    "compartment": ""

  • Compartment-OCID

    "compartment" : "ocid1.tenancy.oc1...4ksd"

includeTTL

• Zweck: Gibt an, ob TTL-Metadaten für Tabellenzeilen einbezogen werden sollen, die von der Quelle beim Importieren von Oracle NoSQL Database-Tabellen bereitgestellt werden.

  Wenn Sie diesen Parameter nicht angeben, wird er standardmäßig auf false gesetzt. In diesem Fall enthält der NoSQL Database Migrator keine TTL-Metadaten für Tabellenzeilen, die von der Quelle beim Importieren von Oracle NoSQL Database-Tabellen bereitgestellt werden.

  Wenn diese Option auf "true" gesetzt ist, führt das Tool NoSQL Database Migrator beim Importieren einer Tabellenzeile die folgenden Prüfungen der TTL-Metadaten aus:

  • Wenn Sie eine Zeile ohne _metadata-Definition importieren, setzt das Tool NoSQL Database Migrator die TTL auf 0. Das bedeutet, dass die Zeile nie abläuft.
  • Wenn Sie eine Zeile mit der Definition _metadata importieren, vergleicht das Tool NoSQL Database Migrator den TTL-Wert mit einer Referenzzeit, wenn eine Zeile importiert wird. Wenn die Zeile relativ zur Referenzzeit bereits abgelaufen ist, wird sie übersprungen. Wenn die Zeile nicht abgelaufen ist, wird sie zusammen mit dem TTL-Wert importiert. Standardmäßig ist die Referenzzeit des Importvorgangs die aktuelle Zeit in Millisekunden, die aus System.currentTimeMillis() des Rechners abgerufen wird, auf dem das Datenbankmigrator-Tool NoSQL 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 Formel zur Berechnung der Ablaufzeit eines Datensatzes lautet wie folgt:

    expiration = (TTL value of source row in milliseconds - Reference Time in milliseconds)
    if (expiration <= 0) then it indicates that row has expired.

    Hinweis:

    Da die TTL-Grenzen von Oracle NoSQL in Stunden und Tagen angegeben sind, kann die TTL der importierten Zeile in einigen Fällen auf die nächste Stunde oder den nächsten Tag angepasst werden. Beispiel: Eine Zeile mit dem Ablaufwert 1629709200000 (2021-08-23 09:00:00) und dem Referenzzeitwert 1629707962582 (2021-08-23 08:39:22). Auch wenn die Zeile beim Import dieser Daten relativ zur Referenzzeit nicht abgelaufen ist, lautet die neue TTL für die Zeile 1629712800000 (2021-08-23 10:00:00).
• Datentyp: boolescher Wert
• Erforderlich (J/N): N
• Beispiel: "includeTTL" : true

ttlRelativeDate

• Zweck: Geben Sie ein UTC-Datum im Format JJJJ-MM-TT hh:mm:ss an, mit dem der TTL-Ablauf von Tabellenzeilen beim Import in Oracle NoSQL Database festgelegt wird.

  Wenn eine Tabellenzeile in den Daten, die Sie exportieren, abgelaufen ist, können Sie den Parameter ttlRelativeDate auf ein Datum setzen, das vor der Ablaufzeit der Tabellenzeile in den exportierten Daten liegt.

  Wenn Sie diesen Parameter nicht angeben, wird standardmäßig die aktuelle Zeit in Millisekunden verwendet, die aus System.currentTimeMillis() des Rechners abgerufen wird, auf dem das NoSQL Database Migrator-Tool ausgeführt wird.

• Datentyp: Datum
• Erforderlich (J/N): N
• Beispiel: "ttlRelativeDate" : "2021-01-03 04:31:17"

  Betrachten wir ein Szenario, in dem Tabellenzeilen nach sieben Tagen ab dem 1. Januar 2021 ablaufen. Nach dem Export dieser Tabelle treten am 7. Januar 2021 Probleme mit der Tabelle auf und Sie entscheiden, die Daten zu importieren. Die Tabellenzeilen laufen an einem Tag ab (Datenablaufdatum minus dem Standardwert des Konfigurationsparameters ttlRelativedate, dem aktuellen Datum). Wenn Sie jedoch das Ablaufdatum von Tabellenzeilen auf fünf Tage anstatt auf einen Tag erweitern möchten, verwenden Sie den Parameter ttlRelativeDate, und wählen Sie ein früheres Datum aus. Wenn Sie also in diesem Szenario die Ablaufzeit der Tabellenzeilen um fünf Tage verlängern möchten, setzen Sie den Wert der Konfigurationsparameter ttlRelativeDate auf den 3. Januar 2021. Dieser Wert wird beim Import von Tabellenzeilen als Referenzzeitpunkt verwendet.

schemaInfo

• Zweck: Gibt das Schema für die zu migrierenden Daten an.

  Wenn Sie diesen Parameter nicht angeben, geht der NoSQL Database Migrator davon aus, dass die Tabelle bereits in Oracle NoSQL Database Cloud Service vorhanden ist.

  Wenn dieser Parameter nicht angegeben ist und die Tabelle nicht in der Sink vorhanden ist, verläuft die Migration nicht erfolgreich.

• Datentyp: Objekt
• Erforderlich (J/N): N

schemaInfo.schemaPath

• Zweck: Gibt den absoluten Pfad zu einer Datei an, die DDL-Anweisungen für die Tabelle NoSQL enthält.

  Der NoSQL Database Migrator führt die in dieser Datei aufgeführten DDL-Befehle aus, bevor die Daten migriert werden.

  Der NoSQL Database Migrator unterstützt nicht mehr als eine DDL-Anweisung pro Zeile in der Datei schemaPath.

• Datentyp: Zeichenfolge

• Erforderlich (J/N): N

  Hinweis:

  defaultSchema und schemaPath schließen sich gegenseitig aus.

• Beispiel: "schemaPath" : "/home/user/schema_file"

schemaInfo.defaultSchema

• Zweck: Wenn Sie diesen Parameter auf Ja setzen, wird der NoSQL Database Migrator angewiesen, eine Tabelle mit dem Standardschema zu erstellen. Das Standardschema wird vom Migrator selbst definiert. Weitere Informationen zu Standardschemadefinitionen finden Sie unter Standardschema in Oracle NoSQL Data Migrator verwenden.

• Datentyp: Boolescher Wert

• Erforderlich (J/N): N

  Hinweis:

  defaultSchema und schemaPath schließen sich gegenseitig aus.

schemaInfo.useSourceSchema

• Zweck: Gibt an, ob die Sink die Tabellenschemadefinition verwendet, die von der Quelle bei der Migration von NoSQL-Tabellen angegeben wird.

• Datentyp: Boolescher Wert

• Erforderlich (J/N): N

  Hinweis:

  Die Parameter defaultSchema, schemaPath und useSourceSchema schließen sich gegenseitig aus. Geben Sie nur einen dieser Parameter an.
• Beispiel:
  • Mit Standardschema:

    "schemaInfo": {
      "defaultSchema": true,
      "readUnits": 100,
      "writeUnits": 60,
      "storageSize": 1
    }

  • Mit einem vordefinierten Schema:

    "schemaInfo": {
      "schemaPath": "<complete/path/to/the/schema/definition/file>",
      "readUnits": 100,
      "writeUnits": 100,
      "storageSize": 1
    }

  • Mit dem Quellschema:

    "schemaInfo": {
      "useSourceSchema": true,
      "readUnits": 100,
      "writeUnits": 60,
      "storageSize": 1
    }

schemaInfo.DDBPartitionKey

• Zweck: Gibt den Partitionsschlüssel DynamoDB und den entsprechenden Oracle NoSQL Database-Typ an, der in der Oracle NoSQL Database-Sinktabelle verwendet werden soll. Dieser Schlüssel wird als Shard-Schlüssel der DB-Tabelle NoSQL verwendet. Dies gilt nur, wenn defaultSchema auf "true" gesetzt ist und das Quellformat dynamodb_json ist. Weitere Informationen finden Sie unter DynamoDB-Typen Oracle-NoSQL-Typen zuordnen.
• Erforderlich (J/N): J, wenn defaultSchema wahr ist und die Quelle dynamodb_json ist.
• Beispiel: "DDBPartitionKey" : "PersonID:INTEGER"

  Hinweis:

  Wenn der Partitionsschlüssel Bindestrich (-) oder Punkt () enthält, wird er vom Migrator durch Unterstrich (_) ersetzt, da der Spaltenname NoSQL keinen Punkt und Bindestrich unterstützt.

schemaInfo.DDBSortKey

• Zweck: Gibt den Sortierschlüssel DynamoDB und den entsprechenden Oracle NoSQL Database-Typ an, der in der Oracle NoSQL Database-Zieltabelle verwendet werden soll. Wenn die importierende Tabelle DynamoDB keinen Sortierschlüssel enthält, darf dieses Attribut nicht festgelegt werden. Dieser Schlüssel wird als Nicht-Shard-Teil des Primärschlüssels in der DB-Tabelle NoSQL verwendet. Dies gilt nur, wenn defaultSchema auf "true" gesetzt ist und die Quelle dynamodb_json ist. Weitere Informationen finden Sie unter DynamoDB-Typen Oracle-NoSQL-Typen zuordnen.
• Erforderlich (J/N): N
• Beispiel: "DDBSortKey" : "Skey:STRING"

  Hinweis:

  Wenn der Sortierschlüssel Bindestriche (-) oder Punkte () enthält, ersetzt ihn der Migrator durch Unterstriche (_), da der Spaltenname NoSQL keinen Punkt und Bindestrich unterstützt.

schemaInfo.onDemandThroughput

• Zweck: Gibt an, dass die Tabelle mit On-Demand-Lese- und -Schreibdurchsatz erstellt werden soll. Wenn dieser Parameter nicht festgelegt ist, wird die Tabelle mit bereitgestellter Kapazität erstellt.

  Der Standardwert ist false.

  Hinweis:

  Dieser Parameter gilt nicht für untergeordnete Tabellen, da sie den Durchsatz der übergeordneten Tabelle der obersten Ebene gemeinsam nutzen.

• Datentyp: Boolescher Wert

• Erforderlich (J/N): N

• Beispiel: "onDemandThroughput" : "true"

schemaInfo.readUnits

• Zweck: Gibt den Lesedurchsatz der neuen Tabelle an.

  Hinweis:

  • Dieser Parameter gilt nicht für Tabellen, die mit On-Demand-Kapazität bereitgestellt werden.
  • Dieser Parameter gilt nicht für untergeordnete Tabellen, da sie den Lesedurchsatz der übergeordneten Tabelle der obersten Ebene gemeinsam nutzen.

• Datentyp: Ganzzahl

• Erforderlich (J/N): J, wenn die Tabelle keine untergeordnete Tabelle ist oder der Parameter schemaInfo.onDemandThroughput auf false gesetzt ist, andernfalls N.

• Beispiel: "readUnits" : 100

schemaInfo.writeUnits

• Zweck: Gibt den Schreibdurchsatz der neuen Tabelle an.

  Hinweis:

  • Dieser Parameter gilt nicht für Tabellen, die mit On-Demand-Kapazität bereitgestellt werden.
  • Dieser Parameter gilt nicht für untergeordnete Tabellen, da sie den Schreibdurchsatz der übergeordneten Tabelle der obersten Ebene gemeinsam nutzen.

• Datentyp: Ganzzahl

• Erforderlich (J/N): J, wenn die Tabelle keine untergeordnete Tabelle ist oder der Parameter schemaInfo.onDemandThroughput auf false gesetzt ist, andernfalls N.

• Beispiel: "writeUnits" : 100

schemaInfo.storageSize

• Zweck: Gibt die Speichergröße der neuen Tabelle in GB an.

  Hinweis:

  Dieser Parameter gilt nicht für untergeordnete Tabellen, da sie die Speichergröße der übergeordneten Tabelle der obersten Ebene gemeinsam verwenden.

• Datentyp: Ganzzahl

• Erforderlich (J/N): J, wenn die Tabelle keine untergeordnete Tabelle ist, andernfalls N.

• Beispiel:

  • Mit schemaPath

    "schemaInfo" : { 
      "schemaPath" : "</path/to/a/schema/file>",
      "readUnits" : 500,
      "writeUnits" : 1000,
      "storageSize" : 5 }

  • Mit defaultSchema

    "schemaInfo" : {
      "defaultSchema" :Yes,
      "readUnits" : 500,   
      "writeUnits" : 1000,   
      "storageSize" : 5  
    }

writeUnitsPercent

• Zweck: Gibt den Prozentsatz der Tabellenschreibeinheiten an, die während der Migrationsaktivität verwendet werden sollen. Die für die Migration von Daten erforderliche Zeit ist direkt proportional zu diesem Attribut.

  Der Standardwert ist 90. Der gültige Bereich ist eine Ganzzahl zwischen 1 und 100.

  Informationen zur Verwendung dieses Attributs zur Verbesserung der Datenmigrationsgeschwindigkeit finden Sie unter Fehlerbehebung bei Oracle NoSQL Database-Migrator.

• Datentyp: Ganzzahl
• Erforderlich (J/N): N
• Beispiel: "writeUnitsPercent" : 90

overwrite

• Zweck: Gibt das Verhalten von NoSQL Database Migrator an, wenn der aus der Quelle migrierte Datensatz bereits in der Senke vorhanden ist.

  Wenn der Wert auf "false" gesetzt ist, überspringt der NoSQL Database Migrator beim Migrieren von Tabellen die Datensätze, für die bereits derselbe Primärschlüssel in der Senke vorhanden ist.

  Wenn der Wert auf "true" gesetzt ist, überschreibt der NoSQL Database Migrator bei der Migration von Tabellen die Datensätze, für die bereits derselbe Primärschlüssel in der Senke vorhanden ist.

  Wenn keine Angabe gemacht wird, wird standardmäßig "true" verwendet.

• Datentyp: boolescher Wert
• Erforderlich (J/N): N
• Beispiel: "overwrite" : false

Transformationskonfigurationsvorlagen

In diesem Thema werden die Konfigurationsparameter für die verschiedenen Transformationen erläutert, die vom Oracle NoSQL Database-Migrator unterstützt werden. Die vollständige Konfigurationsdateivorlage finden Sie unter Konfigurationsdatei in Terminologie mit NoSQL-Datenmigrator.

Mit dem Oracle NoSQL Database-Migrator können Sie die Daten ändern, d.h. Datentransformationen als Teil der Migrationsaktivität hinzufügen. Sie können mehrere Transformationen in einer einzelnen Migration definieren. In einem solchen Fall ist die Reihenfolge der Transformationen von entscheidender Bedeutung, da die Quelldaten jede Transformation in der angegebenen Reihenfolge durchlaufen. Die Ausgabe einer Transformation wird zur Eingabe zur nächsten in der Migrationspipeline.

Die verschiedenen vom Datenmigrator NoSQL unterstützten Transformationen sind:

Tabelle - Transformationen

Transformationskonfigurationsattribut	Mit dieser Transformation können Sie...
ignoreFields	Ignorieren Sie die identifizierten Spalten aus der Quellzeile, bevor Sie in die Senke schreiben.
includeFields	Nehmen Sie die identifizierten Spalten aus der Quellzeile auf, bevor Sie in die Senke schreiben.
renameFields	Benennen Sie die identifizierten Spalten aus der Quellzeile um, bevor Sie in die Senke schreiben.
aggregateFields	Aggregieren Sie mehrere Spalten aus der Quelle in eine einzelne Spalte in der Senke. Im Rahmen dieser Transformation können Sie auch die Spalten identifizieren, die Sie in der Aggregation ausschließen möchten. Diese Felder werden aus der aggregierten Spalte übersprungen.

Die Konfigurationsvorlage für jede unterstützte Transformation finden Sie unten.

ignoreFields

Das Konfigurationsdateiformat für die ignoreFields-Transformation wird unten angezeigt.

Transaktionskonfigurationsvorlage

"transforms" : {
  "ignoreFields" : ["<field1>","<field2>",...]
}

Transformationsparameter

ignoreFields

• Zweck: Ein Array der Spaltennamen, die aus den Quelldatensätzen ignoriert werden sollen.

  Hinweis:

  Sie können nur Felder der obersten Ebene angeben. Transformationen können nicht auf die Daten in den verschachtelten Feldern angewendet werden.
• Datentyp: Array von Zeichenfolgen
• Erforderlich (J/N): J

• Beispiel: So ignorieren Sie die Spalten "Name" und "Adresse" aus dem Quelldatensatz:

  "ignoreFields" : ["name","address"]

includeFields

Das Konfigurationsdateiformat für die includeFields-Transformation wird unten angezeigt.

Transaktionskonfigurationsvorlage

"transforms" : {
  "includeFields" : ["<field1>","<field2>",...]
}

Transformationsparameter

includeFields

• Zweck: Ein Array der Spaltennamen, die aus den Quelldatensätzen aufgenommen werden sollen. Sie enthält nur die im Array angegebenen Felder. Die übrigen Felder werden ignoriert.

  Hinweis:

  Das Tool NoSQL Database Migrator löst einen Fehler aus, wenn Sie ein leeres Array angeben. Außerdem können Sie nur die Felder der obersten Ebene angeben. Das Tool NoSQL Database Migrator wendet keine Transformationen auf die Daten in den verschachtelten Feldern an.
• Datentyp: Array von Zeichenfolgen
• Erforderlich (J/N): J

• Beispiel: So ignorieren Sie die Spalten "Alter" und "Geschlecht" aus dem Quelldatensatz:

  "includeFields" : ["age","gender"]

renameFields

Das Konfigurationsdateiformat für die renameFields-Transformation wird unten angezeigt.

Transaktionskonfigurationsvorlage

"transforms" : {
  "renameFields" : {
    "<old_name>" : "<new_name>",
    "<old_name>" : "<new_name>,"
    .....
  }
}

Transformationsparameter

renameFields

• Zweck: Schlüssel/Wert-Paare der alten und neuen Namen der umzubenennenden Spalten.

  Hinweis:

  Sie können nur Felder der obersten Ebene angeben. Transformationen können nicht auf die Daten in den verschachtelten Feldern angewendet werden.
• Datentyp: JSON-Objekt
• Erforderlich (J/N): J

• Beispiel: So benennen Sie die Spalte "residence" in "address" und die Spalte "_id" in "id" um:

  "renameFields" : { "residence" : "address", "_id" : "id" }

aggregateFields

Das Konfigurationsdateiformat für die aggregateFields-Transformation wird unten angezeigt.

Transaktionskonfigurationsvorlage

"transforms" : {
  "aggregateFields" : {
    "fieldName" : "name of the new aggregate field",
    "skipFields" : ["<field1>","<field2">,...]
  }
}

Transformationsparameter

aggregateFields

• Zweck: Name des aggregierten Feldes in der Senke.

• Datentyp: Zeichenfolge
• Erforderlich (J/N): J

• Beispiel: Wenn der angegebene Datensatz:

  {
    "id" : 100,
    "name" : "john",
    "address" : "USA",
    "age" : 20
  }

  Wenn die Aggregattransformation:

  "aggregateFields" : {
    "fieldName" : "document",
    "skipFields" : ["id"]
  }

  Die aggregierte Spalte in der Spüle sieht wie folgt aus:

  {
    "id": 100,
    "document": {
      "name": "john",
      "address": "USA",
      "age": 20
    }
  }

Zuordnung von DynamoDB-Typen zu Oracle NoSQL-Typen

Die folgende Tabelle zeigt die Zuordnung von DynamoDB-Typen zu Oracle-NoSQL-Typen.

Tabelle - DynamoDB-Typ wird Oracle NoSQL-Typ zugeordnet

#	Typ DynamoDB	JSON-Typ für JSON-Spalte NoSQL	Oracle-NoSQL-Typ
1	Zeichenfolge (S)	JSON-Zeichenfolge	STRING
2	Zahlentyp (N)	JSON-Nummer	GANZZAHL/LANG/GLEITKOMMAZAHL/DOPPEL/ZAHL
3	Boolescher Wert (BOOL)	JSON - Boolescher Wert	BOOLEAN
4	Binärer Typ (B) - Byte-Puffer	BASE-64-codierte JSON-Zeichenfolge	BINARY
5	NULL	JSON nicht angegeben	NULL
6	Zeichensatz (SS)	JSON-Zeichenfolgenarray	ARRAY (ZEICHENFOLGE)
7	NummernSet (NS)	JSON-Zahlenarray	ARRAY (GANZZAHL/LANG/GLEITKOMMAZAHL/DOPPEL/ZAHL)
8	Binärset (BS)	JSON-Array mit Base-64-codierten Zeichenfolgen	ARRAY (BINÄR)
9	LISTE (L)	Array von JSON	ARRAY (JSON)
10	KARTE (M)	JSON-Objekt	JSON
11	PARTITIONSSCHLÜSSEL	-	PRIMARY KEY UND SHARD KEY
12	SORTIERSCHLÜSSEL	-	PRIMÄRSCHLÜSSEL
13	Attributnamen mit Bindestrich und Punkt	JSON-Feldnamen mit Unterstrich	Spaltennamen mit Unterstrichen

Bei der Zuordnung von DynamoDB-Typen zu Oracle-NoSQL-Typen sind nur wenige zusätzliche Punkte zu berücksichtigen:

• DynamoDB Unterstützt nur einen Datentyp für Zahlen und kann eine Genauigkeit von bis zu 38 Stellen aufweisen. Im Gegensatz dazu unterstützt Oracle NoSQL viele Typen zur Auswahl basierend auf dem Bereich und der Genauigkeit von data.You, um den entsprechenden Zahlentyp auszuwählen, der dem Bereich Ihrer Eingabedaten entspricht. Wenn Sie sich über die Art der Daten nicht sicher sind, kann der Typ NoSQL NUMBER verwendet werden.
• DynamoDB Unterstützt nur einen Datentyp für Zahlen und kann eine Genauigkeit von bis zu 38 Stellen aufweisen. Im Gegensatz dazu unterstützt Oracle NoSQL viele Typen zur Auswahl basierend auf dem Bereich und der Genauigkeit von data.You, um den entsprechenden Zahlentyp auszuwählen, der dem Bereich Ihrer Eingabedaten entspricht. Wenn Sie sich über die Art der Daten nicht sicher sind, kann der Typ NoSQL NUMBER verwendet werden.
• Der Partitionsschlüssel in DynamoDB ist auf 2048 Byte begrenzt. Oracle NoSQL Cloud Service ist jedoch auf 64 Byte für den Primärschlüssel/Shard-Schlüssel begrenzt.
• Der Sortierschlüssel in DynamoDB ist auf 1024 Byte begrenzt, Oracle NoSQL Cloud Service ist jedoch auf 64 Byte für den Primärschlüssel begrenzt.
• Attributnamen in DynamoDB können 64 KB lang sein, Oracle NoSQL Cloud-Service-Spaltennamen sind jedoch auf 64 Zeichen begrenzt.

Zuordnung von Oracle NoSQL zu Parquet-Datentypen

Beschreibung der Zuordnung von Oracle NoSQL-Datentypen zu Parquet-Datentypen.

NoSQL-Typ	Parquet-Typ
BOOLEAN	BOOLEAN
INTEGER	INT32
LONG	INT64
FLOAT	DOUBLE
DOUBLE	DOUBLE
BINARY	BINARY
FIXED_BINARY	BINARY
STRING	BINÄR (ZEICHENFOLGE)
ENUM	BINÄR (ZEICHENFOLGE) oder BINARY(ENUM), wenn die logische ENUM konfiguriert ist
UUID	BINÄR (ZEICHENFOLGE) oder FIXED_BINARY(16), wenn die logische UUID konfiguriert ist
TIMESTAMP(p)	INT64(TIMESTAMP(p))
NUMBER	DOUBLE
field_name ARRAY (T)	group field_name(LIST) { repeated group list { required T element } }
field_name ZUORDNUNG (T)	group field_name (MAP) { repeated group key_value (MAP_KEY_VALUE) { required binary key (STRING); required T value; } }
field_name RECORD(K₁ T₁ N₁, Kٖ₂ T₂ N₂, ....) Hierbei gilt: K = Schlüsselname T = Typ N = Nullierbar oder nicht	group field_name { ni == true ? optional Ti ki : required Ti ki }
JSON	BINÄR (ZEICHENFOLGE) oder BINARY(JSON), wenn logisches JSON konfiguriert ist

Hinweis:

Wenn der Zahlentyp NoSQL in den Typ "Parquet Double" konvertiert wird, kann es zu einem gewissen Nachkommastellenverlust kommen, falls der Wert nicht in "Doppelt" dargestellt werden kann. Wenn die Zahl zu groß ist, um sie als Double darzustellen, wird sie in Double.NEGATIVE_INFINITY oder Double.POSITIVE_INFINITY konvertiert.

Zuordnung der Tabelle DynamoDB zur Tabelle Oracle NoSQL

In DynamoDB ist eine Tabelle eine Sammlung von Elementen, und jedes Element ist eine Sammlung von Attributen. Jedes Element in der Tabelle hat eine eindeutige ID oder einen Primärschlüssel. Abgesehen vom Primärschlüssel ist die Tabelle ohne Schema. Jedes Element kann eigene eindeutige Attribute aufweisen.

DynamoDB unterstützt zwei verschiedene Arten von Primärschlüsseln:

• Partitionsschlüssel: Ein einfacher Primärschlüssel, der aus einem Attribut besteht, das als Partitionsschlüssel bezeichnet wird. DynamoDB verwendet den Wert des Partitionsschlüssels als Eingabe für eine interne Hash-Funktion. Die Ausgabe der Hash-Funktion bestimmt die Partition, in der das Element gespeichert wird.
• Partitionsschlüssel und Sortierschlüssel - Als zusammengesetzter Primärschlüssel setzt sich dieser Schlüsseltyp aus zwei Attributen zusammen. Das erste Attribut ist der Partitionsschlüssel, und das zweite Attribut ist der Sortierschlüssel. DynamoDB verwendet den Partitionsschlüsselwert als Eingabe für eine interne Hashfunktion. Die Ausgabe der Hash-Funktion bestimmt die Partition, in der das Element gespeichert wird. Alle Elemente mit demselben Partitionsschlüsselwert werden in sortierter Reihenfolge nach Sortierschlüsselwert gespeichert.

Im Gegensatz dazu unterstützen Oracle NoSQL-Tabellen flexible Datenmodelle mit schemalosem und schemalosem Design.

Es gibt zwei verschiedene Möglichkeiten, eine DynamoDB-Tabelle zu modellieren:

1. Tabelle DynamoDB als JSON-Dokument modellieren (empfohlen): Bei dieser Modellierung ordnen Sie alle Attribute der Dynamo-DB-Tabellen einer JSON-Spalte der Tabelle NoSQL zu, mit Ausnahme von Partitionsschlüssel und Sortierschlüssel. Sie modellieren Partitionsschlüssel und Sortierschlüssel als Primärschlüsselspalten der Tabelle NoSQL. Sie verwenden die Transformation AggregateFields, um Nicht-Primärschlüsseldaten in eine JSON-Spalte zu aggregieren.

   Hinweis:

   Der Migrator stellt eine benutzerfreundliche Konfiguration defaultSchema bereit, um automatisch eine schemalose DDL-Tabelle zu erstellen, die auch Attribute in einer JSON-Spalte aggregiert.
2. Tabelle DynamoDB als feste Spalten in Tabelle NoSQL modellieren: In dieser Modellierung erstellen Sie für jedes Attribut der Tabelle DynamoDB eine Spalte in der Tabelle NoSQL, wie unter Zuordnung von DynamoDB-Typen zu Oracle-Typen NoSQL angegeben. Sie modellieren Partitionsschlüssel und sortieren Schlüsselattribute als Primärschlüssel. Dies sollte nur verwendet werden, wenn Sie sicher sind, dass der Import des Tabellenschemas DynamoDB fest ist und jedes Element Werte für die meisten Attribute aufweist. Wenn DynamoDB-Elemente keine gemeinsamen Attribute aufweisen, kann dies zu vielen NoSQL-Spalten mit leeren Werten führen.

   Hinweis:

   Es wird dringend empfohlen, schemalose Tabellen zu verwenden, wenn Daten von DynamoDB zu Oracle NoSQL Database migriert werden, da die DynamoDB-Tabellen keine Schemas aufweisen. Dies gilt insbesondere für große Tabellen, bei denen der Inhalt der einzelnen Datensätze in der Tabelle möglicherweise nicht einheitlich ist.

Fehler bei einem Oracle NoSQL Database-Migrator beheben

Erfahren Sie mehr über die allgemeinen Herausforderungen, mit denen Sie bei der Verwendung von konfrontiert werden, und wie Sie sie lösen können.

Migration nicht erfolgreich. Wie kann ich dieses Problem lösen?

Ein Fehler bei der Datenmigration kann auf mehrere zugrunde liegende Gründe zurückzuführen sein. Die wichtigsten Ursachen sind unten aufgeführt:

Tabelle - Migrationsfehlerursachen

Fehlermeldung	Bedeutung	Auflösung
Failed to connect to Oracle NoSQL Database	Der Migrator konnte keine Verbindung zur NoSQL-Datenbank herstellen.	Prüfen Sie, ob die Werte der Attribute storeName und helperHosts in der JSON-Konfigurationsdatei gültig sind und ob die Hosts erreichbar sind. Prüfen Sie bei einem gesicherten Speicher, ob die Sicherheitsdatei mit den korrekten Werten für Benutzername und Kennwort gültig ist.
Failed to connect to Oracle NoSQL Database Cloud Service	Der Migrator konnte keine Verbindung zu Oracle NoSQL Database Cloud Service herstellen.	Prüfen Sie, ob die Endpunkt-URL oder der Regionsname in der JSON-Konfigurationsdatei korrekt ist. Prüfen Sie, ob die OCI-Zugangsdatendatei in dem in der Konfigurations-JSON-Datei angegebenen Pfad verfügbar ist. Stellen Sie sicher, dass die in den OCI-Zugangsdaten angegebenen OCI-Zugangsdaten gültig sind.
Table not found	Die für die Migration angegebene Tabelle konnte nicht vom NoSQL Database Migrator gefunden werden.	Für die Quelle: Prüfen Sie, ob die Tabelle in der Quelldatenbank vorhanden ist. Stellen Sie sicher, dass die Tabelle mit ihrem Namespace in der JSON-Konfigurationsdatei angegeben ist, wenn die Tabelle in einem Nicht-Standard-Namespace erstellt wird. Prüfen Sie, ob Sie über die erforderliche Lese-/Schreibberechtigung für den Zugriff auf die Tabelle verfügen. Wenn die Quelle Oracle NoSQL Database Cloud Service ist, prüfen Sie, ob der gültige Compartment-Name in der Konfigurations-JSON-Datei angegeben ist, und stellen Sie sicher, dass Sie über die erforderliche Autorisierung für den Zugriff auf die Tabelle verfügen. Für den Waschbecken: Prüfen Sie, ob die Tabelle in der Spüle vorhanden ist. Wenn die Tabelle nicht vorhanden ist, müssen Sie sie entweder manuell erstellen oder mit der Konfiguration schemaInfo über die Migration erstellen.
DDL Execution failed	Die in der Eingabeschemadefinitionsdatei angegebenen DDL-Befehle sind ungültig.	Prüfen Sie die Syntax der DDL-Befehle in der Datei schemaPath. Stellen Sie sicher, dass nur eine DDL-Anweisung pro Zeile in der Datei schemaPath vorhanden ist.
failed to write record to the sink table with java.lang.IllegalArgumentException	Der Eingabedatensatz stimmt nicht mit dem Tabellenschema der Sink überein.	Prüfen Sie, ob die in der Zielsink-Tabelle angegebenen Datentypen und Spaltennamen mit dem Sink-Tabellenschema übereinstimmen. Wenn Sie eine Transformation angewendet haben, prüfen Sie, ob die transformierten Datensätze mit dem Sink-Tabellenschema übereinstimmen.
Request timeout	Der Vorgang der Quelle oder des Sinkens wurde nicht in der erwarteten Zeit abgeschlossen.	Prüfen Sie die Netzwerkverbindung. Prüfen Sie, ob die NoSQL-Datenbank hochgefahren und gestartet ist. Versuchen Sie, den Wert requestTimeout in der JSON-Konfigurationsdatei zu erhöhen.

Was muss ich vor dem Neustart einer nicht erfolgreichen Migration beachten?

Wenn eine Datenmigrationsaufgabe nicht erfolgreich verläuft, befindet sich die Senke bis zum Zeitpunkt des Fehlers in einem Zwischenzustand mit den importierten Daten. Sie können die Fehler- und Fehlerdetails in den Logs identifizieren und die Migration nach der Diagnose und Korrektur des Fehlers neu starten. Eine neu gestartete Migration wird neu gestartet und verarbeitet alle Daten von Anfang an. Es gibt keine Möglichkeit, die Migration ab dem Zeitpunkt des Fehlers zu prüfen und neu zu starten. Daher überschreibt NoSQL Database Migrator alle Datensätze, die bereits in die Sink migriert wurden.

Migration ist zu langsam. Wie kann ich es beschleunigen?

Die für die Datenmigration benötigte Zeit hängt von mehreren Faktoren ab, wie dem zu migrierenden Datenvolumen, der Netzwerkgeschwindigkeit und der aktuellen Datenbanklast. Bei einem Cloud-Service hängt die Migrationsgeschwindigkeit auch vom Lesedurchsatz und dem bereitgestellten Schreibdurchsatz ab. Um die Migrationsgeschwindigkeit zu verbessern, können Sie:

• Versuchen Sie, die aktuelle Workload in Oracle NoSQL Database zu reduzieren, während Sie die Daten migrieren.
• Stellen Sie sicher, dass der Rechner, auf dem Migration, Quelle und Sink ausgeführt werden, sich alle im selben Data Center befinden und die Netzwerklatenzen minimal sind.
• Stellen Sie bei Oracle NoSQL Database Cloud Service einen hohen Lese-/Schreibdurchsatz bereit, und prüfen Sie, ob der für die Tabelle zugewiesene Speicher ausreichend ist. Wenn der NoSQL-Datenbankmigrator die Tabelle nicht erstellt, können Sie den Schreibdurchsatz erhöhen. Wenn der Migrator die Tabelle erstellt, sollten Sie einen höheren Wert für den Parameter schemaInfo.writeUnits in der Sink-Konfiguration angeben. Nach Abschluss der Datenmigration können Sie diesen Wert senken. Beachten Sie die täglichen Limits für Durchsatzänderungen. Informationen hierzu finden Sie unter Cloud-Limits und Sinkkonfigurationsvorlagen.

Ich habe eine lange Migration mit riesigen Datensätzen. Wie kann ich den Fortschritt der Migration verfolgen?

Sie können zusätzliches Logging aktivieren, um den Fortschritt einer Migration mit langer Ausführungszeit zu verfolgen. Um das Loggingverhalten von Oracle NoSQL Database-Migrator zu steuern, müssen Sie die gewünschte Loggingebene in der Datei logging.properties festlegen. Diese Datei wird im Package NoSQL Database Migrator bereitgestellt und ist in dem Verzeichnis verfügbar, in dem der Oracle NoSQL Database-Migrator entpackt wurde. Die verschiedenen Logging-Ebenen sind OFF, SEVERE, WARNING, INFO, FINE, und ALL in der Reihenfolge, in der die Ausführlichkeit erhöht wird. Wenn Sie die Logebene auf OFF setzen, werden alle Logginginformationen deaktiviert, während die Logebene auf ALL gesetzt wird, werden die vollständigen Loginformationen bereitgestellt. Die Standard-Loggingebene ist WARNING. Die gesamte Loggingausgabe ist so konfiguriert, dass sie standardmäßig zur Konsole wechselt. In der Datei logging.properties werden Kommentare zu den einzelnen Logebenen angezeigt.

---

Titel und Copyright-Informationen

Oracle NoSQL Database-Migrator - Referenz

Copyright ©2022,2024,

Oracle und/oder verbundene Unternehmen.