Uso de Oracle NoSQL Database Migrator

Obtenga información sobre Oracle NoSQL Database Migrator y cómo utilizarlo para la migración de datos.

Oracle NoSQL Database Migrator es una herramienta que permite migrar tablas NoSQL de Oracle de un origen de datos a otro. Esta herramienta puede funcionar en tablas de Oracle NoSQL Database Cloud Service, Oracle NoSQL Database locales y AWS S3. La herramienta Migrator admite varios formatos de datos y tipos de medios físicos diferentes. Los formatos de datos soportados son archivos JSON, Parquet, JSON con formato MongoDB, JSON con formato DynamoDB y CSV. Los tipos de medios físicos soportados son archivos, OCI Object Storage, Oracle NoSQL Database local, Oracle NoSQL Database Cloud Service y AWS S3.

En este artículo se incluyen los siguientes temas:

Descripción general

Oracle NoSQL Database Migrator permite mover tablas NoSQL de Oracle de un origen de datos a otro, como Oracle NoSQL Database local o en la nube o incluso un archivo JSON simple.

Puede haber muchas situaciones que requieran que migre las tablas NoSQL desde o a una instancia de Oracle NoSQL Database. Por ejemplo, un equipo de desarrolladores que mejoren una aplicación de NoSQL Database puede que desee probar su código actualizado en la instancia local de Oracle NoSQL Database Cloud Service (NDCS) mediante cloudim. Para verificar todos los casos de prueba posibles, deben configurar los datos de prueba de forma similar a los datos reales. Para ello, deben copiar las tablas NoSQL del entorno de producción a su instancia de NDCS local, el entorno de cloudim. En otra situación, es posible que los desarrolladores de NoSQL necesiten mover los datos de sus aplicaciones de la ubicación local a la nube y viceversa, ya sea para el desarrollo o las pruebas.

En todos estos casos y muchos más, puede utilizar Oracle NoSQL Database Migrator para mover las tablas NoSQL de un origen de datos a otro, como Oracle NoSQL Database local o en la nube o incluso un archivo JSON simple. También puede copiar tablas NoSQL de un archivo de entrada JSON con formato MongoDB, un archivo de entrada JSON con formato DynamoDB (almacenado en el origen S3 de AWS o desde archivos) o un archivo CSV en la NoSQL Database local o en la nube.

Como se muestra en la siguiente figura, la utilidad NoSQL Database Migrator actúa como un conector o conducto entre el origen de datos y el destino (denominado receptor). Básicamente, esta utilidad exporta datos del origen seleccionado e importa esos datos al receptor. Esta herramienta está orientada a tablas, es decir, puede mover los datos solo a nivel de tabla. Una única tarea de migración funciona en una única tabla y soporta la migración de datos de tabla del origen al receptor en varios formatos de datos.

Oracle NoSQL Database Migrator está diseñado de forma que pueda soportar orígenes y receptores adicionales en el futuro. Para obtener una lista de los orígenes y los receptores soportados por Oracle NoSQL Database Migrator a partir de la versión actual, consulte Orígenes y receptores soportados.

Terminología utilizada con Oracle NoSQL Database Migrator

Obtenga información detallada sobre los diferentes términos utilizados en el diagrama anterior.

  • Origen: entidad desde la que se exportan las tablas NoSQL para la migración. Algunos ejemplos de orígenes son Oracle NoSQL Database local o en la nube, archivo JSON, archivo JSON con formato MongoDB, archivo JSON con formato DynamoDB y archivos CSV.
  • Fregadero: entidad que importa las tablas NoSQL desde NoSQL Database Migrator. Algunos ejemplos para los receptores son el archivo Oracle NoSQL Database local o en la nube y JSON.

La herramienta NoSQL Database Migrator admite diferentes tipos de orígenes y receptores (es decir, medios físicos o repositorios de datos) y formatos de datos (es decir, cómo se representan los datos en el origen o el receptor). Los formatos de datos soportados son archivos JSON, Parquet, JSON con formato MongoDB, JSON con formato DynamoDB y CSV. Los tipos de origen y de receptor soportados son archivos, OCI Object Storage, Oracle NoSQL Database local y Oracle NoSQL Database Cloud Service.

  • Conducto de migración: NoSQL Database Migrator transferirá los datos de un origen al receptor. Esto se puede visualizar como un conducto de migración.
  • Transformaciones: puede agregar reglas para modificar los datos de la tabla NoSQL en el canal de migración. Estas reglas se llaman transformaciones. Oracle NoSQL Database Migrator solo permite transformaciones de datos en campos o columnas de nivel superior. No permite transformar los datos en los campos anidados. Algunos ejemplos de transformaciones permitidas son:
    • Borrar o ignorar una o más columnas,
    • Cambie el nombre de una o más columnas, o
    • Agregue varias columnas en un solo campo, normalmente un campo JSON.
  • Archivo de configuración: un archivo de configuración es donde se definen todos los parámetros necesarios para la actividad de migración en formato JSON. Más tarde, pasará este archivo de configuración como un único parámetro al comando runMigrator desde la CLI. Un formato de archivo de configuración típico es similar al que se muestra a continuación.
    {
     "source": {
       "type" : <source type>,
       //source-configuration for type. See Source Configuration Templates  .
     },
     "sink": {
       "type" : <sink type>,
       //sink-configuration for type. See Sink Configuration Templates  .
     },
     "transforms" : {
       //transforms configuration. See Transformation Configuration Templates  .
     },
     "migratorVersion" : "<migrator version>",
     "abortOnError" : <true|false>
    }
    Agrupar Parámetros Obligatorio (Y/N) Finalidad Valores soportados
    source type S Representa el origen desde el que migrar los datos. El origen proporciona datos y metadatos (si los hay) para la migración. Para conocer el valor type para cada origen, consulte Supported Sources and Sinks.
    source configuración de origen para el tipo S Define la configuración para el origen. Estos parámetros de configuración son específicos del tipo de origen seleccionado anteriormente. Consulte Source Configuration Templates (Plantillas de configuración de origen) para obtener la lista completa de parámetros de configuración para cada tipo de origen.
    sink type S Representa el receptor al que migrar los datos. El sumidero es el destino o destino de la migración. Para conocer el valor type para cada origen, consulte Supported Sources and Sinks.
    sink sink-configuration para tipo S Define la configuración del receptor. Estos parámetros de configuración son específicos del tipo de receptor seleccionado anteriormente. Consulte Sink Configuration Templates para obtener una lista completa de los parámetros de configuración para cada tipo de receptor.
    transforms configuración de transformaciones N Define las transformaciones que se aplicarán a los datos del conducto de migración. Consulte Plantillas de configuración de transformación para obtener la lista completa de transformaciones soportadas por el migrador de datos NoSQL.
    - migratorVersion N Versión del migrador de datos NoSQL -
    - abortOnError N

    Especifica si se debe detener la actividad de migración en caso de error.

    El valor predeterminado es true, lo que indica que la migración se detiene cuando encuentra un error de migración.

    Si establece este valor en false, la migración continúa incluso en caso de registros con fallos u otros errores de migración. Los registros con fallos y los errores de migración se registrarán como ADVERTENCIAS en el terminal de la CLI.

    true, false

    Note:

    Como el archivo JSON es sensible a mayúsculas/minúsculas, todos los parámetros definidos en el archivo de configuración son sensibles a mayúsculas/minúsculas a menos que se especifique lo contrario.

Orígenes y receptores soportados

En este tema se proporciona la lista de orígenes y receptores soportados por Oracle NoSQL Database Migrator.

Puede utilizar cualquier combinación de un origen y un receptor válidos de esta tabla para la actividad de migración. Sin embargo, debe asegurarse de que al menos uno de los extremos, es decir, el origen o el receptor, debe ser un producto NoSQL de Oracle. No puede utilizar el NoSQL Database Migrator para mover los datos de la tabla NoSQL de un archivo a otro.

Tipo
(valor)

Formato
(valor)

Origen válido Fregadero válido

Oracle NoSQL Database
(nosqldb)

NA S S

Oracle NoSQL Database Cloud Service
(nosqldb_cloud)

NA S S

Sistema de archivos
(file)

JSON
(json)

S S

MongoDB JSON
(mongodb_json)

S N

DynamoDB JSON
(dynamodb_json)

S N

Parquet(parquet)

N S

CSV
(csv)

S N

OCI Object Storage
(object_storage_oci)

JSON
(json)

S S

MongoDB JSON
(mongodb_json)

S N

Parquet(parquet)

N S

CSV
(csv)

S N
AWS S3 (en inglés)

DynamoDB JSON
(dynamodb_json)

S N

Note:

Muchos parámetros de configuración son comunes en la configuración de origen y receptor. Para facilitar la referencia, la descripción de dichos parámetros se repite para cada fuente y fregadero en las secciones de documentación, que explican los formatos de archivo de configuración para varios tipos de fuentes y fregaderos. En todos los casos, la sintaxis y la semántica de los parámetros con el mismo nombre son idénticas.

Seguridad del origen y el receptor

Algunos de los tipos de fuente y receptor tienen información de seguridad opcional u obligatoria para fines de autenticación.

Todos los orígenes y receptores que utilizan servicios de Oracle Cloud Infrastructure (OCI) pueden utilizar determinados parámetros para proporcionar información de seguridad opcional. Esta información se puede proporcionar mediante un archivo de configuración de OCI o un principal de instancia.

Los orígenes y los receptores de Oracle NoSQL Database necesitan información de seguridad obligatoria si la instalación es segura y utiliza una autenticación basada en Oracle Wallet. Esta información se puede proporcionar agregando un archivo jar al directorio <MIGRATOR_HOME>/lib.

Autenticación basada en cartera

Si una instalación de Oracle NoSQL Database utiliza la autenticación basada en Oracle Wallet, debe incluir archivos jar adicionales que formen parte de la instalación de EE. Para obtener más información, consulte Oracle Wallet.

Sin los archivos jar, obtendrá el siguiente mensaje de error:

No se han encontrado kvstore-ee.jar y kvstore-ee-<version>.jar en el directorio lib. Copie kvstore-ee.jar y kvstore-ee-<version>.jar en el directorio lib

Para evitar la excepción mostrada anteriormente, debe copiar los archivos kvstore-ee.jar y kvstore-ee-<version>.jar del paquete del servidor EE en el directorio <MIGRATOR_HOME>/lib. <MIGRATOR_HOME> es el directorio nosql-migrator-M.N.O/ creado mediante la extracción del paquete Oracle NoSQL Database Migrator y M.N.O representa los números release.major.minor del software. Por ejemplo, nosql-migrator-1.1.0/lib.

Note:

La autenticación basada en cartera solo está soportada en Enterprise Edition (EE) de Oracle NoSQL Database.

Identificación con principales de instancia

Los principales de instancia son una función de servicio IAM que permite que las instancias sean actores (o principales) autorizados que puedan realizar acciones en recursos de servicio. Cada una de las instancias informáticas tiene su propia identidad y se autentica con los certificados que tiene agregados.

Oracle NoSQL Database Migrator proporciona una opción para conectarse a una nube NoSQL y a orígenes y receptores de OCI Object Storage mediante la autenticación de principal de instancia. Solo está soportado cuando la herramienta NoSQL Database Migrator se utiliza en una instancia informática de OCI, por ejemplo, la herramienta NoSQL Database Migrator que se ejecuta en una máquina virtual alojada en OCI. Para activar esta función, utilice el atributo useInstancePrincipal del origen de nube NoSQL y del archivo de configuración de receptor. Para obtener más información sobre los parámetros de configuración para diferentes tipos de fuentes y receptores, consulte Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates (Plantillas de configuración de fregadero).

Para obtener más información sobre los principales de la instancia, consulte Llamada a servicios desde una Instancia.

Flujo de trabajo para Oracle NoSQL Database Migrator

Obtenga información sobre los distintos pasos necesarios para utilizar la utilidad Oracle NoSQL Database Migrator para migrar los datos de NoSQL.

El flujo de alto nivel de las tareas implicadas en el uso de NoSQL Database Migrator se muestra en la siguiente figura.

Descargue la utilidad de migración de datos NoSQL

La utilidad Oracle NoSQL Database Migrator se puede descargar de la página Descargas de Oracle NoSQL. Una vez descargado y descomprimido en la máquina, puede acceder al comando runMigrator desde la interfaz de línea de comandos.

Note:

La utilidad Oracle NoSQL Database Migrator requiere la ejecución de Java 11 o versiones posteriores.

Identificar el Origen y el Fregadero

Antes de utilizar el migrator, debe identificar el origen de datos y el receptor. Por ejemplo, si desea migrar una tabla NoSQL de Oracle NoSQL Database local a un archivo con formato JSON, el origen será Oracle NoSQL Database y el receptor será un archivo JSON. Asegúrese de que el Oracle NoSQL Database Migrator soporta el origen y el receptor identificados haciendo referencia a Orígenes y receptores soportados. También es una fase adecuada para decidir el esquema de la tabla NoSQL en el destino o receptor y crearlos.
  • Identificar esquema de tabla de receptor: si el receptor es Oracle NoSQL Database local o en la nube, debe identificar el esquema de la tabla de receptor y asegurarse de que los datos de origen coinciden con el esquema de destino. Si es necesario, utilice transformaciones para asignar los datos de origen a la tabla de receptor.
    • Esquema por defecto: NoSQL Database Migrator proporciona una opción para crear una tabla con el esquema por defecto sin necesidad de predefinir el esquema para la tabla. Esto resulta útil principalmente al cargar archivos de origen JSON en Oracle NoSQL Database.
      Si el origen es un archivo JSON con formato MongoDB, el esquema por defecto de la tabla será el siguiente:
      CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))

      Dónde:

      - tablename = valor proporcionado para el atributo de tabla en la configuración.

      - ID = valor _id de cada documento del archivo de origen JSON exportado mongoDB.

      - DOCUMENT = Para cada documento del archivo exportado mongoDB, el contenido que excluye el campo _id se agrega a la columna DOCUMENT.

      Si el origen es un archivo JSON con formato DynamoDB, el esquema por defecto de la tabla será el siguiente:
      CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, 
      [DDBSortKey_name DDBSortKey_type],DOCUMENT JSON,
      PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))

      Dónde:

      - TABLE_NAME = valor proporcionado para la tabla de receptor en la configuración

      - DDBPartitionKey_name = valor proporcionado para la clave de partición en la configuración

      - DDBPartitionKey_type = valor proporcionado para el tipo de datos de la clave de partición en la configuración

      - DDBSortKey_name = valor proporcionado para la clave de ordenación en la configuración si la hay

      - DDBSortKey_type = valor proporcionado para el tipo de dato de la clave de ordenación en la configuración si existe

      - DOCUMENT = Todos los atributos excepto la partición y la clave de ordenación de un elemento de tabla de base de datos Dynamo agregado a una columna JSON NoSQL

      Si el formato de origen es un archivo CSV, no se admite un esquema por defecto para la tabla de destino. Puede crear un archivo de esquema con una definición de tabla que contenga el mismo número de columnas y tipos de datos que el archivo CSV de origen. Para obtener más información sobre la creación de archivos de esquema, consulte Proporcionar esquema de tabla.

      Para todos los demás orígenes, el esquema por defecto será el siguiente:
      CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))

      Dónde:

      - tablename = valor proporcionado para el atributo de tabla en la configuración.

      - ID = Valor LONG generado automáticamente.

      - DOCUMENT = El registro JSON proporcionado por el origen se agrega a la columna DOCUMENT.

      Note:

      Si el valor _id no se proporciona como cadena en el archivo JSON con formato MongoDB, NoSQL Database Migrator lo convierte en una cadena antes de insertarlo en el esquema por defecto.
  • Proporcionar esquema de tabla: NoSQL Database Migrator permite al origen proporcionar definiciones de esquema para los datos de tabla mediante el atributo schemaInfo. El atributo schemaInfo está disponible en todos los orígenes de datos que no tienen un esquema implícito ya definido. Los almacenes de datos del fregadero pueden elegir cualquiera de las siguientes opciones.
    • Utilice el esquema por defecto definido por el NoSQL Database Migrator.
    • Utilice el esquema proporcionado por el origen.
    • Sustituya el esquema proporcionado por el origen definiendo su propio esquema. Por ejemplo, si desea transformar los datos del esquema de origen en otro esquema, debe sustituir el esquema proporcionado por el origen y utilizar la capacidad de transformación de la herramienta NoSQL Database Migrator.


    El archivo de esquema de tabla, por ejemplo, mytable_schema.ddl puede incluir sentencias DDL de tabla. La herramienta NoSQL Database Migrator ejecuta este archivo de esquema de tabla antes de iniciar la migración. La herramienta de migración no soporta más de una sentencia DDL por línea en el archivo de esquema. Por ejemplo,
    CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))

    Note:

    La migración fallará si la tabla está presente en el receptor y el DDL en schemaPath es diferente de la tabla.
  • Crear tabla de receptor: una vez identificado el esquema de tabla de receptor, cree la tabla de receptor mediante la CLI de administrador o mediante el atributo schemaInfo del archivo de configuración de receptor. Consulte Sink Configuration Templates.

    Note:

    Si el origen es un archivo CSV, cree un archivo con los comandos DDL para el esquema de la tabla de destino. Proporcione la ruta del archivo en el parámetro schemaInfo.schemaPath del archivo de configuración del receptor.

Migración de metadatos de TTL para filas de tabla

El tiempo de actividad (TTL) es un mecanismo que permite hacer caducar automáticamente las filas de la tabla. El TTL se expresa como la cantidad de tiempo que los datos pueden estar activos en la tienda. Los datos que han alcanzado su valor de timeout de caducidad ya no se pueden recuperar y no aparecerán en ninguna estadística de almacén.

Puede elegir incluir los metadatos de TTL para las filas de tabla junto con los datos reales al realizar la migración de tablas de Oracle NoSQL Database. NoSQL Database Migrator proporciona parámetros de configuración para soportar la exportación e importación de metadatos TTL de fila de tabla para los siguientes tipos de origen:

Tabla: Migración de metadatos de TTL

Tipos de Origen Parámetro de configuración de origen Parámetro de configuración de fregadero
Oracle NoSQL Database includeTTL includeTTL
Oracle NoSQL Database Cloud Service includeTTL includeTTL
Archivo JSON con formato DynamoDB ttlAttributeName includeTTL
Archivo JSON con formato DynamoDB almacenado en AWS S3 ttlAttributeName includeTTL

Exportación de metadatos TTL en Oracle NoSQL Database y Oracle NoSQL Database Cloud Service

NoSQL Database Migrator proporciona el parámetro de configuración includeTTL para soportar la exportación de metadatos TTL de la fila de tabla.

Cuando se exporta una tabla, los datos de TTL se exportan para las filas de la tabla que tienen un tiempo de caducidad válido. Si una fila no caduca, el objeto JSON _metadata no se incluye explícitamente en los datos exportados porque su valor de caducidad es siempre 0. NoSQL Database Migrator exporta el tiempo de caducidad de cada fila como el número de milisegundos desde la época de UNIX (1 de enero de 1970). Por ejemplo,
//Row 1
{
    "id" : 1,
    "name" : "xyz",
    "age" : 45,
    "_metadata" : {
        "expiration" : 1629709200000   //Row Expiration time in milliseconds
    }
}

//Row 2
{
    "id" : 2,
    "name" : "abc",
    "age" : 52,
    "_metadata" : {
        "expiration" : 1629709400000   //Row Expiration time in milliseconds
    }
}

//Row 3 No Metadata for below row as it will not expire
{
    "id" : 3,
    "name" : "def",
    "age" : 15
}

Importación de metadatos de TTL

Opcionalmente, puede importar metadatos de TTL mediante el parámetro de configuración includeTTL en la plantilla de configuración del receptor.

El tiempo de referencia predeterminado de la operación de importación es el tiempo actual en milisegundos, obtenido de System.currentTimeMillis(), de la máquina en la que se está ejecutando la herramienta NoSQL Database Migrator. Sin embargo, también puede definir un tiempo de referencia personalizado mediante el parámetro de configuración ttlRelativeDate si desea ampliar el tiempo de caducidad e importar filas que, de lo contrario, vencerían inmediatamente. La extensión se calcula de la siguiente manera y se agrega a la hora de caducidad.

Extended time = expiration time - reference time

La operación de importación maneja los siguientes casos de uso al migrar filas de tabla que contienen metadatos TTL. Estos casos de uso solo son aplicables cuando el parámetro de configuración includeTTL está definido en true.

  • Caso de uso 1: no hay información de metadatos TTL presente en la fila de la tabla de importación.

    Si la fila que desea importar no contiene información de TTL, NoSQL Database Migrator define el TTL=0 para la fila.

  • Caso de uso 2: el valor de TTL de la fila de la tabla de origen ha caducado en relación con el tiempo de referencia cuando se importa la fila de la tabla.

    La fila de la tabla caducada se ignora y no se escribe en el almacén.

  • Caso de uso 3: el valor de TTL de la fila de la tabla de origen no ha caducado en relación con el tiempo de referencia cuando se importa la fila de la tabla.

    La fila de la tabla se importa con un valor TTL. Sin embargo, es posible que el valor de TTL importado no coincida con el valor de TTL exportado original debido a las restricciones de hora y día entero en la clase TimeToLive. Por ejemplo,

    Considere una fila de tabla exportada:
    {
      "id" : 8,
      "name" : "xyz",
      "_metadata" : {
      "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC
      }
    }

    La hora de referencia durante la importación es 1734480000000, que es el miércoles, 18 de diciembre de 2024 a las 12:00:00 a. m.

    Fila de tabla importada
    {
      "id" : 8,
      "name" : "xyz",
      "_metadata" : {
        "ttl" :  1734739200000 //Saturday, December 21, 2024 12:00:00 AM
      }
    }

Importación de metadatos TTL en el archivo JSON con formato DynamoDB y en el archivo JSON con formato DynamoDB almacenado en AWS S3

NoSQL Database Migrator proporciona un parámetro de configuración adicional, ttlAttributeName, para soportar la importación de metadatos de TTL de los elementos de archivo JSON con formato DynamoDB.

Los archivos JSON exportados de DynamoDB incluyen un atributo específico en cada elemento para almacenar el registro de hora de caducidad de TTL. Para importar de manera opcional los valores de TTL de los archivos JSON exportados DynamoDB, debe proporcionar el nombre del atributo específico como valor para el parámetro de configuración ttlAttributeName en los archivos de configuración de origen DynamoDB-Formatted JSON File o DynamoDB-Formatted JSON File almacenados en los archivos de configuración de origen S3 de AWS. Además, debe definir el parámetro de configuración includeTTL en la plantilla de configuración del receptor. Los sumideros válidos son Oracle NoSQL Database y Oracle NoSQL Database Cloud Service. NoSQL Database Migrator almacena información de TTL en el objeto JSON _metadata para el elemento importado.

La operación de importación gestiona los siguientes casos de uso al migrar elementos de tabla de los archivos JSON exportados DynamoDB:
  • Caso de uso 1: el valor del parámetro de configuración ttlAttributeName se define en el nombre de atributo TTL especificado en el archivo JSON exportado DynamoDB.

    NoSQL Database Migrator importa el tiempo de caducidad de este elemento como el número de milisegundos desde la época de UNIX (1 de enero de 1970).

    Por ejemplo, considere un elemento en el archivo JSON exportado DynamoDB:
    {
        "Item": {
            "DeptId": {
                "N": "1"
            },
            "DeptName": {
                "S": "Engineering"
            },
            "ttl": {
                "N": "1734616800"
            }
        }
    }
    En este caso, el atributo ttl especifica el valor de tiempo de actividad del elemento. Si define el parámetro de configuración ttlAttributeName como ttl en el archivo JSON con formato DynamoDB o en el archivo JSON con formato DynamoDB almacenado en el archivo de configuración de origen S3 de AWS, NoSQL Database Migrator importa el tiempo de caducidad del elemento de la siguiente manera:
    {
      "DeptId": 1,
      "document": {
          "DeptName": "Engineering"
        }  
      "_metadata": {
        "expiration": 1734616800000
      }
    }

    Note:

    Puede proporcionar el parámetro de configuración ttlRelativeDate en la plantilla de configuración del receptor como la hora de referencia para calcular la hora de caducidad.
  • Caso de uso 2: se define el valor del parámetro de configuración ttlAttributeName; sin embargo, el valor no existe como atributo en el elemento del archivo JSON exportado DynamoDB.

    NoSQL Database Migrator no importa la información de metadatos de TTL para el elemento proporcionado.

  • Caso de uso 3: el valor del parámetro de configuración ttlAttributeName no coincide con el nombre de atributo en el elemento del archivo JSON exportado DynamoDB.
    NoSQL Database Migrator gestiona la importación de una de las siguientes maneras según la configuración del receptor:
    • Copia el atributo como un campo normal si está configurado para importar mediante el esquema por defecto.
    • Omite el atributo si está configurado para importar mediante un esquema definido por el usuario.

Importación de datos a un receptor con una columna IDENTITY

Puede importar los datos de un origen válido a una tabla de receptor (servicios locales/en la nube) con una columna IDENTITY. La columna IDENTITY se crea como GENERATED SIEMPRE COMO IDENTITY o GENERATED BY DEFAULT AS IDENTITY. Para obtener más información sobre la creación de tablas con una columna IDENTITY, consulte Creating Tables With an IDENTITY Column en la SQL Reference Guide.

Antes de importar los datos, asegúrese de que la tabla de Oracle NoSQL Database en el receptor esté vacía si existe. Si hay datos preexistentes en la tabla de receptor, la migración puede provocar problemas como sobrescribir los datos existentes en la tabla de receptor u omitir los datos de origen durante la importación.

Tabla de fregadero con la columna IDENTITY como GENERATED SIEMPRE AS IDENTITY

Considere una tabla de reducción con la columna IDENTITY creada como GENERATED SIEMPRE AS IDENTITY. La importación de datos depende de si el origen proporciona o no los valores a la columna IDENTITY y al parámetro de transformación ignoreFields en el archivo de configuración.

Por ejemplo, desea importar datos de un origen de archivo JSON a la tabla de Oracle NoSQL Database como receptor. El esquema de la tabla de receptor es:

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))
La utilidad Migrator maneja la migración de datos como se describe en los siguientes casos:
Condición de origen Acción del Usuario Resultado de migración

CASO 1: Los datos de origen no proporcionan un valor para el campo IDENTITY de la tabla de receptores.

Ejemplo: archivo de origen JSON sample_noID.json

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

Cree o genere el archivo de configuración.

Migración de datos correcta. Los valores de la columna IDENTITY se generan automáticamente. Datos migrados en la tabla de receptor de Oracle NoSQL Database migrateID:

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

CASO 2: Los datos de origen proporcionan valores para el campo IDENTITY de la tabla de receptores.

Ejemplo: archivo de origen JSON sampleID.json

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

Cree o genere el archivo de configuración. Proporciona una transformación ignoreFields para la columna ID en la plantilla de configuración de receptor.

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

Migración de datos correcta. Los valores de ID proporcionados se omiten y los valores de columna IDENTITY se generan automáticamente.

Datos migrados en la tabla de receptor de Oracle NoSQL Database migrateID:
{"ID":2003,"name":"John","course":"Computer Science"}
{"ID":2002,"name":"Tony","course":"Electronics"}
{"ID":2001,"name":"Jane","course":"BioTechnology"}

Puede crear/generar el archivo de configuración sin la transformación ignoreFields para la columna IDENTITY.

La migración de datos falla con el siguiente mensaje de error:

"Cannot set value for a generated always identity column".

Para obtener más información sobre los parámetros de configuración de transformación, consulte el tema Plantillas de configuración de transformación.

Tabla de fregadero con la columna IDENTITY como GENERATED BY DEFAULT AS IDENTITY

Considere una tabla de reducción con la columna IDENTITY creada como GENERATED BY DEFAULT AS IDENTITY. La importación de datos depende de si el origen proporciona o no los valores a la columna IDENTITY y al parámetro de transformación ignoreFields.

Por ejemplo, desea importar datos de un origen de archivo JSON a la tabla de Oracle NoSQL Database como receptor. El esquema de la tabla de receptor es:

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))
La utilidad Migrator maneja la migración de datos como se describe en los siguientes casos:
Condición de origen Acción del Usuario Resultado de migración

CASO 1: Los datos de origen no proporcionan un valor para el campo IDENTITY de la tabla de receptores.

Ejemplo: archivo de origen JSON sample_noID.json

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

Cree o genere el archivo de configuración.

Migración de datos correcta. Los valores de la columna IDENTITY se generan automáticamente. Datos migrados en la tabla de receptor de Oracle NoSQL Database migrateID:
{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}

CASO 2: Los datos de origen proporcionan valores para el campo IDENTITY de la tabla de receptor y es un campo Primary Key.

Ejemplo: archivo de origen JSON sampleID.json

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

Cree o genere el archivo de configuración. Proporcione una transformación ignoreFields para la columna de ID en la plantilla de configuración de receptor (Recomendado).

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

Migración de datos correcta. Los valores de ID proporcionados se omiten y los valores de columna IDENTITY se generan automáticamente.

Datos migrados en la tabla de receptor de Oracle NoSQL Database migrateID:
{"ID":1002,"name":"John","course":"Computer Science"}
{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"Tony","course":"Electronics"}

Puede crear/generar el archivo de configuración sin la transformación ignoreFields para la columna IDENTITY.

Migración de datos correcta. Los valores ID proporcionados del origen se copian en la columna ID de la tabla de receptor.

Cuando intenta insertar una fila adicional en la tabla sin proporcionar un valor de ID, el generador de secuencias intenta generar automáticamente el valor de ID. El valor inicial del generador de secuencias es 1. Como resultado, el valor de ID generado puede duplicar potencialmente uno de los valores de ID existentes en la tabla de receptor. Puesto que se trata de una violación de la restricción de clave primaria, se devuelve un error y la fila no se inserta.

Consulte Sequence Generator para obtener más información.

Para evitar la violación de la restricción de clave primaria, el generador de secuencias debe iniciar la secuencia con un valor que no entre en conflicto con los valores de ID existentes en la tabla de receptor. Para utilizar el atributo START WITH para realizar esta modificación, consulte el siguiente ejemplo:

Ejemplo: datos migrados en la tabla de receptor migrateID de Oracle NoSQL Database:
{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}
Para buscar el valor adecuado para que el generador de secuencias lo inserte en la columna de ID, recupere el valor máximo del campo ID mediante la siguiente consulta:
SELECT max(ID) FROM migrateID
Salida:
{"Column_1":3}
El valor máximo de la columna ID en la tabla de receptor es 3. Desea que el generador de secuencias comience a generar los valores de ID más allá de 3 para evitar la duplicación. Actualice el atributo START WITH del generador de secuencias a 4 mediante la siguiente sentencia:
ALTER Table migrateID (MODIFY ID GENERATED BY DEFAULT AS IDENTITY (START WITH 4))

Esto iniciará la secuencia en 4.

Ahora, cuando inserta filas en la tabla de reducción sin proporcionar los valores de ID, el generador de secuencias genera automáticamente los valores de ID a partir de 4, evitando la duplicación de los IDs.

Para obtener más información sobre los parámetros de configuración de transformación, consulte el tema Plantillas de configuración de transformación.

Ejecute el comando runMigrator

El archivo ejecutable runMigrator está disponible en los archivos NoSQL Database Migrator extraídos. Debe instalar Java 11 o una versión superior y bash en el sistema para ejecutar correctamente el comando runMigrator.

Puede ejecutar el comando runMigrator de dos formas:
  1. Mediante la creación del archivo de configuración mediante las opciones de tiempo de ejecución del comando runMigrator, como se muestra a continuación.
    [~]$ ./runMigrator
    configuration file is not provided. Do you want to generate configuration? (y/n)                                                                              
     
    [n]: y
    ...
    ...
    • Al llamar a la utilidad runMigrator, proporciona una serie de opciones de tiempo de ejecución y crea el archivo de configuración en función de las opciones que haya elegido para cada opción.
    • Una vez que la utilidad crea el archivo de configuración, tiene la opción de continuar con la actividad de migración en la misma ejecución o guardar el archivo de configuración para una migración futura.
    • Independientemente de su decisión de continuar o diferir la actividad de migración con el archivo de configuración generado, el archivo estará disponible para ediciones o personalización para cumplir con sus requisitos futuros. Puede utilizar el archivo de configuración personalizado para la migración más adelante.
  2. Mediante la transferencia de un archivo de configuración creado manualmente (en formato JSON) como parámetro de tiempo de ejecución mediante la opción -c o --config. Debe crear el archivo de configuración manualmente antes de ejecutar el comando runMigrator con la opción -c o --config. Para obtener ayuda con los parámetros de configuración de origen y receptor, consulte Referencia de Oracle NoSQL Database Migrator.
    [~]$ ./runMigrator -c </path/to/the/configuration/json/file>

Note:

NoSQL Database Migrator consume unidades de lectura al realizar la exportación de datos de la tabla de Oracle NoSQL Cloud Service a cualquier disco válido.

Progreso de Logging Migrator

La herramienta NoSQL Database Migrator proporciona opciones que permiten imprimir mensajes de rastreo, depuración y progreso en una salida estándar o en un archivo. Esta opción puede ser útil para realizar un seguimiento del progreso de la operación de migración, especialmente para tablas o juegos de datos muy grandes.

  • Niveles de Log

    Para controlar el comportamiento de registro mediante la herramienta NoSQL Database Migrator, transfiera el parámetro --log-level o -l de tiempo de ejecución al comando runMigrator. Puede especificar la cantidad de información de log que desea escribir transfiriendo el valor de nivel de log adecuado.

    $./runMigrator --log-level <loglevel>
    Por ejemplo:
    $./runMigrator --log-level debug

    Tabla: niveles de log soportados para NoSQL Database Migrator

    Nivel de Log Descripción
    Advertencia Imprime errores y advertencias.
    info (por defecto) Imprime el estado de progreso de la migración de datos, como la validación del origen, la validación del receptor, la creación de tablas y el recuento del número de registros de datos migrados.
    debug Permite imprimir información adicional de depuración.
    all Imprime todo. Este nivel activa todos los niveles de registro.
  • Archivo Log:
    Puede especificar el nombre del archivo log mediante el parámetro --log-file o -f. Si --log-file se transfiere como parámetro de tiempo de ejecución al comando runMigrator, NoSQL Database Migrator escribe todos los mensajes de log en el archivo o en la salida estándar.
    $./runMigrator --log-file <log file name>
    Por ejemplo:
    $./runMigrator --log-file nosql_migrator.log

demostraciones de casos de uso para Oracle NoSQL Database Migrator

Descubra cómo realizar la migración de datos con Oracle NoSQL Database Migrator para casos de uso específicos. Puede encontrar instrucciones sistemáticas detalladas con ejemplos de código para realizar la migración en cada uno de los casos de uso.

En este artículo se incluyen los siguientes temas:

Migración de Oracle NoSQL Database Cloud Service a un archivo JSON

En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar datos y la definición de esquema de una tabla NoSQL de Oracle NoSQL Database Cloud Service (NDCS) en un archivo JSON.

Caso de uso

Una organización decide entrenar un modelo mediante los datos de Oracle NoSQL Database Cloud Service (NDCS) para predecir comportamientos futuros y proporcionar recomendaciones personalizadas. Pueden realizar una copia periódica de los datos de las tablas NDCS en un archivo JSON y aplicarla al motor de análisis para analizar y entrenar el modelo. Esto les ayuda a separar las consultas analíticas de las rutas críticas de baja latencia.

Ejemplo

Para la demostración, veamos cómo migrar la definición de datos y esquema de una tabla NoSQL denominada myTable desde NDCS a un archivo JSON.
Requisitos
  • Identifique el origen y el sumidero de la migración.
    • Origen: Oracle NoSQL Database Cloud Service
    • Fregadero: archivo JSON
  • Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración de OCI. Guarde el archivo de configuración en /home/.oci/config. Consulte Adquisición de credenciales.
    [DEFAULT]
    tenancy=ocid1.tenancy.oc1....
    user=ocid1.user.oc1....
    fingerprint= 43:d1:....
    key_file=</fully/qualified/path/to/the/private/key/>
    pass_phrase=<passphrase>
  • Identifique el punto final de región y el nombre del compartimento para Oracle NoSQL Database Cloud Service.
    • punto final: us-phoenix-1
    • compartimento: developers
Procedimiento
Para migrar la definición de datos y esquema de myTable de Oracle NoSQL Database Cloud Service a un archivo JSON:
  1. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator.
  2. Para generar el archivo de configuración mediante el NoSQL Database Migrator, ejecute el comando runMigrator sin ningún parámetro de tiempo de ejecución.
    [~/nosqlMigrator]$./runMigrator
  3. Como no ha proporcionado el archivo de configuración como parámetro de tiempo de ejecución, la utilidad solicita si desea generar la configuración ahora. Escriba y.
    Configuration file is not provided. Do you want to generate
    configuration? (y/n) [n]: y
    
    Generating a configuration file interactively.
    
    
  4. En función de las peticiones de datos de la utilidad, seleccione las opciones para la configuración de origen.
    Enter a location for your config [./migrator-config.json]: /home/<user>/nosqlMigrator/NDCS2JSON
    Select the source: 
    1) nosqldb
    2) nosqldb_cloud
    3) file
    4) object_storage_oci
    5) aws_s3
    #? 2
    
    Configuration for source type=nosqldb_cloud
    Enter endpoint URL or region ID of the Oracle NoSQL Database Cloud: us-phoenix-1
    Select the authentication type: 
    1) credentials_file
    2) instance_principal
    3) delegation_token
    #? 1
    Enter path to the file containing OCI credentials [/home/<user>/.oci/config]:
    Enter the profile name in OCI credentials file [DEFAULT]: 
    Enter the compartment name or id of the table []: developers
    Enter table name: myTable
    Include TTL data? If you select 'yes' TTL of rows will also 
    be included in the exported data.(y/n) [n]: 
    Enter percentage of table read units to be used for migration operation. (1-100) [90]:
    Enter store operation timeout in milliseconds. (1-30000) [5000]:
  5. En función de las indicaciones de la utilidad, seleccione las opciones para la configuración del fregadero.
    Select the sink:
    1) nosqldb
    2) nosqldb_cloud
    3) file
    #? 3
    Configuration for sink type=file
    Enter path to a directory to store JSON data: /home/<user>/nosqlMigrator
    would you like to export data to multiple files for each source?(y/n) [y]: n
    Would you like to store JSON in pretty format? (y/n) [n]: y
    Would you like to migrate the table schema also? (y/n) [y]: y
    Enter path to a file to store table schema: /home/<user>/nosqlMigrator/myTableSchema
  6. En función de las peticiones de datos de la utilidad, seleccione las opciones para las transformaciones de datos de origen. El valor predeterminado es n.
    Would you like to add transformations to source data? (y/n) [n]:
  7. Introduzca su elección para determinar si desea continuar con la migración en caso de que no se pueda migrar ningún registro.
    Would you like to continue migration in case of any record/row is failed to migrate?: (y/n) [n]:
    
  8. La utilidad muestra la configuración generada en la pantalla.
    generated configuration is:
    {
      "source": {
        "type": "nosqldb_cloud",
        "endpoint": "us-phoenix-1",
        "table": "myTable",
        "compartment": "developers",
        "credentials": "/home/<user>/.oci/config",
        "credentialsProfile": "DEFAULT",
        "readUnitsPercent": 90,
        "requestTimeoutMs": 5000
      },
      "sink": {
        "type": "file",
        "format": "json",
        "useMultiFiles" : false,
        "schemaPath": "/home/<user>/nosqlMigrator/myTableSchema",
        "pretty": true,
        "dataPath": "/home/<user>/nosqlMigrator"
      },
      "abortOnError": true,
      "migratorVersion": "1.6.5"
    }
  9. Por último, la utilidad le solicita que elija si desea continuar con la migración con el archivo de configuración generado o no. La opción por defecto es y.

    Note:

    Si selecciona n, puede utilizar el archivo de configuración generado para ejecutar la migración mediante la opción ./runMigrator -c o ./runMigrator --config.
    would you like to run the migration with above configuration?
    If you select no, you can use the generated configuration file to run the migration using
    ./runMigrator --config /home/<user>/nosqlMigrator/NDCS2JSON
    (y/n) [y]:
  10. El NoSQL Database Migrator migra los datos y el esquema de NDCS al archivo JSON.
    Records provided by source=10,Records written to sink=10,Records failed=0,Records skipped=0.
    Elapsed time: 0min 1sec 277ms
    Migration completed.
Validación

Para validar la migración, puede navegar hasta el directorio del receptor especificado y ver el esquema y los datos.

-- Exported myTable Data. JSON files are created in the supplied data path
 
[~/nosqlMigrator]$cat myTable_1_5.json
{
  "id" : 10,
  "document" : {
    "course" : "Computer Science",
    "name" : "Neena",
    "studentid" : 105
  }
}
{
  "id" : 3,
  "document" : {
  "course" : "Computer Science",
    "name" : "John",
    "studentid" : 107
  }
}
{
  "id" : 4,
  "document" : {
    "course" : "Computer Science",
    "name" : "Ruby",
    "studentid" : 100
  }
}
{
  "id" : 6,
  "document" : {
    "course" : "Bio-Technology",
    "name" : "Rekha",
    "studentid" : 104
  }
}
{
  "id" : 7,
  "document" : {
    "course" : "Computer Science",
    "name" : "Ruby",
    "studentid" : 100
  }
}
{
  "id" : 5,
  "document" : {
    "course" : "Journalism",
    "name" : "Rani",
    "studentid" : 106
  }
}
{
  "id" : 8,
  "document" : {
    "course" : "Computer Science",
    "name" : "Tom",
    "studentid" : 103
  }
}
{
  "id" : 9,
  "document" : {
    "course" : "Computer Science",
    "name" : "Peter",
    "studentid" : 109
  }
}
{
  "id" : 1,
  "document" : {
    "course" : "Journalism",
    "name" : "Tracy",
    "studentid" : 110
  }
}
{
  "id" : 2,
  "document" : {
    "course" : "Bio-Technology",
    "name" : "Raja",
    "studentid" : 108
  }
}
-- Exported myTable Schema
 
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))

Migración de Oracle NoSQL Database local a Oracle NoSQL Database Cloud Service

En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar datos y la definición de esquema de una tabla NoSQL de Oracle NoSQL Database a Oracle NoSQL Database Cloud Service (NDCS).

Caso de uso

Como desarrollador, está explorando opciones para evitar la sobrecarga de la gestión de recursos, clusters y recolección de basura para las cargas de trabajo KVStore de la base de datos NoSQL existentes. Como solución, decide migrar las cargas de trabajo locales existentes de KVStore a Oracle NoSQL Database Cloud Service porque NDCS las gestiona automáticamente.

Ejemplo

Para la demostración, veamos cómo migrar la definición de datos y esquema de una tabla NoSQL denominada myTable de la base de datos NoSQL KVStore a NDCS. También utilizaremos este caso de uso para mostrar cómo ejecutar la utilidad runMigrator transfiriendo un archivo de configuración creado previamente.
Requisitos
  • Identifique el origen y el sumidero de la migración.
    • Origen: Oracle NoSQL Database
    • Fregadero: Oracle NoSQL Database Cloud Service
  • Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración de OCI. Guarde el archivo de configuración en /home/.oci/config. Consulte Adquisición de credenciales en Uso de Oracle NoSQL Database Cloud Service.
    [DEFAULT]
    tenancy=ocid1.tenancy.oc1....
    user=ocid1.user.oc1....
    fingerprint= 43:d1:....
    key_file=</fully/qualified/path/to/the/private/key/>
    pass_phrase=<passphrase>
  • Identifique el punto final de región y el nombre del compartimento para Oracle NoSQL Database Cloud Service.
    • punto final: us-phoenix-1
    • compartimento: developers
  • Identifique los siguientes detalles para KVStore local:
    • storeName: kvstore
    • helperHosts: <hostname>:5000
    • tabla: myTable
Procedimiento
Para migrar la definición de datos y esquema de myTable de la base de datos NoSQL KVStore a NDCS:
  1. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y de fregadero identificados. Consulte Source Configuration Templates y Sink Configuration Templates.
    {
      "source" : {
        "type" : "nosqldb",
        "storeName" : "kvstore",
        "helperHosts" : ["<hostname>:5000"],
        "table" : "myTable",
        "requestTimeoutMs" : 5000
      },
      "sink" : {
        "type" : "nosqldb_cloud",
        "endpoint" : "us-phoenix-1",
        "table" : "myTable",
        "compartment" : "developers",
        "schemaInfo" : {
          "schemaPath" : "<complete/path/to/the/JSON/file/with/DDL/commands/for/the/schema/definition>",
          "readUnits" : 100,
          "writeUnits" : 100,
          "storageSize" : 1
        },
        "credentials" : "<complete/path/to/oci/config/file>",
        "credentialsProfile" : "DEFAULT",
        "writeUnitsPercent" : 90,
        "requestTimeoutMs" : 5000
      },
      "abortOnError" : true,
      "migratorVersion" : "1.0.0"
    }
  2. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator.
  3. Ejecute el comando runMigrator transfiriendo el archivo de configuración mediante la opción --config o -c.
    [~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
    
  4. La utilidad continúa con la migración de datos, como se muestra a continuación.
    Records provided by source=10, Records written to sink=10, Records failed=0.
    Elapsed time: 0min 10sec 426ms
    Migration completed.
Validación

Para validar la migración, puede conectarse a la consola de NDCS y verificar que myTable se ha creado con los datos de origen.

Migración del origen de archivo JSON a Oracle NoSQL Database Cloud Service

En este ejemplo se muestra el uso de Oracle NoSQL Database Migrator para copiar datos de un origen de archivo JSON a Oracle NoSQL Database Cloud Service.

Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database Cloud Service como su plataforma de base de datos NoSQL. Dado que el contenido de origen está en formato de archivo JSON, están buscando una forma de migrarlo a Oracle NoSQL Database Cloud Service.

En este ejemplo, aprenderá a migrar los datos de un archivo JSON denominado SampleData.json. Ejecute la utilidad runMigrator transfiriendo un archivo de configuración creado previamente. Si el archivo de configuración no se proporciona como parámetro de tiempo de ejecución, la utilidad runMigrator le solicita que genere la configuración mediante un procedimiento interactivo.

Requisitos
  • Identifique el origen y el sumidero de la migración.
    • Fuente: Archivo de origen JSON.
      SampleData.json es el archivo de origen. Contiene varios documentos JSON con un documento por línea, delimitados por un nuevo carácter de línea.
      {"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-03-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
      {"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-02T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-02T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-02T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
      {"id":7,"val_json":{"array":["a","b","c"],"date":"2023-02-20T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-01-20T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-01-22T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
      {"id":4,"val_json":{"array":["j","k","l"],"date":"2023-02-03T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-03T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-02-03T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
    • Fregadero: Oracle NoSQL Database Cloud Service.
  • Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración. Guarde el archivo de configuración en /home/user/.oci/config. Para obtener más información, consulte Adquisición de credenciales en Uso de Oracle NoSQL Database Cloud Service.
    [DEFAULT]
    tenancy=ocid1.tenancy.oc1....
    user=ocid1.user.oc1....
    fingerprint= 43:d1:....
    region=us-ashburn-1
    key_file=</fully/qualified/path/to/the/private/key/>
    pass_phrase=<passphrase>
  • Identifique el punto final de región y el nombre del compartimento para Oracle NoSQL Database Cloud Service.
    • punto final: us-ashburn-1
    • compartimento: Training-NoSQL
  • Identifique los siguientes detalles para el archivo de origen JSON:
    • schemaPath: <absolute path to the schema definition file containing DDL statements for the NoSQL table at the sink>.

      En este ejemplo, el archivo DDL es schema_json.ddl.
      create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY
          KEY(id));

      Oracle NoSQL Database Migrator proporciona una opción para crear una tabla con el esquema por defecto si no se proporciona schemaPath. Para obtener más información, consulte el tema Identificación del origen y el fregadero en Flujo de trabajo para Oracle NoSQL Database Migrator.

    • Ruta de datos: <absolute path to a file or directory containing the JSON data for migration>.
Procedimiento
Para migrar el archivo de origen JSON de SampleData.json a Oracle NoSQL Database Cloud Service, realice lo siguiente:
  1. Prepare el archivo de configuración (en formato JSON) con el origen identificado y los detalles del receptor. Consulte Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates (Plantillas de configuración de receptor).
    {
      "source" : {
        "type" : "file",
        "format" : "json",
        "schemaInfo" : {
          "schemaPath" : "[~/nosql-migrator-1.5.0]/schema_json.ddl"
        },
        "dataPath" : "[~/nosql-migrator-1.5.0]/SampleData.json"
      },
      "sink" : {
        "type" : "nosqldb_cloud",
        "endpoint" : "us-ashburn-1",
        "table" : "Migrate_JSON",
        "compartment" : "Training-NoSQL",
        "includeTTL" : false,
        "schemaInfo" : {
          "readUnits" : 100,
          "writeUnits" : 60,
          "storageSize" : 1,
          "useSourceSchema" : true
        },
        "credentials" : "/home/user/.oci/config",
        "credentialsProfile" : "DEFAULT",
        "writeUnitsPercent" : 90,
        "overwrite" : true,
        "requestTimeoutMs" : 5000
      },
      "abortOnError" : true,
      "migratorVersion" : "1.5.0"
    }
  2. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad Oracle NoSQL Database Migrator.
  3. Ejecute el comando runMigrator transfiriendo el archivo de configuración mediante la opción --config o -c.
    [~/nosql-migrator-1.5.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. La utilidad continúa con la migración de datos, como se muestra a continuación. La tabla Migrate_JSON se crea en el receptor con el esquema proporcionado en schemaPath.
    creating source from given configuration:
    source creation completed
    creating sink from given configuration:
    sink creation completed
    creating migrator pipeline
    migration started
    [cloud sink] : start loading DDLs
    [cloud sink] : executing DDL: create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id)),limits: [100, 60, 1]
    [cloud sink] : completed loading DDLs
    [cloud sink] : start loading records
    [json file source] : start parsing JSON records from file: SampleData.json
    [INFO] migration completed.
    Records provided by source=4, Records written to sink=4, Records failed=0, Records skipped=0.
    Elapsed time: 0min 5sec 778ms
    Migration completed.
Validación
Para validar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service y verificar que la tabla Migrate_JSON se crea con los datos de origen. Para conocer el procedimiento de acceso a la consola, consulte el artículo sobre acceso al servicio desde la consola de Infrastructure en el documento Oracle NoSQL Database Cloud Service.

Figura - Tablas de la consola de Oracle NoSQL Database Cloud Service



Figura - Datos de la tabla de la consola de Oracle NoSQL Database Cloud Service



Migración de un archivo JSON MongoDB a Oracle NoSQL Database Cloud Service

En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar datos con formato Mongo-DB en Oracle NoSQL Database Cloud Service (NDCS).

Caso de uso

Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database Cloud Service como su plataforma de base de datos NoSQL. Como sus tablas y datos de NoSQL están en MongoDB, buscan una forma de migrar esas tablas y datos a Oracle NDCS.

Puede copiar un archivo o directorio que contenga los datos JSON exportados de MongoDB para la migración especificando el archivo o directorio en la plantilla de configuración de origen.

Un archivo JSON con formato MongoDB de ejemplo es el siguiente:
{"_id":0,"name":"Aimee Zank","scores":[{"score":1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}

MongoDB soporta dos tipos de extensiones en formato JSON de archivos: modo canónico y modo relajado. Puede proporcionar el archivo JSON con formato MongoDB generado mediante la herramienta mongoexport en modo canónico o relajado. Ambos modos están soportados por el NoSQL Database Migrator para la migración.

Para obtener más información sobre el archivo MongoDB Extended JSON (v2), consulte mongoexport_formats.

Para obtener más información sobre la generación del archivo JSON con formato MongoDB, consulte mongoexport.

Ejemplo

Para la demostración, veamos cómo migrar un archivo JSON con formato MongoDB a NDCS. Para este ejemplo, utilizaremos un archivo de configuración creado manualmente.
Requisitos
  • Identifique el origen y el sumidero de la migración.
    • Origen: archivo JSON con formato MongoDB
    • Fregadero: Oracle NoSQL Database Cloud Service
  • Extraiga los datos de Mongo DB mediante la utilidad mongoexport. Consulte mongoexport para obtener más información.
  • Cree una tabla NoSQL en el fregadero con un esquema de tabla que coincida con los datos del archivo JSON con formato Mongo-DB. Como alternativa, puede indicar al NoSQL Database Migrator que cree una tabla con la estructura de esquema por defecto definiendo el atributo defaultSchema en true.

    Note:

    Para un origen MongoDB-Formatted JSON, el esquema por defecto de la tabla será el siguiente:
    CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))
    
    Dónde:
    • tablename = valor de la configuración de la tabla.
    • ID = valor _id del archivo de origen JSON exportado mongoDB.
    • DOCUMENT = todo el contenido del archivo de origen JSON exportado mongoDB se agrega a la columna DOCUMENT, excluyendo el campo _id.
  • Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración de OCI. Guardar el archivo de configuración en /home/.oci/config. Consulte Adquisición de credenciales en Uso de Oracle NoSQL Database Cloud Service.
    [DEFAULT]
    tenancy=ocid1.tenancy.oc1....
    user=ocid1.user.oc1....
    fingerprint= 43:d1:....
    key_file=</fully/qualified/path/to/the/private/key/>
    pass_phrase=<passphrase>
  • Identifique el punto final de región y el nombre del compartimento para Oracle NoSQL Database Cloud Service.
    • punto final: us-phoenix-1
    • compartimento: developers
Procedimiento

Para migrar los datos JSON con formato MongoDB a Oracle NoSQL Database Cloud Service:

  1. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y fregadero identificados. Consulte Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates (Plantillas de configuración de receptor).
    {
      "source" : {
        "type" : "file",
        "format" : "mongodb_json",
        "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
      },
      "sink" : {
        "type" : "nosqldb_cloud",
        "endpoint" : "us-phoenix-1",
        "table" : "mongoImport",
        "compartment" : "developers",
        "schemaInfo" : {
          "defaultSchema" : true,
          "readUnits" : 100,
          "writeUnits" : 60,
          "storageSize" : 1
        },
        "credentials" : "<complete/path/to/the/oci/config/file>",
        "credentialsProfile" : "DEFAULT",
        "writeUnitsPercent" : 90,
        "requestTimeoutMs" : 5000
      },
      "abortOnError" : true,
      "migratorVersion" : "1.0.0"
    }
  2. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator.
  3. Ejecute el comando runMigrator transfiriendo el archivo de configuración mediante la opción --config o -c.
    [~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
    
  4. La utilidad continúa con la migración de datos, como se muestra a continuación.
    Records provided by source=29,353, Records written to sink=29,353, Records failed=0.
    Elapsed time: 9min 9sec 630ms
    Migration completed.
Validación

Para validar la migración, puede conectarse a la consola de NDCS y verificar que myTable se ha creado con los datos de origen.

Migración del archivo JSON DynamoDB a Oracle NoSQL Database

En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar el archivo JSON DynamoDB en NoSQL Database.

Caso de uso:

Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database en la base de datos DynamoDB. La organización desea migrar sus tablas y datos de DynamoDB a Oracle NoSQL Database (local).

Consulte Asignación de la tabla DynamoDB a la tabla NoSQL de Oracle para obtener más información.

Puede migrar un archivo o directorio que contenga los datos JSON exportados de DynamoDB desde un sistema de archivos especificando la ruta en la plantilla de configuración de origen.

Un archivo JSON con formato DynamoDB de ejemplo es el siguiente:
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}

Copie los datos de la tabla DynamoDB exportada del almacenamiento S3 de AWS en un sistema de archivos montado local.

Por ejemplo:

Para esta demostración, aprenderá a migrar un archivo JSON DynamoDB a Oracle NoSQL Database (local). Para este ejemplo, utilizará un archivo de configuración creado manualmente.

Requisitos

  • Identifique el origen y el sumidero de la migración.
    • Origen: DynamoDB JSON File
    • Sink: Oracle NoSQL Database (local)
  • Para importar datos de la tabla DynamoDB a Oracle NoSQL Database, primero debe exportar la tabla DynamoDB a S3. Consulte los pasos proporcionados en Exportación de datos de tabla DynamoDB a Amazon S3 para exportar la tabla. Durante la exportación, seleccione el formato como DynamoDB JSON. Los datos exportados contienen datos de tabla DynamoDB en varios archivos gzip, como se muestra a continuación.
    / 01639372501551-bb4dd8c3 
    |-- 01639372501551-bb4dd8c3 ==> exported data prefix
    |----data
    |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data
    |----manifest-files.json
    |----manifest-files.md5
    |----manifest-summary.json
    |----manifest-summary.md5
    |----_started
  • Debe descargar los archivos de AWS S3. La estructura de los archivos después de la descarga será como se muestra a continuación.
    download-dir/01639372501551-bb4dd8c3     
    |----data    
    |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data   
    |----manifest-files.json   
    |----manifest-files.md5   
    |----manifest-summary.json   
    |----manifest-summary.md5   
    |----_started

Procedimiento

Para migrar los datos JSON DynamoDB a Oracle NoSQL Database:
  1. Prepare el archivo de configuración (en formato JSON) con los detalles del origen y del receptor identificados. Para obtener detalles, consulte Source Configuration Templates y Sink Configuration Templates.

    Note:

    Si los elementos de tabla JSON exportados de DynamoDB contienen el atributo TTL, para importar opcionalmente los valores de TTL, especifique el atributo en el parámetro de configuración ttlAttributeName de la plantilla de configuración de origen y defina el parámetro de configuración includeTTL en true en la plantilla de configuración del receptor.
    Puede seleccionar una de estas dos opciones.
    • Opción 1: importación de la tabla DynamoDB como documento JSON mediante la configuración del esquema por defecto.

      Aquí, definirá el parámetro de configuración defaultSchema en true. Por lo tanto, NoSQL Database Migrator crea el esquema por defecto en el receptor. Debe especificar el tipo de columna DDBPartitionKey y el tipo de columna NoSQL correspondiente. De lo contrario, se muestra un error.

      Para obtener más información sobre el esquema por defecto para un origen de JSON exportado DynamoDB, consulte el tema Identificación del origen y el fregadero en Flujo de trabajo para Oracle NoSQL Database Migrator.
      {
        "source" : {
          "type" : "file",
          "format" : "dynamodb_json",
          "ttlAttributeName" : "ttl",
          "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>"
        },
        "sink" : {
          "type" : "nosqldb",
          "storeName" : "kvstore",
          "helperHosts" : ["<hostname>:5000"],
          "table" : "sampledynDBImp",
          "includeTTL" : true,
          "schemaInfo" : {
            "DDBPartitionKey" : "Id:INTEGER",
            "defaultSchema" : true
          },
          "overwrite" : true,
          "requestTimeoutMs" : 5000
        },
        "abortOnError" : true,
        "migratorVersion" : "1.6.5"
      }
      En este ejemplo se utiliza el siguiente esquema por defecto:
      CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
    • Opción 2: importación de la tabla DynamoDB como columnas fijas mediante un archivo de esquema proporcionado por el usuario.

      Aquí, definirá el parámetro de configuración defaultSchema en false. Por lo tanto, especifique el archivo que contiene la sentencia DDL de la tabla del receptor en el parámetro schemaPath. Consulte Asignación de tipos DynamoDB a tipos NoSQL de Oracle para obtener más información.

      En este ejemplo se utiliza el siguiente esquema definido por el usuario:
      CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))

      NoSQL Database Migrator utiliza el archivo de esquema para crear la tabla en el receptor como parte de la migración. Siempre que se proporcionen los datos de clave primaria, se insertará el registro JSON de entrada. De lo contrario, se muestra un error.

      Note:

      • Si la tabla de base de datos Dynamo tiene un tipo de dato no soportado en NoSQL Database, la migración falla.
      • Si los datos de entrada no contienen un valor para una columna concreta (que no sea la clave primaria), se utilizará el valor por defecto de la columna. El valor por defecto debe formar parte de la definición de columna al crear la tabla. Por ejemplo, id INTEGER not null default 0. Si la columna no tiene una definición por defecto, se inserta SQL NULL si no se proporcionan valores para la columna.
      • Si está modelando la tabla DynamoDB como documento JSON, asegúrese de utilizar la transformación AggregateFields para agregar datos de clave no primaria a una columna JSON. Para obtener detalles, consulte aggregateFields.
      {
        "source" : {
          "type" : "file",
          "format" : "dynamodb_json",
          "ttlAttributeName" : "ttl",
          "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>"
        },
        "sink" : {
          "type" : "nosqldb",
          "storeName" : "kvstore",
          "helperHosts" : ["<hostname>:5000"],
          "table" : "sampledynDBImp",
          "includeTTL" : true,
          "schemaInfo" : {
            "schemaPath" : "<full path of the schema file with the DDL statement>"
          },
          "overwrite" : true,
          "requestTimeoutMs" : 5000
        },
        "transforms": {
          "aggregateFields" : {
            "fieldName" : "document",
            "skipFields" : ["Id"]
          }
        },
        "abortOnError" : true,
        "migratorVersion" : "1.6.5"
      }
  2. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator.
  3. Ejecute el comando runMigrator transfiriendo archivos de configuración independientes para las opciones 1 y 2. Utilice la opción --config o -c.
    ./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. La utilidad continúa con la migración de datos, como se muestra en el siguiente ejemplo:
    [INFO] creating source from given configuration:
    [INFO] source creation completed
    [INFO] creating sink from given configuration:
    [INFO] sink creation completed
    [INFO] creating migrator pipeline
    [INFO] [nosqldb sink] : start loading DDLs
    [INFO] [nosqldb sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
    [INFO] [nosqldb sink] : completed loading DDLs
    [INFO] migration started
    [INFO] Start writing data to OnDB Sink
    [INFO] executing for source:DynamoSample
    [INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz
    [INFO] Writing data to OnDB Sink completed.
    [INFO] migration completed.
    Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
    Elapsed time: 0min 0sec 45ms
    Migration completed.

Validación

Inicie la petición de datos SQL en el almacén de datos.
 java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
Verifique que la nueva tabla se crea con los datos de origen:
SELECT * FROM sampledynDBImp

Salida

Observe que la información de TTL se incluye en el objeto JSON _metadata para cada elemento importado.
{"Id":102,"document":{"Address":{"City":"Wales","DoorNum":1024,"Street":"32 main","Zip":560014},"Age":48,"FavColors":["Blue"],"FavNumbers":[10],"FirstName":"John","LastName":"White","Phones":[["222-222"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}
{"Id":101,"document":{"Address":{"City":"London","DoorNum":201,"Street":"21 main","Zip":570004},"Age":22,"FavColors":["Red","Green"],"FavNumbers":[10],"FirstName":"Fred","LastName":"Smith","Phones":[["555-222","123-567"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}

Migración del archivo JSON DynamoDB en AWS S3 a Oracle NoSQL Database Cloud Service

En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar el archivo JSON DynamoDB almacenado en un almacén S3 de AWS en Oracle NoSQL Database Cloud Service (NDCS).

Caso de uso:

Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database Cloud Service con una base de datos DynamoDB. La organización desea migrar sus tablas y datos de DynamoDB a Oracle NoSQL Database Cloud Service.

Consulte Asignación de la tabla DynamoDB a la tabla NoSQL de Oracle para obtener más información.

Puede migrar un archivo que contenga los datos JSON exportados de DynamoDB desde el almacenamiento S3 de AWS especificando la ruta en la plantilla de configuración de origen.

Un archivo JSON con formato DynamoDB de ejemplo es el siguiente:
{"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"}}}

La tabla DynamoDB se exporta al almacenamiento S3 de AWS como se especifica en Exportación de datos de tabla DynamoDB a Amazon S3.

Por ejemplo:

Para esta demostración, aprenderá a migrar un archivo JSON DynamoDB en un origen S3 de AWS a NDCS. Para este ejemplo, utilizará un archivo de configuración creado manualmente.

Requisitos

  • Identifique el origen y el sumidero de la migración.
    • Origen: DynamoDB JSON File en AWS S3
    • Disipador: Oracle NoSQL Database Cloud Service
  • Identifique la tabla de AWS DynamoDB que se debe migrar a NDCS. Inicie sesión en la consola de AWS con sus credenciales. Vaya a DynamoDB. En Tablas, seleccione la tabla que desea migrar.
  • Cree un cubo de objeto y exporte la tabla a S3. Desde la consola de AWS, vaya a S3. En cubos, cree un nuevo cubo de objeto. Vuelva a DynamoDB y haga clic en Exportaciones a S3. Proporcione la tabla de origen y el cubo S3 de destino y haga clic en Exportar.
    Consulte los pasos proporcionados en Exportación de datos de la tabla DynamoDB a Amazon S3 para exportar la tabla. Durante la exportación, seleccione el formato como DynamoDB JSON. Los datos exportados contienen datos de la tabla DynamoDB en varios archivos gzip, como se muestra a continuación.
    / 01639372501551-bb4dd8c3 
    |-- 01639372501551-bb4dd8c3 ==> exported data prefix
    |----data
    |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data
    |----manifest-files.json
    |----manifest-files.md5
    |----manifest-summary.json
    |----manifest-summary.md5
    |----_started
  • Necesita credenciales aws (incluidos el ID de clave de acceso y la clave de acceso secreta) y archivos de configuración (credenciales y, opcionalmente, configuración) para acceder a AWS S3 desde el migrator. Consulte Set and view configuration settings para obtener más información sobre los archivos de configuración. Consulte Creación de un par de claves para obtener más información sobre la creación de claves de acceso.
  • Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración de OCI. Guarde el archivo de configuración en el directorio .oci del directorio raíz (~/.oci/config). Consulte Consulta de credenciales para obtener más información.
    [DEFAULT]              
    tenancy=ocid1.tenancy.oc1....         
    user=ocid1.user.oc1....         
    fingerprint= 43:d1:....         
    key_file=</fully/qualified/path/to/the/private/key/>              
    pass_phrase=<passphrase>
  • Identifique el punto final de la región y el nombre del compartimento para Oracle NoSQL Database. Por ejemplo,
    • punto final: us-phoenix-1
    • compartimento: desarrolladores

Procedimiento

Para migrar los datos JSON de DynamoDB a Oracle NoSQL Database:
  1. Prepare el archivo de configuración (en formato JSON) con los detalles del origen y del receptor identificados. Para obtener detalles, consulte Source Configuration Templates y Sink Configuration Templates.

    Note:

    Si los elementos del archivo JSON DynamoDB de AWS S3 contienen el atributo TTL, para importar opcionalmente los valores de TTL, especifique el atributo en el parámetro de configuración ttlAttributeName de la plantilla de configuración de origen y defina el parámetro de configuración includeTTL en true en la plantilla de configuración del receptor. Para obtener más información, consulte Migración de metadatos TTL para filas de tabla.
    Puede seleccionar una de estas dos opciones.
    • Opción 1: importación de la tabla DynamoDB como documento JSON mediante la configuración del esquema por defecto.
      Aquí, defaultSchema es TRUE y, por lo tanto, el migrador crea el esquema por defecto en el fregadero. Debe especificar el tipo de columna DDBPartitionKey y el tipo de columna NoSQL correspondiente. De lo contrario, se devuelve un error.
      {
       "source" : {
         "type" : "aws_s3",
         "format" : "dynamodb_json",
         "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>",
         "credentials" : "</path/to/aws/credentials/file>",
         "credentialsProfile" : <"profile name in aws credentials file">
       },
       "sink" : {
         "type" : "nosqldb_cloud",
         "endpoint" : "<region_name>",
         "table" : "<table_name>",
         "compartment" : "<compartment_name>",
         "schemaInfo" : {
            "defaultSchema" : true,
            "readUnits" : 100,
            "writeUnits" : 60,
            "DDBPartitionKey" : "<PrimaryKey:Datatype>",
            "storageSize" : 1
         },
         "credentials" : "<complete/path/to/the/oci/config/file>",
         "credentialsProfile" : "DEFAULT",
         "writeUnitsPercent" : 90,
         "requestTimeoutMs" : 5000
       },
       "abortOnError" : true,
       "migratorVersion" : "1.6.5"
      }
      Para un origen JSON DynamoDB, el esquema por defecto de la tabla será el que se muestra a continuación:
      CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, 
      [DDBSortKey_name DDBSortKey_type], DOCUMENT JSON, 
      PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))

      Dónde

      TABLE_NAME = valor proporcionado para la 'tabla' del receptor en la configuración

      DDBPartitionKey_name = valor proporcionado para la clave de partición en la configuración

      DDBPartitionKey_type = valor proporcionado para el tipo de datos de la clave de partición en la configuración

      DDBSortKey_name = valor proporcionado para la clave de ordenación en la configuración si la hay

      DDBSortKey_type = valor proporcionado para el tipo de dato de la clave de ordenación en la configuración si existe

      DOCUMENT = Todos los atributos excepto la partición y la clave de ordenación de un elemento de tabla de base de datos de Dynamo agregado a una columna JSON NoSQL

    • Opción 2: importación de la tabla DynamoDB como columnas fijas mediante un archivo de esquema proporcionado por el usuario.
      Aquí, defaultSchema es FALSE y se especifica schemaPath como un archivo que contiene la sentencia DDL. Para obtener más información, consulte Asignación de tipos DynamoDB a tipos NoSQL de Oracle para obtener más información.

      Note:

      Si la tabla de base de datos Dynamo tiene un tipo de datos que no está soportado en NoSQL, la migración falla.
      Un ejemplo de archivo de esquema se muestra a continuación.
      CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, 
      PRIMARY KEY(SHARD(AccountId)));
      El archivo de esquema se utiliza para crear la tabla en el receptor como parte de la migración. Siempre que se proporcionen los datos de clave primaria, se insertará el registro JSON de entrada; de lo contrario, se devolverá un error.

      Note:

      • Si los datos de entrada no contienen un valor para una columna concreta (que no sea la clave primaria), se utilizará el valor por defecto de la columna. El valor por defecto debe formar parte de la definición de columna al crear la tabla. Por ejemplo, id INTEGER not null default 0. Si la columna no tiene una definición por defecto, se inserta SQL NULL si no se proporcionan valores para la columna.
      • Si está modelando la tabla DynamoDB como documento JSON, asegúrese de utilizar la transformación AggregateFields para agregar datos de clave no primaria a una columna JSON. Para obtener detalles, consulte aggregateFields.
      {
       "source" : {
         "type" : "aws_s3",
         "format" : "dynamodb_json",
         "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>",
         "credentials" : "</path/to/aws/credentials/file>",
         "credentialsProfile" : <"profile name in aws credentials file">
       },
       "sink" : {
         "type" : "nosqldb_cloud",
         "endpoint" : "<region_name>",
         "table" : "<table_name>",
         "compartment" : "<compartment_name>",
         "schemaInfo" : {
            "defaultSchema" : false,
            "readUnits" : 100,
            "writeUnits" : 60,
            "schemaPath" : "<full path of the schema file with the DDL statement>",
            "storageSize" : 1
         },
         "credentials" : "<complete/path/to/the/oci/config/file>",
         "credentialsProfile" : "DEFAULT",
         "writeUnitsPercent" : 90,
         "requestTimeoutMs" : 5000
       },
        "transforms": {
          "aggregateFields" : {
            "fieldName" : "document",
            "skipFields" : ["AccountId"]
          }
        },
       "abortOnError" : true,
       "migratorVersion" : "1.6.5"
      }
  2. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad Database Migrator NoSQL.
  3. Ejecute el comando runMigrator transfiriendo el archivo de configuración mediante la opción --config o -c.
    [~/nosqlMigrator]$./runMigrator 
    --config <complete/path/to/the/JSON/config/file>
  4. La utilidad continúa con la migración de datos, como se muestra a continuación.
    Records provided by source=7..,
    Records written to sink=7,
    Records failed=0,
    Records skipped=0.
    Elapsed time: 0 min 2sec 50ms
    Migration completed.

Validación

Puede conectarse a la consola de NDCS y verificar que la nueva tabla se ha creado con los datos de origen.

Migre entre regiones de Oracle NoSQL Database Cloud Service

En este ejemplo se muestra el uso de Oracle NoSQL Database Migrator para realizar la migración entre regiones.

Ejemplo

Una organización utiliza Oracle NoSQL Database Cloud Service para almacenar y gestionar sus datos. Decide replicar datos de una región existente en una región más reciente para realizar pruebas antes de que se pueda iniciar la nueva región para el entorno de producción.

En este caso de uso, aprenderá a utilizar el NoSQL Database Migrator para copiar datos de la tabla user_data de la región Ashburn en la región Phoenix.

Ejecute la utilidad runMigrator transfiriendo un archivo de configuración creado previamente. Si no proporciona el archivo de configuración como parámetro de tiempo de ejecución, la utilidad runMigrator le solicita que genere la configuración mediante un procedimiento interactivo.

Requisitos
  • Descargue Oracle NoSQL Database Migrator de la página Descargas de Oracle NoSQL y extraiga el contenido de su máquina. Para obtener más información, consulte Flujo de trabajo para Oracle NoSQL Database Migrator.
  • Identifique el origen y el sumidero de la migración.
    • Origen: tabla user_data en la región Ashburn.
      La tabla user_data incluye los siguientes datos:
      {"id":40,"firstName":"Joanna","lastName":"Smith","otherNames":[{"first":"Joanna","last":"Smart"}],"age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085},"connections":[70,30,40],"email":"joanna.smith123@reachmail.com","communityService":"**"}
      
      {"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"Good"},{"first":"Johny2","last":"Brave"},{"first":"Johny3","last":"Kind"},{"first":"Johny4","last":"Humble"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"email":"john.smith@reachmail.com","communityService":"****"}
      
      {"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"BeGood"}],"age":22,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"email":"jane.smith201@reachmail.com","communityService":"*****"}
      
      {"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"BeGood"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"email":"adam.smith201reachmail.com","communityService":"***"}
      Identifique el punto final de región o el punto final de servicio y el nombre de compartimento para el origen.
      • punto final: us-ashburn-1
      • compartimento: ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
    • Fregadero: tabla user_data en la región Phoenix.
      Identifique el punto final de región o el punto final de servicio y el nombre del compartimento para el receptor.
      • punto final: us-phoenix-1
      • compartimento: ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma

      Identificar el esquema de la tabla de receptor.

      Puede utilizar el mismo nombre de tabla y esquema que la tabla de origen. Para obtener información sobre otras opciones de esquema, consulte el tema Identificación del origen y el fregadero en Flujo de trabajo para Oracle NoSQL Database Migrator

  • Identifique sus credenciales de OCI en la nube para ambas regiones y capturelas en el archivo de configuración. Guarde el archivo de configuración en la máquina en la ubicación /home/<user>/.oci/config. Para obtener más información, consulte Adquisición de credenciales.

Note:

  • Si las regiones están en arrendamientos diferentes, debe proporcionar perfiles diferentes en el archivo /home/<user>/.oci/config con las credenciales de nube de OCI adecuadas para cada uno de ellos.
  • Si las regiones están en el mismo arrendamiento, puede tener un único perfil en el archivo /home/<user>/.oci/config.

En este ejemplo, las regiones están en arrendamientos diferentes. El perfil DEFAULT incluye credenciales de OCI para la región Ashburn y DEFAULT2 incluye credenciales de OCI para la región Phoenix.

En el parámetro endpoint del archivo de configuración del migrator (tanto plantillas de configuración de origen como de receptor), puede proporcionar la URL de punto final de servicio o el ID de región de las regiones. Para obtener la lista de regiones de datos soportadas para Oracle NoSQL Database Cloud Service y sus URL de punto final de servicio, consulte Regiones de datos y URL de servicio asociadas en el documento Oracle NoSQL Database Cloud Service.
[DEFAULT]
user=ocid1.user.oc1....
fingerprint=fd:96:....
tenancy=ocid1.tenancy.oc1....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=abcd


[DEFAULT2]
user=ocid1.user.oc1....
fingerprint=1b:68:....
tenancy=ocid1.tenancy.oc1....
region=us-phoenix-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=23456
Procedimiento
Para migrar la tabla user_data de la región Ashburn a la región Phoenix, realice lo siguiente:
  1. Prepare el archivo de configuración (en formato JSON) con el origen identificado y los detalles del receptor. Consulte Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates (Plantillas de configuración de receptor).
    {
      "source" : {
        "type" : "nosqldb_cloud",
        "endpoint" : "us-ashburn-1",
        "table" : "user_data",
        "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
        "credentials" : "/home/<user>/.oci/config",
        "credentialsProfile" : "DEFAULT",
        "readUnitsPercent" : 100,
        "includeTTL" : false,
        "requestTimeoutMs" : 5000
      },
      "sink" : {
        "type" : "nosqldb_cloud",
        "endpoint" : "us-phoenix-1",
        "table" : "user_data",
        "compartment" : "ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma",
        "includeTTL" : false,
        "schemaInfo" : {
          "readUnits" : 100,
          "writeUnits" : 60,
          "storageSize" : 1,
          "useSourceSchema" : true
        },
        "credentials" : "/home/<user>/.oci/config",
        "credentialsProfile" : "DEFAULT2",
        "writeUnitsPercent" : 90,
        "overwrite" : true,
        "requestTimeoutMs" : 5000
      },
      "abortOnError" : true,
      "migratorVersion" : "1.5.0"
    }
  2. En la máquina, navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator. Puede acceder al comando runMigrator desde la interfaz de línea de comandos.
  3. Ejecute el comando runMigrator transfiriendo el archivo de configuración mediante la opción --config o -c.
    [~/nosql-migrator-1.5.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. La utilidad continúa con la migración de datos, como se muestra a continuación. La tabla user_data se crea en el receptor con el mismo esquema que la tabla de origen, ya que ha configurado el parámetro useSourceSchema como verdadero en la plantilla de configuración del receptor.
    creating source from given configuration:
    source creation completed
    creating sink from given configuration:
    sink creation completed
    creating migrator pipeline
    migration started
    [cloud sink] : start loading DDLs
    [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS user_data (id INTEGER, firstName STRING, lastName STRING, otherNames ARRAY(RECORD(first STRING, last STRING)), age INTEGER, income INTEGER, address JSON, connections ARRAY(INTEGER), email STRING, communityService STRING, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
    [cloud sink] : completed loading DDLs
    [cloud sink] : start loading records
    migration completed.
    Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
    Elapsed time: 0min 5sec 603ms
    Migration completed.

    Note:

    • Si la tabla ya existe en el receptor con el mismo esquema que la tabla de origen, las filas con las mismas claves primarias se sobrescriben, ya que ha proporcionado el parámetro overwrite como verdadero en la plantilla de configuración.
    • Si la tabla ya existe en el receptor con un esquema diferente al de la tabla de origen, la migración fallará.
Validación

Para validar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service en la región Phoenix. Verifique que los datos de origen de la tabla user_data de la región Ashburn se copian en la tabla user_data de esta región. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure.

Migre de Oracle NoSQL Database Cloud Service a OCI Object Storage

En este ejemplo se muestra el uso de Oracle NoSQL Database Migrator desde Cloud Shell.

Caso de uso

Una empresa emergente planea utilizar Oracle NoSQL Database Cloud Service como su solución de almacenamiento de datos. La compañía desea utilizar Oracle NoSQL Database Migrator para copiar datos de una tabla de Oracle NoSQL Database Cloud Service en OCI Object Storage para realizar copias de seguridad periódicas de sus datos. Como medida rentable, desean ejecutar la utilidad NoSQL Database Migrator desde Cloud Shell, a la que pueden acceder todos los usuarios de OCI.

En este caso de uso, aprenderá a copiar la utilidad NoSQL Database Migrator a Cloud Shell en la región suscrita y a realizar una migración de datos. Puede migrar los datos de origen de la tabla de Oracle NoSQL Database Cloud Service a un archivo JSON en OCI Object Storage.

Ejecute la utilidad runMigrator transfiriendo un archivo de configuración creado previamente. Si no proporciona el archivo de configuración como parámetro de tiempo de ejecución, la utilidad runMigrator le solicita que genere la configuración mediante un procedimiento interactivo.

Requisitos
  • Descargue Oracle NoSQL Database Migrator de la página Descargas de Oracle NoSQL en su máquina local.
  • Inicie Cloud Shell desde el menú Herramientas de desarrollador de la consola en la nube. El explorador web abre el directorio de inicio. Haga clic en el menú de Cloud Shell en la esquina superior derecha de la ventana de Cloud Shell y seleccione la opción de carga en la lista desplegable. En la ventana emergente, arrastre y suelte el paquete de Oracle NoSQL Database Migrator desde la máquina local o haga clic en la opción Seleccionar de la computadora, seleccione el paquete de la máquina local y haga clic en el botón Cargar. También puede arrastrar y soltar el paquete Oracle NoSQL Database Migrator directamente desde la máquina local al directorio raíz de Cloud Shell. Extraiga el contenido del paquete.
  • Identifique el origen y el receptor de la copia de seguridad.
    • Origen: tabla NDCSupload en la región Oracle NoSQL Database Cloud Service Ashburn.

      Para la demostración, tenga en cuenta los siguientes datos en la tabla NDCSupload:
      {"id":1,"name":"Jane Smith","email":"iamjane@somemail.co.us","age":30,"income":30000.0}
      {"id":2,"name":"Adam Smith","email":"adam.smith@mymail.com","age":25,"income":25000.0}
      {"id":3,"name":"Jennifer Smith","email":"jenny1_smith@mymail.com","age":35,"income":35000.0}
      {"id":4,"name":"Noelle Smith","email":"noel21@somemail.co.us","age":40,"income":40000.0} 
      

      Identifique el punto final y el ID de compartimento para el origen. Para el punto final, puede proporcionar el identificador de región o el punto final de servicio. Para obtener la lista de regiones de datos soportadas en Oracle NoSQL Database Cloud Service, consulte Regiones de datos y URL de servicio asociadas.

      • punto final: us-ashburn-1
      • ID de compartimento: ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
    • Sink: archivo JSON en el cubo de OCI Object Storage.

      Identifique el punto final de región, el espacio de nombres, el cubo y el prefijo para OCI Object Storage. Para obtener más información, consulte Acceso a Oracle Cloud Object Storage. Para obtener una lista de los puntos finales del servicio OCI Object Storage, consulte Puntos finales de Object Storage.

      • punto final: us-ashburn-1
      • cubo: Migrate_oci
      • prefijo: Delegation
      • espacio de nombres: <> Si no proporciona un espacio de nombres, la utilidad utiliza el espacio de nombres por defecto del arrendamiento.

      Note:

      Si el cubo de almacenamiento de objetos está en un compartimento diferente, asegúrese de que tiene los privilegios para escribir objetos en el cubo. Para obtener más información sobre la configuración de las políticas, consulte Escritura de objetos en Object Storage.
Procedimiento
Para realizar una copia de seguridad de la tabla NDCSupload de Oracle NoSQL Database Cloud Service en un archivo JSON en el cubo de OCI Object Storage mediante Cloud Shell, realice lo siguiente:
  1. Prepare el archivo de configuración (en formato JSON) con el origen identificado y los detalles del receptor. Consulte Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates (Plantillas de configuración de receptor). Asegúrese de definir el parámetro useDelegationToken en true en las plantillas de configuración de origen y receptor.
    En este caso de uso se utiliza la siguiente plantilla de configuración:
    {
      "source" : {
        "type" : "nosqldb_cloud",
        "endpoint" : "us-ashburn-1",
        "table" : "NDCSupload",
        "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
        "useDelegationToken" : true,
        "readUnitsPercent" : 90,
        "includeTTL" : true,
        "requestTimeoutMs" : 5000
      },
      "sink" : {
        "type" : "object_storage_oci",
        "format" : "json",
        "endpoint" : "us-ashburn-1",
        "namespace" : "",
        "bucket" : "Migrate_oci",
        "prefix" : "Delegation",
        "chunkSize" : 32,
        "compression" : "",
        "useDelegationToken" : true
      },
      "abortOnError" : true,
      "migratorVersion" : "1.6.0"
    }
  2. En Cloud Shell, vaya al directorio donde extrajo la utilidad NoSQL Database Migrator.
  3. Ejecute el comando runMigrator transfiriendo el archivo de configuración mediante la opción --config o -c
    [~/nosql-migrator-1.6.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. La utilidad NoSQL Database Migrator continúa con la migración de datos. Como ha definido el parámetro useDelegationToken en true, Cloud Shell se autentica automáticamente mediante el token de delegación al ejecutar la utilidad NoSQL Database Migrator. El NoSQL Database Migrator copia los datos de la tabla NDCSupload en un archivo JSON del cubo de Object Storage Migrate_oci. Consulte los logs para obtener una copia de seguridad de datos correcta.
    [INFO] creating source from given configuration:
    [INFO] source creation completed
    [INFO] creating sink from given configuration:
    [INFO] sink creation completed
    [INFO] creating migrator pipeline
    [INFO] migration started
    [INFO] [OCI OS sink] : writing table schema to Delegation/Schema/schema.ddl
    [INFO] [OCI OS sink] : start writing records with prefix Delegation
    [INFO] migration completed.
    Records provided by source=4,Records written to sink=4,Records failed=0.
    Elapsed time: 0min 0sec 486ms
    Migration completed.

    Note:

    Los datos se copian en el archivo: Migrate_oci/NDCSupload/Delegation/Data/000000.json

    Según el parámetro chunkSize de la plantilla de configuración de receptor, los datos de origen se pueden dividir en varios archivos JSON en el mismo directorio.

    El esquema se copia en el archivo: Migrate_oci/NDCStable1/Delegation/Schema/schema.ddl

Validación

Para validar la copia de seguridad de datos, conéctese a la consola de Oracle NoSQL Database Cloud Service. Navegue por los menús, Storage > Object Storage & Archive Storage > Buckets. Acceda a los archivos desde el directorio NDCSupload/Delegation en el cubo Migrate_oci. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure.

Migración de OCI Object Storage a Oracle NoSQL Database Cloud Service mediante la autenticación de OKE

En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator con la autenticación de identidad de carga de trabajo de OKE para copiar datos de un archivo JSON en la tabla OCI Object Storage a Oracle NoSQL Database Cloud Service.

Casos prácticos

Como desarrollador, está explorando una opción para restaurar datos de un archivo JSON en el cubo de OCI Object Storage (SO OCI) a la tabla de Oracle NoSQL Database Cloud Service (NDCS) mediante NoSQL Database Migrator en una aplicación en contenedores. Una aplicación en contenedores es un entorno virtualizado que agrupa la aplicación y todas sus dependencias (como bibliotecas, binarios y archivos de configuración) en un paquete. Esto permite que la aplicación se ejecute de forma consistente en los distintos entornos, independientemente de la infraestructura subyacente.

Desea ejecutar NoSQL Database Migrator en un pod de Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). Para acceder de forma segura a los servicios del sistema operativo OCI y NDCS desde el pod de OKE, utilizará el método de autenticación de identidad de carga de trabajo (WIA).

En esta demostración, creará una imagen de docker para el NoSQL Database Migrator, copiará la imagen en un repositorio de Container Registry, creará un cluster de OKE y desplegará la imagen del migrador en el pod de cluster de OKE para ejecutar la utilidad Migrator. Aquí, proporcionará un archivo de configuración de NoSQL Database Migrator creado manualmente para ejecutar la utilidad Migrator como una aplicación en contenedores.

Requisitos
  • Identifique el origen y el sumidero de la migración.
    • Origen: archivo de esquema y archivos JSON en el cubo del sistema operativo OCI.
      Identifique el punto final de región, el espacio de nombres, el cubo y el prefijo del cubo del sistema operativo OCI en el que están disponibles los archivos JSON y el esquema de origen. Para obtener más información, consulte Acceso al almacenamiento de objetos de Oracle Cloud. Para obtener la lista de puntos finales del servicio del sistema operativo OCI, consulte Puntos finales de Object Storage.
      • punto final: us-ashburn-1
      • cubo: Migrate_oci
      • prefijo: userSession
      • espacio de nombres: idhkv1iewjzj
        El nombre del espacio de nombres de un cubo es el mismo que el espacio de nombres de su arrendamiento y se genera automáticamente cuando se crea su arrendamiento. Puede obtener el nombre del espacio de nombres de la siguiente manera:
        • En la consola de Oracle NoSQL Database Cloud Service, vaya a Almacenamiento> Cubos.
        • Seleccione Compartimento en Ámbito de lista y seleccione el cubo. La página Detalles de cubo muestra el nombre en el parámetro Espacio de nombres.

        Si no proporciona un nombre de espacio de nombres del sistema operativo OCI, la utilidad Migrator utiliza el espacio de nombres por defecto del arrendamiento.

    • Fregadero: tabla users en Oracle NoSQL Database Cloud Service.

      Identifique el punto final de región o el punto final de servicio y el nombre del compartimento para el fregadero:

      • punto final: us-ashburn-1
      • compartimento: ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma

      Identifique el esquema de tabla de receptor:

      Para utilizar el nombre de tabla y el esquema almacenados en el cubo del sistema operativo OCI, defina el parámetro useSourceSchema en true. Para obtener más información sobre otras opciones de esquema, consulte el tema Identificar el origen y el fregadero en Flujo de trabajo para el migrador de Oracle NoSQL Database.

      Note:

      Asegúrese de tener los privilegios de escritura en el compartimento en el que va a restaurar los datos en la tabla de NDCS. Para obtener más información, consulte Gestión de compartimentos.
  • Prepare una imagen de Docker para el NoSQL Database Migrator y muévala a Container Registry.
    1. Obtenga el espacio de nombres del arrendamiento desde la consola de OCI.

      Conéctese a la consola de Oracle NoSQL Database Cloud Service. En la barra de navegación, seleccione el menú Perfil y, a continuación, seleccione Arrendamiento: <Nombre de Tenany>.

      Copie el nombre del espacio de nombres de Object Storage, que es el espacio de nombres de arrendamiento, en el portapapeles.

    2. Cree una imagen de Docker para la utilidad Migrator.
      Navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator. El paquete Migrator incluye un archivo docker denominado Dockerfile. Desde una interfaz de comandos, utilice el siguiente comando para crear una imagen de Docker de la utilidad Migrator:
      #Command:
      docker build -t nosqlmigrator:<tag> .
      #Example:
      docker build -t nosqlmigrator:1.0 .
      Puede especificar un identificador de versión para la imagen de Docker en la opción tag. Compruebe la imagen de Docker mediante el comando:
      #Command:
      Docker images
      #Example output
      ------------------------------------------------------------------------------------------
      
      REPOSITORY                 TAG          IMAGE ID         CREATED         SIZE
      localhost/nosqlmigrator    1.0          e1dcec27a5cc     10 seconds ago  487 MB
      quay.io/podman/hello       latest       83fc7ce1224f     10 months ago   580 kB
      docker.io/library/openjdk  17-jdk-slim  8a3a2ffec52a     2 years ago     406 MB
      
      ------------------------------------------------------------------------------------------
    3. Genere un token de autorización.

      Necesita un token de autenticación para conectarse a Container Registry y almacenar la imagen de Docker del migrador. Si aún no tiene un token de autenticación, debe generar uno. Para obtener más información, consulte Obtención de un token de autenticación.

    4. Almacene la imagen de Docker del migrador en Container Registry.

      Para acceder a la imagen de Docker del migrador desde el pod de Kubernetes, debe almacenar la imagen en cualquier registro público o privado. Por ejemplo, Docker, Artifact Hub, OCI Container Registry, etc. son algunos registros. En esta demostración, se utiliza Container Registry. Para obtener más información, consulte Visión general de Container Registry.

      1. Desde la consola de OCI, cree un repositorio en Container Registry. Para obtener más información, consulte Creación de un repositorio.

        Para esta demostración, cree el repositorio okemigrator.

      2. Inicie sesión en Container Registry desde la interfaz de comandos con el siguiente comando:
        #Command:
        docker login <region-key>.ocir.io -u <tenancy-namespace>/<user name>password: <Auth token>
        #Example:
        docker login iad.ocir.io -u idhx..xxwjzj/rx..xxxxh@oracle.com
        password: <Auth token>
        #Output:
        Login Succeeded!

        En el comando anterior,

        region-key: especifica la clave para la región en la que está utilizando Container Registry. Para obtener más información, consulte Disponibilidad por región.

        tenancy-namespace: especifica el espacio de nombres de arrendamiento que ha copiado de la consola de OCI.

        user name: especifica el nombre de usuario de la consola de OCI.

        password: especifica el token de autenticación.

      3. Etiquete y transfiera la imagen de Docker del migrador a Container Registry mediante los siguientes comandos:
        #Command:
        docker tag <Migrator Docker image> <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>
        docker push <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>
        #Example:
        docker tag localhost/nosqlmigrator:1.0 iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
        docker push iad.ocir.io/idhx..xxwjzj/okemigrator:1.0

        En el comando anterior,

        repo: especifica el nombre del repositorio que ha creado en Container Registry.

        tag: especifica el identificador de versión para la imagen de Docker.

        #Output:
        Getting image source signatures
        Copying blob 0994dbbf9a1b done   | 
        Copying blob 37849399aca1 done   | 
        Copying blob 5f70bf18a086 done   | 
        Copying blob 2f263e87cb11 done   | 
        Copying blob f941f90e71a8 done   | 
        Copying blob c82e5bf37b8a done   | 
        Copying blob 2ad58b3543c5 done   | 
        Copying blob 409bec9cdb8b done   | 
        Copying config e1dcec27a5 done   | 
        Writing manifest to image destination
  • Configurar un cluster de OKE con WIA a NDCS y OCI OS.
    1. Crear un clúster de Kubernetes mediante OKE.

      Desde la consola de OCI, defina y cree un cluster de Kubernetes basado en la disponibilidad de los recursos de red mediante OKE. Necesita un cluster de Kubernetes para ejecutar la utilidad Migrator como una aplicación en contenedores. Para obtener más información sobre la creación de clusters, consulte Creación de clusters de Kubernetes mediante flujos de trabajo de consola.

      Para esta demostración, puede crear un cluster gestionado de un solo nodo mediante el flujo de trabajo Creación rápida que se detalla en el enlace anterior.

      Figura - Cluster de Kubernetes para el contenedor del migrador



    2. Configure WIA desde la consola de OCI para acceder a otros recursos de OCI desde el cluster de Kubernetes.

      Para otorgar acceso a la utilidad Migrator al cubo del sistema operativo NDCS y OCI mientras se ejecuta desde los pods de cluster de Kubernetes, debe configurar WIA. Realice los siguientes pasos:

      1. Configure el archivo de configuración kubeconfig del cluster.
        • Desde la consola de OCI, abra el cluster de Kubernetes que ha creado y haga clic en el botón Acceder a cluster.
        • En el cuadro de diálogo Acceso al cluster, haga clic en Acceso a Cloud Shell.
        • Haga clic en Iniciar Cloud Shell para mostrar la ventana de Cloud Shell.
        • Ejecute el comando de interfaz de línea de comandos de Oracle Cloud Infrastructure para configurar el archivo kubeconfig Puede copiar el comando desde el cuadro de diálogo Access Your Cluster. Puede esperar la siguiente salida:
          #Example:  
          oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aaa...muqzq --file $HOME/.kube/config --region us-ashburn-1 --token-version 2.0.0  --kube-endpoint PUBLIC_ENDPOINT
          #Output:
          New config written to the Kubeconfig file /home/<user>/.kube/config
      2. Copie el OCID del cluster de la opción cluster-id del comando anterior y guárdelo para utilizarlo en otros pasos.
        ocid1.cluster.oc1.iad.aaa...muqzq
      3. Cree un espacio de nombres para la cuenta de servicio de Kubernetes mediante el siguiente comando en la ventana de Cloud Shell:
        #Command:
        kubectl create namespace <namespace-name>
        #Example:
        kubectl create namespace migrator
        #Output:
        namespace/migrator created
      4. Cree una cuenta de servicio de Kubernetes para la aplicación Migrator en un espacio de nombres mediante el siguiente comando en la ventana de Cloud Shell:
        #Command:
        kubectl create serviceaccount <service-account-name> --namespace <namespace-name>
        #Example:
        kubectl create serviceaccount migratorsa --namespace migrator
        #Output:
        serviceaccount/migratorsa created
      5. Defina una política de IAM desde la consola de OCI para permitir que la carga de trabajo acceda a los recursos de OCI desde el cluster de Kubernetes.

        Desde la consola de OCI, navegue por los menús Identidad y seguridad > Identidad > Políticas. Cree las siguientes políticas para permitir el acceso a los recursos nosql-family y object-family. Utilice el OCID del cluster, el espacio de nombres y los valores de cuenta de servicio de los pasos anteriores.

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

        Para obtener más información sobre la creación de políticas, consulte Uso de la consola para crear políticas.

Procedimiento

Para migrar del archivo JSON del cubo del sistema operativo OCI a la tabla NDCS, realice lo siguiente desde la ventana de Cloud Shell:

  1. Prepare un archivo de configuración del migrador, migrator-config.json con el origen del sistema operativo OCI y el receptor NDCS. Para las plantillas, consulte Source Configuration Templates y Sink Configuration Templates.

    Para utilizar OKE WIA para acceder al cubo del sistema operativo OCI y a NDCS, defina el parámetro useOKEWorkloadIdentity en true en las plantillas de configuración de origen y de receptor. Aquí, utilizará el esquema de origen del archivo DDL de esquema en el cubo del sistema operativo OCI. Por lo tanto, defina el parámetro useSourceSchema en true en la plantilla de configuración de fregadero.

    Note:

    Al utilizar OKE WIA, no puede generar el archivo de configuración del migrador de manera interactiva. Debe preparar el archivo de configuración manualmente haciendo referencia a las plantillas de configuración de origen y receptor.
    {
      "source" : {
        "type" : "object_storage_oci",
        "format" : "json",
        "endpoint" : "us-ashburn-1",
        "namespace" : "",
        "bucket" : "Migrate_oci",
        "prefix" : "userSession",
        "useOKEWorkloadIdentity" : true
      },
      "sink" : {
        "type" : "nosqldb_cloud",
        "endpoint" : "us-ashburn-1",
        "table" : "users",
        "compartment" : "Training-NoSQL",
        "includeTTL" : true,
        "schemaInfo" : {
          "readUnits" : 100,
          "writeUnits" : 60,
          "storageSize" : 1,
          "useSourceSchema" : true
        },
        "useOKEWorkloadIdentity" : true,
        "writeUnitsPercent" : 90,
        "overwrite" : true,
        "requestTimeoutMs" : 5000
      },
      "abortOnError" : true,
      "migratorVersion" : "1.7.0"
    }
  2. Cree un recurso de asignación de configuración (configmap) para transferir el archivo de entrada de configuración migrator-config.json al contenedor Migrator en tiempo de ejecución en el pod de Kubernetes. El mapa de configuración monta el archivo de configuración del migrador en el sistema de archivos del contenedor como un volumen de montaje.
    #Command:
    kubectl create configmap oci-migrator-config --from-file=<Migrator configuration file> -n <namespace-name>
    #Example:
    kubectl create configmap oci-migrator-config --from-file=migrator-config.json -n migrator
    #Output:
    configmap/oci-migrator-config created
  3. Cree un secreto de registro de Docker que incluya las credenciales de OCI que se utilizarán al extraer la imagen de Docker del migrador de Container Registry al pod de Kubernetes.
    #Command:
    kubectl create secret docker-registry ocirsecret --docker-server=<region-key>.ocir.io --docker-username='tenancy-namespace/username' --docker-password='auth token' --docker-email='<user Email>' -n <namespace-name>
    #Example:
    kubectl create secret docker-registry ocirsecret --docker-server=iad.ocir.io --docker-username='idhx..xxwjzj/rx..xxxxh@oracle.com' --docker-password='<Auth token>' --docker-email='rx..xxxxh@oracle.com' -n migrator
    #Output:
    secret/ocirsecret created
  4. Cree un archivo de manifiesto, que utilizará para especificar la imagen de Docker del migrador. Asegúrese de proporcionar los valores de los pasos anteriores para el espacio de nombres, el nombre de la cuenta de servicio de Kubernetes, el nombre de imagen de Docker, el secreto de registro de Docker y el mapa de configuración. Puede consultar el siguiente archivo de manifiesto de ejemplo:
    #migrator-deployment.yaml
    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: nosql-migrator
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nosql-migrator
      template:
        metadata:
          labels:
            app: nosql-migrator
        spec:
          serviceAccountName: migratorsa
          automountServiceAccountToken: true
          containers:
            - name: nosqlmigrator
              image: iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
              imagePullPolicy: Always
              args: ["--config", "/config/migrator-config.json", "--log-level", "DEBUG"]
              volumeMounts:
                - name: config-volume
                  mountPath: /config  # Mount the file here
          imagePullSecrets:
            - name: ocirsecret
          volumes:
            - name: config-volume
              configMap:
                name: oci-migrator-config
    
  5. Desplegue la imagen de Docker del migrador en el pod de Kubernetes mediante el siguiente comando. OKE ejecuta la utilidad Migrator en un contenedor en uno de los nodos del cluster de Kubernetes.
    #Command:
    kubectl create -f <manifest file> -n <namespace-name>
    #Example:
    kubectl create -f migrator-deployment.yaml -n migrator
    #Output:
    deployment.apps/nosql-migrator created
  6. Puede comprobar los logs mediante los siguientes comandos:
    1. Recupere el nombre del pod en el que se ejecuta la utilidad Migrator.
      #Command:
      kubectl get pods -n <namespace-name>
      #Example:
      kubectl get pods -n migrator
      #Output:
      NAME                            READY   STATUS    RESTARTS   AGE
      nosql-migrator-ccdbf549-6sjjg   1/1     Running   0          56s
    2. Utilice el nombre del pod para recuperar los logs del migrador.
      #Command:
      kubectl logs -f <kubernetes cluster pod name> -n <namespace-name>
      #Example:
      kubectl logs -f nosql-migrator-ccdbf549-6sjjg -n migrator
      #Output:
      SLF4J(I): Connected with provider of type [org.apache.logging.slf4j.SLF4JServiceProvider]
      [INFO] Configuration for migration:
      {
        "source" : {
          "type" : "object_storage_oci",
          "format" : "json",
          "endpoint" : "us-ashburn-1",
          "namespace" : "idhkv1iewjzj",
          "bucket" : "Migrate_oci",
          "prefix" : "userSession",
          "useOKEWorkloadIdentity" : true
        },
        "sink" : {
          "type" : "nosqldb_cloud",
          "endpoint" : "us-ashburn-1",
          "table" : "users",
          "compartment" : "Training-NoSQL",
          "includeTTL" : true,
          "schemaInfo" : {
            "readUnits" : 100,
            "writeUnits" : 60,
            "storageSize" : 1,
            "useSourceSchema" : true
          },
          "useOKEWorkloadIdentity" : true,
          "writeUnitsPercent" : 90,
          "overwrite" : true,
          "requestTimeoutMs" : 5000
        },
        "abortOnError" : true,
        "migratorVersion" : "1.7.0"
      }
      [INFO] creating source from given configuration:
      [INFO] source creation completed
      [INFO] creating sink from given configuration:
      [INFO] sink creation completed
      [INFO] creating migrator pipeline
      [INFO] migration started
      [INFO] [cloud sink] : start loading DDLs
      [INFO] [cloud sink] : completed loading DDLs
      [INFO] [cloud sink] : start loading records
      [INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_1_5_0.json
      [INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_6_10_0.json
      [INFO] migration completed.
      Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
      Elapsed time: 0min 1sec 15ms
      Migration completed.
      

    Note:

    Puede ejecutar de forma iterativa la migración de datos de la siguiente manera:

    1. Suprima el contenedor nosql-migrator con el siguiente comando:
      #Command:
      kubectl delete -f <manifest file> -n <namespace-name>
      #Example:
      kubectl delete -f migrator-deployment.yaml -n migrator
      #Output:
      deployment.apps "nosql-migrator" deleted
    2. Actualice el archivo de entrada de configuración migrator-config.json.
    3. Suprima y vuelva a crear el mapa de configuración con los comandos del paso 2.

      No es necesario crear el secreto de registro de Docker y el archivo de manifiesto de nuevo.

    4. Despliegue la imagen de Docker del migrador en el pod de Kubernetes mediante el archivo de manifiesto (paso 5).
Verificación

Para verificar la restauración de datos, conéctese a la consola de Oracle NoSQL Database Cloud Service. En la barra de navegación, vaya a Bases de datos > NoSQL Database. Seleccione el compartimento en la lista desplegable para ver la tabla users. Para conocer el procedimiento para acceder a la consola, consulte Acceso al servicio desde la consola de Infrastructure.

Migración de Oracle NoSQL Database a OCI Object Storage mediante la autenticación de token de sesión

En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator con autenticación de token de sesión para copiar datos de la tabla de Oracle NoSQL Database a un archivo JSON en un cubo de OCI Object Storage.

Casos prácticos

Como desarrollador, está explorando una opción para realizar una copia de seguridad de los datos de la tabla de Oracle NoSQL Database en OCI Object Storage (sistema operativo OCI). Desea utilizar la autenticación basada en token de sesión.

En esta demostración, utilizará los comandos de la interfaz de línea de comandos (CLI) de OCI para crear un token de sesión. Creará manualmente un archivo de configuración del migrador y realizará la migración de datos.

Requisitos
  • Identifique el origen y el receptor de la migración.
    • Origen: tabla users en Oracle NoSQL Database.
    • Fregadero: archivo JSON en el cubo del sistema operativo OCI

      Identifique el punto final, el espacio de nombres, el cubo y el prefijo de la región para el sistema operativo OCI. Para obtener más información, consulte Acceso al almacenamiento de objetos de Oracle Cloud. Para obtener la lista de puntos finales del servicio del sistema operativo OCI, consulte Puntos finales de Object Storage.

      • punto final: us-ashburn-1
      • cubo: Migrate_oci
      • prefijo: userSession
      • espacio de nombres: idhkv1iewjzj
        El nombre del espacio de nombres de un cubo es el mismo que el espacio de nombres de su arrendamiento y se genera automáticamente cuando se crea su arrendamiento. Puede obtener el nombre del espacio de nombres de la siguiente manera:
        • En la consola de Oracle NoSQL Database Cloud Service, vaya a Almacenamiento> Cubos.
        • Seleccione Compartimento en Ámbito de lista y seleccione el cubo. La página Detalles de cubo muestra el nombre en el parámetro Espacio de nombres.

        Si no proporciona un nombre de espacio de nombres del sistema operativo OCI, la utilidad Migrator utiliza el espacio de nombres por defecto del arrendamiento.

      Note:

      Asegúrese de que tiene privilegios para escribir objetos en el cubo del sistema operativo OCI. Para obtener más información sobre la configuración de las políticas, consulte Escritura en Object Storage.
  • Genere un token de sesión siguiendo estos pasos:
    • Instalar y configurar OCI CLI. Consulte Inicio rápido.
    • Utilice uno de los siguientes comandos de la CLI de OCI para generar un token de sesión. Para obtener más información sobre las opciones disponibles, consulte Autenticación basada en token para la CLI.
      #Create a session token using OCI CLI from a web browser:
      oci session authenticate --region <region_name> --profile-name <profile_name>
      #Example:
      oci session authenticate --region us-ashburn-1 --profile-name SESSIONPROFILE

      o

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

      En el comando anterior,

      region_name: especifica el punto final de región para el sistema operativo OCI. Para obtener una lista de las regiones de datos soportadas en Oracle NoSQL Database Cloud Service, consulte Regiones de datos y URL de servicio asociadas.

      profile_name: especifica el perfil que utiliza el comando de la CLI de OCI para generar un token de sesión.

      El comando de la CLI de OCI crea una entrada en el archivo de configuración de OCI en la ruta de acceso $HOME/.oci/config, como se muestra en el siguiente ejemplo:
      [SESSIONPROFILE]
      fingerprint=f1:e9:b7:e6:25:ff:fe:05:71:be:e8:aa:cc:3d:0d:23
      key_file=$HOME/.oci/sessions/SESSIONPROFILE/oci_api_key.pem
      tenancy=ocid1.tenancy.oc1..aaaaa ... d6zjq
      region=us-ashburn-1
      security_token_file=$HOME/.oci/sessions/SESSIONPROFILE/token
      

      security_token_file apunta a la ruta del token de sesión que ha generado mediante el comando de la CLI de OCI anterior.

      Note:

      • Si el perfil ya existe en el archivo de configuración de OCI, el comando de la CLI de OCI sobrescribe el perfil con la configuración relacionada con el token de sesión al generar el token de sesión.
      • Especifique lo siguiente en la plantilla de configuración de fregadero:
        • Ruta de acceso al archivo de configuración de OCI del parámetro credentials.
        • Perfil utilizado al generar el token de sesión en el parámetro credentialsProfile.
        "credentials" : "$HOME/.oci/config"
        "credentialsProfile" : "SESSIONPROFILE"

        La utilidad Migrator recupera automáticamente los detalles del token de sesión generado mediante los parámetros anteriores. Si no especifica el parámetro credentials, la utilidad Migrator busca el archivo de credenciales en la ruta de acceso $HOME/.oci. Si no especifica el parámetro credentialsProfile, la utilidad Migrator utiliza el nombre de perfil por defecto (DEFAULT) del archivo de configuración de OCI.

      • El token de sesión es válido durante 60 minutos. Para ampliar la duración de la sesión, puede refrescar la sesión. Para obtener más información, consulte Refrescamiento de un token.
Procedimiento

Para migrar de la tabla de Oracle NoSQL Database a un archivo JSON en el cubo del sistema operativo OCI:

  1. Prepare el archivo de configuración (en formato JSON) con el origen de Oracle NoSQL Database y el archivo JSON en el fregadero del cubo del sistema operativo OCI. Para obtener información sobre las plantillas, consulte Source Configuration Templates y Sink Configuration Templates.
    Para utilizar la autenticación del token de sesión para acceder al cubo del sistema operativo OCI, defina el parámetro useSessionToken en true en la plantilla de configuración de fregadero. En consecuencia, especifique la ruta de configuración en el parámetro credentials y el nombre de perfil en el parámetro credentialsProfile.
    {
      "source" : {
        "type" : "nosqldb",
        "storeName" : "kvstore",
        "helperHosts" : ["<hostname>:<port>"],
        "table" : "users",
        "includeTTL" : true,
        "requestTimeoutMs" : 5000
      },
      "sink" : {
        "type" : "object_storage_oci",
        "format" : "json",
        "endpoint" : "us-ashburn-1",
        "namespace" : "idhkv1iewjzj",
        "bucket" : "Migrate_oci",
        "prefix" : "userSession",
        "chunkSize" : 32,
        "compression" : "",
        "useSessionToken" : true,
        "credentials" : "$/home/.oci/config",
        "credentialsProfile" : "SESSIONPROFILE"
      },
      "abortOnError" : true,
      "migratorVersion" : "<latest>"
    }
  2. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator.
  3. Ejecute el comando runMigrator transfiriendo la opción de archivo de configuración. Utilice la opción --config o -c para transferir el archivo de configuración de la siguiente manera:
    ./runMigrator --config ./migrator-config.json
  4. La utilidad Migrator continúa con la migración de datos. A continuación se muestra un ejemplo de salida.
    Con el parámetro useSessionToken en true, la utilidad Migrator se autentica automáticamente mediante el token de sesión. La utilidad Migrator copia los datos de la tabla users en un archivo JSON del cubo del sistema operativo OCI denominado Migrate_oci. Consulte los logs para obtener una copia de seguridad de datos correcta.
    [INFO] creating source from given configuration:
    [INFO] source creation completed
    [INFO] creating sink from given configuration:
    [INFO] sink creation completed
    [INFO] creating migrator pipeline
    [INFO] [OCI OS sink] : writing table schema to userSession/Schema/schema.ddl
    [INFO] migration started
    [INFO] Migration success for source users_6_10. read=2,written=2,failed=0
    [INFO] Migration success for source users_1_5. read=3,written=3,failed=0
    [INFO] Migration is successful for all the sources.
    [INFO] migration completed.
    Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
    Elapsed time: 0min 0sec 982ms
    Migration completed.
    

    Note:

    Según el parámetro chunkSize de la plantilla de configuración del fregadero, la utilidad Migrator divide los datos de origen en varios archivos JSON del mismo directorio. En este ejemplo, la utilidad Migrator copia datos en archivos users_1_5_0.json y users_6_10_0.json en el directorio Migrate_oci/userSession/Data.

    El esquema de la tabla de origen se copia en el archivo schema.ddl del directorio Migrate_oci/userSession/Schema.

Verificación

Para verificar la copia de seguridad de los datos, conéctese a la consola de Oracle NoSQL Database Cloud Service. Navegue por los menús, Storage > Object Storage & Archive Storage > Buckets. Acceda a los archivos desde el directorio userSession en el cubo Migrate_oci. Para conocer el procedimiento para acceder a la consola, consulte Acceso al servicio desde la consola de Infrastructure

Migración de un archivo CSV a Oracle NoSQL Database

En este ejemplo se muestra el uso de Oracle NoSQL Database Migrator para copiar datos de un archivo CSV en Oracle NoSQL Database.

Ejemplo

Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database como su plataforma de base de datos NoSQL. Dado que el contenido de origen está en formato de archivo CSV, están buscando una forma de migrarlo a Oracle NoSQL Database.

En este ejemplo, aprenderá a migrar los datos de un archivo CSV denominado course.csv, que contiene información sobre varios cursos ofrecidos por una universidad. El archivo de configuración se genera desde la utilidad runMigrator.

También puede preparar el archivo de configuración con los detalles de origen y receptor identificados. Consulte Oracle NoSQL Database Migrator Reference.

Requisitos
  • Identifique el origen y el receptor de la migración.
    • Fuente: Archivo CSV

      En este ejemplo, el archivo de origen es course.csv

      
      cat [~/nosql-migrator-1.5.0]/course.csv
      1,"Computer Science", "San Francisco", "2500"
      2,"Bio-Technology", "Los Angeles", "1200"
      3,"Journalism", "Las Vegas", "1500"
      4,"Telecommunication", "San Francisco", "2500"
      
    • Fregadero: Oracle NoSQL Database
  • El archivo CSV debe tener el formato RFC4180.
  • Cree un archivo que contenga los comandos DDL para el esquema de la tabla de destino, course. La definición de tabla debe coincidir con el archivo de datos CSV relativo al número de columnas y sus tipos.

    En este ejemplo, el archivo DDL es mytable_schema.ddl

    
    cat [~/nosql-migrator-1.5.0]/mytable_schema.ddl
    create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
    
Procedimiento
Para migrar los datos del archivo CSV de course.csv a Oracle NoSQL Database Service, realice los siguientes pasos:
  1. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad Oracle NoSQL Database Migrator.
  2. Para generar el archivo de configuración mediante Oracle NoSQL Database Migrator, ejecute el comando runMigrator sin ningún parámetro de tiempo de ejecución.
    [~/nosql-migrator-1.5.0]$./runMigrator
  3. Como no ha proporcionado el archivo de configuración como parámetro de tiempo de ejecución, la utilidad solicita si desea generar la configuración ahora. Escriba y.
    Puede seleccionar una ubicación para el archivo de configuración o conservar la ubicación por defecto pulsando Enter key.
    
    Configuration file is not provided. Do you want to generate
    configuration? (y/n) [n]: y
    Generating a configuration file interactively.
    
    Enter a location for your config [./migrator-config.json]: 
    ./migrator-config.json already exist. Do you want to overwrite?(y/n) [n]: y
    
  4. En función de las peticiones de datos de la utilidad, seleccione las opciones para la configuración de origen.
    
    Select the source: 
    1) nosqldb
    2) nosqldb_cloud
    3) file
    4) object_storage_oci
    5) aws_s3
    #? 3
    
    Configuration for source type=file
    Select the source file format: 
    1) json
    2) mongodb_json
    3) dynamodb_json
    4) csv
    #? 4
    
  5. Proporcione la ruta al archivo CSV de origen. Además, según las peticiones de datos de la utilidad, puede optar por reordenar los nombres de columna, seleccionar el método de codificación y recortar los espacios de cola de la tabla de destino.
    
    Enter path to a file or directory containing csv data: [~/nosql-migrator-1.5.0]/course.csv
    Does the CSV file contain a headerLine? (y/n) [n]: n
    Do you want to reorder the column names of NoSQL table with respect to
    CSV file columns? (y/n) [n]: n
    Provide the CSV file encoding. The supported encodings are:
    UTF-8,UTF-16,US-ASCII,ISO-8859-1. [UTF-8]: 
    Do you want to trim the tailing spaces? (y/n) [n]: n
    
  6. En función de las indicaciones de la utilidad, seleccione las opciones para la configuración del fregadero.
    
    Select the sink:
    1) nosqldb
    2) nosqldb_cloud
    #? 1
    Configuration for sink type=nosqldb
    Enter store name of the Oracle NoSQL Database: mystore
    Enter comma separated list of host:port of Oracle NoSQL Database: <hostname>:5000
    
  7. Según las peticiones de datos de la utilidad, proporcione el nombre de la tabla de destino.
    
    Enter fully qualified table name: course
    
  8. Introduzca su elección para definir el valor de TTL. El valor predeterminado es n.
    
    Include TTL data? If you select 'yes' TTL value provided by the
    source will be set on imported rows. (y/n) [n]: n
    
  9. En función de las peticiones de datos de la utilidad, especifique si la tabla de destino se debe crear o no mediante la herramienta Oracle NoSQL Database Migrator. Si la tabla ya se ha creado, se recomienda proporcionar n. Si no se crea la tabla, la utilidad solicitará la ruta del archivo que contiene los comandos DDL para el esquema de la tabla de destino.
    
    Would you like to create table as part of migration process?
    Use this option if you want to create table through the migration tool.
    If you select yes, you will be asked to provide a file that contains
    table DDL or to use schema provided by the source or default schema.
    (y/n) [n]: y
    Enter path to a file containing table DDL: [~/nosql-migrator-1.5.0]/mytable_schema.ddl
    Is the store secured? (y/n) [y]: n
    would you like to overwrite records which are already present?
    If you select 'no' records with same primary key will be skipped [y/n] [y]: y
    Enter store operation timeout in milliseconds. [5000]:
    Would you like to add transformations to source data? (y/n) [n]: n
    
  10. Introduzca su elección para determinar si desea continuar con la migración en caso de que no se pueda migrar ningún registro.
    
    Would you like to continue migration if any data fails to be migrated? 
    (y/n) [n]: n
    
  11. La utilidad muestra la configuración generada en la pantalla.
    
    Generated configuration is:
    {
      "source" : {
        "type" : "file",
        "format" : "csv",
        "dataPath" : "[~/nosql-migrator-1.5.0]/course.csv",
        "hasHeader" : false,
        "csvOptions" : {
          "encoding" : "UTF-8",
          "trim" : false
        }
      },
      "sink" : {
        "type" : "nosqldb",
        "storeName" : "mystore",
        "helperHosts" : ["<hostname>:5000"],
        "table" : "migrated_table",
        "query" : "",
        "includeTTL" : false,
        "schemaInfo" : {
          "schemaPath" : "[~/nosql-migrator-1.5.0]/mytable_schema.ddl"
        },
        "overwrite" : true,
        "requestTimeoutMs" : 5000
      },
      "abortOnError" : true,
      "migratorVersion" : "1.5.0"
    }
    
  12. Por último, la utilidad le solicita que especifique si desea continuar con la migración mediante el archivo de configuración generado. La opción por defecto es y.
    Nota: Si selecciona n, puede utilizar el archivo de configuración generado para realizar la migración. Especifique la opción ./runMigrator -c o ./runMigrator --config.
    
    Would you like to run the migration with above configuration?
    If you select no, you can use the generated configuration file to
    run the migration using:
    ./runMigrator --config ./migrator-config.json
    (y/n) [y]: y
    
    
  13. El NoSQL Database Migrator copia los datos del archivo CSV en Oracle NoSQL Database.
    
    creating source from given configuration:
    source creation completed
    creating sink from given configuration:
    sink creation completed
    creating migrator pipeline
    migration started
    [nosqldb sink] : start loading DDLs
    [nosqldb sink] : executing DDL: create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id))
    [nosqldb sink] : completed loading DDLs
    [nosqldb sink] : start loading records
    [csv file source] : start parsing CSV records from file: course.csv
    migration completed. Records provided by source=4, Records written to sink=4, Records failed=0,Records skipped=0.
    Elapsed time: 0min 0sec 559ms
    Migration completed.
    
Validación
Inicie la petición de datos SQL en KVStore.
 java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
Verifique que la nueva tabla se crea con los datos de origen:

sql-> select * from course;
{"id":4,"name":"Telecommunication","location":"San Francisco","fees":2500}
{"id":1,"name":"Computer Science","location":"San Francisco","fees":2500}
{"id":2,"name":"Bio-Technology","location":"Los Angeles","fees":1200}
{"id":3,"name":"Journalism","location":"Las Vegas","fees":1500}
 
4 rows returned