Uso de Oracle NoSQL Database Migrator

Obtenga más 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 de Oracle NoSQL de un origen de datos a otro. Esta herramienta puede funcionar en tablas en Oracle NoSQL Database Cloud Service, Oracle NoSQL Database local y AWS S3. La herramienta Migrator admite varios formatos de datos y tipos de medios físicos diferentes. Los formatos de datos soportados son los archivos JSON, Parquet, JSON con formato MongoDB, JSON con formato DynamoDB y CSV. Los tipos de medios físicos soportados son los 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:

Visión general

Oracle NoSQL Database Migrator permite mover tablas de Oracle NoSQL 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 la migración de tablas NoSQL desde o a una instancia de Oracle NoSQL Database. Por ejemplo, es posible que un equipo de desarrolladores que mejora una aplicación NoSQL Database desee probar su código actualizado en la instancia local de Oracle NoSQL Database Cloud Service (NDCS) mediante un servicio cloudsim. Para verificar todos los posibles casos de prueba, deben configurar los datos de prueba similares a los datos reales. Para ello, deben copiar las tablas NoSQL del entorno de producción en su instancia de NDCS local, el entorno cloudsim. En otra situación, puede que los desarrolladores de NoSQL necesiten mover los datos de sus aplicaciones de las ubicaciones locales 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 desde un archivo de entrada JSON con formato MongoDB, un archivo de entrada JSON con formato DynamoDB (almacenado en el origen de AWS S3 o desde archivos) o un archivo CSV en su base de datos NoSQL local o en la nube.

Como se muestra en la siguiente figura, la utilidad NoSQL Database Migrator actúa como conector o conducto entre el origen de datos y el destino (denominado sumidero). Básicamente, esta utilidad exporta datos del origen seleccionado e importa esos datos en el fregadero. 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 admite la migración de datos de tabla del origen al receptor en varios formatos de datos.

Oracle NoSQL Database Migrator está diseñado para admitir orígenes y sumideros adicionales en el futuro. Para obtener una lista de orígenes y receptores soportados por Oracle NoSQL Database Migrator a partir de la versión actual, consulte Orígenes y receptores soportados. Descripción de imagen a continuación

Descripción de la ilustración migrator_overview.png

Terminología utilizada con Oracle NoSQL Database Migrator

Conozca los diferentes términos utilizados en el diagrama anterior, en detalle.

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

Nota: Dado que el archivo JSON distingue entre mayúsculas y minúsculas, todos los parámetros definidos en el archivo de configuración distinguen entre mayúsculas y 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 fregadero, debe ser un producto Oracle NoSQL. No puede utilizar 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
Sistema de archivos (file) JSON de MongoDB (mongodb_json) S N
Sistema de archivos (file) JSON de DynamoDB (dynamodb_json) S N
Sistema de archivos (file) Parquet (parquet) N S
Sistema de archivos (file) CSV (csv) S N
OCI Object Almacenamiento (object_storage_oci) JSON (json) S S
OCI Object Almacenamiento (object_storage_oci) JSON de MongoDB (mongodb_json) S N
OCI Object Almacenamiento (object_storage_oci) Parquet (parquet) N S
OCI Object Almacenamiento (object_storage_oci) CSV (csv) S N
AWS S3 JSON de DynamoDB (dynamodb_json) S N

Nota: Muchos parámetros de configuración son comunes en la configuración de origen y de receptor. Para facilitar la referencia, la descripción de dichos parámetros se repite para cada origen y fregadero en las secciones de documentación, que explican los formatos de archivo de configuración para varios tipos de orígenes 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 origen y de fregadero tienen información de seguridad opcional u obligatoria para fines de autenticación.

Todos los orígenes y receptores que utilizan servicios en 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 con principales de instancia

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

Oracle NoSQL Database Migrator proporciona una opción para conectarse a una nube de NoSQL y a orígenes y fregaderos de OCI Object Storage mediante la autenticación de principal de instancia. Solo se admite 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 archivo de configuración de origen y receptor de NoSQL en la nube. Para obtener más información sobre los parámetros de configuración para diferentes tipos de orígenes y receptores, consulte Source Configuration Templates y Sink Configuration Templates.

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

Autorización en orígenes y receptores de Oracle NoSQL Database Cloud Service

El acceso a los recursos de Oracle NoSQL Database Cloud Service, como tablas, tablespaces y API, se gestiona mediante políticas de gestión de identidad y acceso (IAM). Esto garantiza que solo los usuarios o las aplicaciones con los permisos de tabla de inspección, lectura, uso o gestión adecuados dentro de un compartimento específico puedan interactuar con estos recursos. Para obtener más información, consulte Gestión de acceso a tablas de NDCS.

Al utilizar la utilidad Migrator para importar o exportar datos de tablas de Oracle NoSQL Database Cloud Service, los permisos de IAM efectivos determinan los recursos desde los que puede leer o escribir. Si un usuario de un grupo definido intenta una acción más allá de sus privilegios autorizados, la utilidad Migrator devuelve el error de autorización correspondiente según lo proporcionado por OCI IAM.

Por ejemplo, OCI IAM niega cualquier intento de importar datos en una tabla de Oracle NoSQL Database Cloud Service si su grupo de usuarios solo tiene el permiso de "lectura" en la tabla. En los logs se muestra un mensaje del error similar al siguiente:

[INSUFFICIENT_PERMISSION] Authorization failed or requested resource not found

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 NoSQL.

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

A continuación, se muestra la descripción de imagen

Descripción de la ilustración migrator_flow.png

Descarga de la utilidad NoSQL Data Migrator

La utilidad Oracle NoSQL Database Migrator está disponible para descargar desde la página Descargas de Oracle NoSQL. Una vez que lo descargue y descomprima en su máquina, puede acceder al comando runMigrator desde la interfaz de línea de comandos.

Nota: La utilidad Oracle NoSQL Database Migrator necesita que se ejecuten Java 11 o versiones superiores.

Identificar el origen y el disipador

Antes de utilizar el migrador, debe identificar el origen de datos y el receptor. Por ejemplo, si desea migrar una tabla NoSQL desde Oracle NoSQL Database local a un archivo con formato JSON, el origen será Oracle NoSQL Database y el archivo JSON será el receptor. Asegúrese de que el migrador de Oracle NoSQL Database soporta el origen y el receptor identificados haciendo referencia a los orígenes y receptores soportados. Esta es también una fase adecuada para decidir el esquema de la tabla NoSQL en el destino o el fregadero y crearlos.

Nota: La migración fallará si la tabla está presente en el receptor y el DDL en schemaPath es diferente de la tabla.

Nota: 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 de acceso del archivo en el parámetro schemaInfo.schemaPath del archivo de configuración del fregadero.

Ejecute el comando runMigrator

El archivo ejecutable runMigrator está disponible en los archivos extraídos de NoSQL Database Migrator. 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. Creando el 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 de cada opción.

    • Después de que la utilidad cree el archivo de configuración, puede 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 aplazar 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 de receptor, consulte Referencia de Oracle NoSQL Database Migrator.

    [~]$ ./runMigrator -c </path/to/the/configuration/json/file>

Nota: NoSQL Database Migrator consume unidades de lectura al exportar datos de la tabla de Oracle NoSQL Cloud Service a cualquier dispositivo válido.

Progreso del Migrador de Registro

La herramienta NoSQL Database Migrator proporciona opciones, lo que permite 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.

Limitación

Oracle NoSQL Database Migrator no bloquea la base de datos durante la copia de seguridad y bloquea a otros usuarios. Por lo tanto, se recomienda no realizar las siguientes actividades cuando se ejecuta una tarea de migración:

Migración de Metadatos de TTL para Filas de Tabla

Descubra cómo migrar datos TTL del origen al fregadero.

El tiempo de vida (TTL) es un mecanismo que permite caducar automáticamente las filas de la tabla. El TTL se expresa como la cantidad de tiempo que 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 optar por 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 de 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 de 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 de 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 siempre es

  1. 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 de fregadero.

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 ejecuta la herramienta NoSQL Database Migrator. Sin embargo, también puede definir una hora de referencia personalizada mediante el parámetro de configuración ttlRelativeDate si desea ampliar la hora de caducidad e importar filas que, de lo contrario, caducarían inmediatamente. La extensión se calcula de la siguiente forma y se agrega al tiempo 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 de TTL. Estos casos de uso solo se aplican cuando el parámetro de configuración includeTTL está definido en true.

Importación de metadatos de TTL en un archivo JSON con formato DynamoDB y un 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 desde 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 opcionalmente los valores de TTL de los archivos JSON exportados de DynamoDB, debe proporcionar el nombre del atributo específico como valor al parámetro de configuración ttlAttributeName en el archivo JSON con formato DynamoDB o el archivo JSON con formato DynamoDB almacenado 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 de fregadero. Los receptores válidos son Oracle NoSQL Database y Oracle NoSQL Database Cloud Service. NoSQL Database Migrator almacena la 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 de DynamoDB:

Nota: Puede proporcionar el parámetro de configuración ttlRelativeDate en la plantilla de configuración de fregadero como hora de referencia para calcular la hora de caducidad.

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

Aprenda a importar datos a un fregadero que incluye una columna IDENTITY.

Puede importar los datos de un origen válido a una tabla de receptor (local/servicios 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 Creación de tablas con una columna IDENTITY en la guía de referencia SQL.

Antes de importar los datos, asegúrese de que la tabla de Oracle NoSQL Database en el fregadero 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 columna IDENTITY como GENERATED SIEMPRE COMO IDENTITY

Considere una tabla de sumideros con la columna IDENTITY creada como GENERATED SIEMPRE COMO IDENTITY. La importación de datos depende de si el origen proporciona o no los valores a la columna IDENTITY y del 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 sumideros es:

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))

La utilidad Migrator gestiona la migración de datos como se describe en los siguientes casos:

Condición de origen Acción de usuario Resultado de migración

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

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.

La migración de datos se ha realizado correctamente. Los valores de 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 sumideros.

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. Se proporciona una transformación ignoreFields para la columna ID en la plantilla de configuración de fregadero.

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

La migración de datos se ha realizado correctamente. Los valores de ID proporcionados se omiten y los valores de la 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 GENERATED BY DEFAULT AS IDENTITY

Considere una tabla de sumideros 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 sumideros es:

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))

La utilidad Migrator gestiona la migración de datos como se describe en los siguientes casos:

Condición de origen Acción de usuario Resultado de migración

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

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.

La migración de datos se ha realizado correctamente. Los valores de 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 sumideros 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. Se proporciona una transformación ignoreFields para la columna ID en la plantilla de configuración de fregadero (recomendado).

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

La migración de datos se ha realizado correctamente. Los valores de ID proporcionados se omiten y los valores de la 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.

La migración de datos se ha realizado correctamente. Los valores ID proporcionados del origen se copian en la columna ID de la tabla de receptor.

Cuando se 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 Generador de secuencias para obtener información adicional.

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 de Oracle NoSQL Database migrateID:

{"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 ID, recupere el valor máximo del campo ID mediante la siguiente consulta:

SELECT ID FROM migrateID ORDER BY ID DESC LIMIT 1

Salida:

{"ID":3}

El valor máximo de la columna ID en la tabla de sumideros es 3. Desea que el generador de secuencias empiece 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 a las 4.

Ahora, al insertar filas en la tabla de receptores 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 ID.

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.

Filtrado de datos mediante predicados de consulta

Descubra cómo especificar predicados de consulta para exportar solo las filas de la tabla que coinciden con los criterios de filtro.

Predicado de consulta

NoSQL Database Migrator proporciona una opción para filtrar los datos durante la exportación especificando un predicado de consulta. El predicado de consulta especifica las condiciones que se deben cumplir para que se exporte una fila. La utilidad Migrator convierte el predicado de consulta en una cláusula SQL WHERE y lo aplica en la tabla determinada para proporcionar una condición de filtro que solo exporte las filas que coincidan con la condición especificada. Puede utilizar funciones incorporadas (modification_time(), expiration_time(), creation_time()) en el predicado de consulta para crear opciones de filtro avanzadas.

Solo puede utilizar predicados de consulta en orígenes de Oracle NoSQL Database y Oracle NoSQL Database Cloud Service para todos los receptores soportados. Para obtener más información, consulte Oracle NoSQL Database y Oracle NoSQL Database Cloud Service.

Para ver una demostración de un caso de uso, consulte Migración de Oracle NoSQL Database Cloud Service a un archivo JSON.

Volcar filtro

La utilidad Migrator proporciona una opción para repetir la consulta SQL que se ejecuta en el backend. Esta función le ayuda a verificar la consulta generada y, si es necesario, a restringir el filtro antes de ejecutar la tarea de migración.

Puede ejecutar la utilidad Migrator con la opción de filtro de volcado de la siguiente manera:

[~/nosqlMigrator]$./runMigrator --dump-filter|df [optional-config-file]

Demostraciones de casos de uso para Oracle NoSQL Database Migrator

Descubra cómo realizar la migración de datos mediante el migrador de Oracle NoSQL Database 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 el migrador de Oracle NoSQL Database para copiar datos y la definición de esquema de una tabla NoSQL de Oracle NoSQL Database Cloud Service (NDCS) a un archivo JSON.

Caso de uso

Una organización decide entrenar un modelo con los datos de Oracle NoSQL Database Cloud Service (NDCS) para predecir comportamientos futuros y proporcionar recomendaciones personalizadas. Pueden tomar una copia periódica de los datos de las tablas de NDCS en un archivo JSON y aplicarla al motor analítico 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 los datos y la definición de esquema de una tabla NoSQL denominada myTable de NDCS a un archivo JSON.

Requisitos

Procedimiento

Para migrar los datos y la definición de esquema de la tabla de Oracle NoSQL Database Cloud Service a un archivo JSON, puede utilizar una de las siguientes opciones:

  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 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 le 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

4) session_token

5) oke_workload_identity

#? 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 peticiones de datos de la utilidad, seleccione las opciones para la configuración de Sink.

    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 por defecto es n.

    Would you like to add transformations to source data? (y/n) [n]:

  7. Introduzca su opción para determinar si se debe continuar con la migración en caso de que algún registro no se pueda migrar.

    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-ashburn-1",
    "table": "myTable",
    "compartment": "ocid1.compartment.oc1..aa..rhsmq",
    "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.8.0"
}

  9. La utilidad le solicita que decida si desea continuar con la migración con el archivo de configuración generado o no. La opción por defecto es y.

    Nota: 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. 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 al directorio de fregadero 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)))

  1. Prepare el archivo de configuración (en formato JSON) con los detalles del origen y el receptor de JSON de Oracle NoSQL Database Cloud Service (NDCS). Consulte Source Configuration Templates y Sink Configuration Templates.

    En este ejemplo, se utiliza una tabla users con los siguientes datos:

    {"id":10,"firstName":"John","lastName":"Smith","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}}
{"id":20,"firstName":"Jane","lastName":"Smith","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}}
{"id":30,"firstName":"Adam","lastName":"Smith","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}}
{"id":40,"firstName":"Joanna","lastName":"Smith","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}}

    Asegúrese de incluir el parámetro queryFilter con el predicado de consulta adecuado en la plantilla de configuración de origen para exportar solo las filas necesarias de la tabla. Para obtener más información sobre cómo crear predicados de consulta, consulte la tabla Predicados de consulta de ejemplo en el tema Origen de servicio de NoSQL Database Cloud.

    En este ejemplo, el predicado de consulta exporta filas con el campo city en la columna JSON address = 'Houston' de la tabla users.

    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "queryFilter" : "$row.address.city='Houston'",
    "compartment" : "ocid1.compartment.oc1..aa..rhsmq",
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "readUnitsPercent" : 90,
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "file",
    "format" : "json",
    "useMultiFiles" : true,
    "chunkSize" : 32,
    "schemaPath" : "/scratch/<user>/nosqlMigrator/tableschema.ddl",
    "pretty" : false,
    "dataPath" : "/scratch/<user>/nosqlMigrator"
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.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. Utilice la opción --config o -c.

    [~/nosqlMigrator]$./runMigrator --config <complete/path/to/the/JSON/config/file>

    Nota:

    También puede ejecutar el comando con la

    opción para ver y verificar la consulta generada antes de ejecutar la tarea de migración de la siguiente manera. Para obtener más información, consulte

    .

    [~/nosqlMigrator]$./runMigrator --dump-filter <complete/path/to/the/JSON/config/file>

    La utilidad continúa con la migración de datos de la siguiente manera:

    [INFO] creating source from given configuration:
[INFO] [cloud source] : query = 'SELECT $row,expiration_time_millis($row) AS expiration FROM users $row where $row.address.city='Houston''
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [json file sink] : writing table schema to /scratch/raumesh/nosqlMigrator/tableschema.ddl
[INFO] migration started
[INFO] Migration success for source users. read=2,written=2,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 182ms
Migration completed.

Verificación

Para verificar la migración, puede navegar hasta el directorio del fregadero especificado y ver el esquema y los datos. Solo se exportan las filas de la columna JSON address con el valor del campo city 'Houston'.

-- Exported users data. Schema and JSON files are created in the supplied data paths.

[~/nosqlMigrator]: cat tableschema.ddl

CREATE TABLE IF NOT EXISTS users (id INTEGER, firstName STRING, lastName STRING, age INTEGER, income INTEGER, address JSON, PRIMARY KEY(SHARD(id)))
[~/nosqlMigrator]: cat users_6_10.json

{"id":30,"firstName":"Adam","lastName":"Smith","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}}
{"id":40,"firstName":"Joanna","lastName":"Smith","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}}
bash-4.4$

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

En este ejemplo se muestra cómo utilizar el migrador de Oracle NoSQL Database 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 que supone gestionar los recursos, los clusters y la recolección de basura para las cargas de trabajo existentes de KVStore de base de datos NoSQL. Como solución, decide migrar sus cargas de trabajo de KVStore locales existentes a Oracle NoSQL Database Cloud Service, ya que NDCS las gestiona automáticamente.

Ejemplo

Para ver la demostración, veamos cómo migrar los datos y la definición de esquema de una tabla NoSQL denominada myTable de NoSQL Database KVStore a NDCS. También utilizaremos este caso de uso para mostrar cómo ejecutar la utilidad runMigrator mediante la transferencia de un archivo de configuración creado previamente.

Requisitos

Procedimiento

Para migrar los datos y la definición de esquema de myTable de NoSQL Database KVStore a NDCS:

  1. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y de disipador 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.8.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.8.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 su origen está en formato de archivo JSON, buscan una forma de migrarlos a Oracle NoSQL Database Cloud Service.

En este ejemplo, aprenderá a migrar los datos de un archivo JSON denominado SampleData.json. Para ejecutar la utilidad runMigrator, transfiera 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

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 los detalles de origen y receptor identificados. Consulte Source Configuration Templates y Sink Configuration Templates.

    {
  "source" : {
    "type" : "file",
    "format" : "json",
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.8.0]/schema_json.ddl"
    },
    "dataPath" : "[~/nosql-migrator-1.8.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.8.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.8.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 fregadero 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 ha creado con los datos de origen. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure en el documento de Oracle NoSQL Database Cloud Service.

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

A continuación, se describe la imagen.

Descripción de la ilustración migrate_json1.png

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

A continuación, se muestra la descripción de imagen

Descripción de la ilustración migrate_json2.png

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

En este ejemplo se muestra cómo utilizar el migrador de Oracle NoSQL Database para copiar datos con formato MongoDB 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. Las tablas y los datos están en MongoDB y la organización desea migrar ambos 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.

Consideremos los dos siguientes archivos JSON de ejemplo exportados desde MongoDB para demostrar nuestro caso de uso.

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

Un archivo JSON con formato MongoDB de ejemplo exportado desde una aplicación Spring es el siguiente:

{"_id":{"$oid":"63d3a87cf564fc21dac3838d"},"firstName":"John","lastName":"Smith","address":{"Country":"France"},"_class":"com.example.demo.Customer"}
{"_id":{"$oid":"63d3a87cf564fc21dac3838e"},"firstName":"Sam","lastName":"David","address":{"Country":"USA"},"_class":"com.example.demo.Customer"}
{"_id":"3","firstName":"Dona","lastName":"William","address":{"Country":"England"},"_class":"com.example.demo.Customer"}

MongoDB soporta dos tipos de extensiones para los archivos JSON con formato, Modo canónico y Modo relajado. Puede proporcionar el archivo JSON con formato MongoDB que se genera mediante la herramienta mongoexport en modo canónico o relajado. NoSQL Database Migrator soporta ambos modos.

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

Para obtener más información sobre la generación de un 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

Procedimiento

Para migrar los datos JSON con formato MongoDB a Oracle NoSQL Database Cloud Service, puede elegir una de las siguientes opciones:

  1. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y de disipador identificados. Consulte Source Configuration Templates y Sink Configuration Templates.

    Aquí, defina el parámetro de configuración defaultSchema en true. Por lo tanto, NoSQL Database Migrator crea una tabla con el esquema por defecto en el fregadero.

    {
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "mongoImport",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",

    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "defaultSchema" : true
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

    El esquema por defecto para el origen de archivo JSON con formato MongoDB es el siguiente:

    CREATE TABLE IF NOT EXISTS <tablename>(id STRING, document JSON,PRIMARY KEY(SHARD(id));

    Dónde:

    • tablename = valor proporcionado para el atributo table en la configuración.

    • id = valor _id de cada documento del archivo de origen JSON exportado de MongoDB.

    • document = Para cada documento del archivo exportado MongoDB, el contenido que excluye el campo _id se agrega a la columna document.

    Nota: Si la tabla <tablename> ya existe en Oracle NoSQL Database Cloud Service y desea migrar datos a la tabla mediante la configuración defaultSchema, debe asegurarse de que la tabla existente tiene la columna de ID en minúsculas (id) y es del tipo STRING.

  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. 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 a continuación.

    [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] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS mongoImport (id STRING, document JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] [mongo file source] : start parsing MongoDB JSON records from file: mongoDBSample.json
[INFO] Migration success for source mongoDBSample. read=5,written=5,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 448ms
Migration completed.

Verificación

Para verificar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service y verificar que la tabla mongoImport se ha creado con los datos de origen. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure.

  1. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y de disipador identificados. Consulte Source Configuration Templates y Sink Configuration Templates.

    Aquí, puede especificar el archivo que contiene la sentencia DDL de la tabla de receptor en el parámetro schemaPath de la plantilla de configuración de origen. En consecuencia, defina el parámetro de configuración useSourceSchema en true en la plantilla de configuración de receptor.

    Puede generar un esquema personalizado de la siguiente manera:

    • Observe los nombres y los tipos de dato de cada columna de los datos JSON con formato MongoDB. Utilice esta información para crear un archivo DDL de esquema para la tabla de Oracle NoSQL Database Cloud Service.

    • En el archivo de esquema, asigne a la primera columna (clave primaria) el nombre id del tipo STRING. Incluya el mismo nombre y tipo para las columnas restantes según lo registrado en el archivo JSON con formato MongoDB.

    • Guarde el archivo de esquema y anote su ruta de acceso completa.

    En este ejemplo se utiliza el siguiente esquema definido por el usuario:

    CREATE TABLE IF NOT EXISTS sampleMongoDBImp (id STRING, name STRING, scores JSON, PRIMARY KEY(SHARD(id)));

    Debe incluir una transformación renameFields que indique a NoSQL Database Migrator que convierta la columna _id en id al crear la tabla. Para obtener más información sobre los parámetros, consulte Transformation Configuration Templates. NoSQL Database Migrator crea una tabla con el esquema personalizado en el fregadero.

    {
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "schemaInfo" : {
      "schemaPath" : "<complete/path/to/the/schema/file>"
    },
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "sampleMongoDBImp",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : false,
    "requestTimeoutMs" : 5000
  },
  "transforms": {
    "renameFields" : {
      "_id":"id"
    }
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.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. 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 a continuación.

    [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] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampleMongoDBImp (id INTEGER, name STRING, scores JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[INFO] [cloud sink] : completed loading DDLs
[INFO] migration started
[INFO] [mongo file source] : start parsing MongoDB JSON records from file: mongoDBSample.json
[INFO] Migration success for source mongoDBSample. read=5,written=5,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 438ms
Migration completed.

Verificación

Para verificar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service y verificar que la tabla sampleMongoDBImp se ha creado con los datos de origen. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure.

  1. Para este caso de uso, utilizaremos el archivo JSON con formato MongoDB de ejemplo exportado desde una aplicación Spring como origen. Para obtener más información sobre este formato, consulte Datos de primavera.

  2. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y de disipador identificados. Consulte Source Configuration Templates y Sink Configuration Templates.

    Aquí, puede especificar el archivo que contiene la sentencia DDL de la tabla de receptor en el parámetro schemaPath de la plantilla de configuración de origen. En consecuencia, defina el parámetro de configuración useSourceSchema en true en la plantilla de configuración de receptor.

    Puede generar un esquema personalizado de la siguiente manera:

    • Observe los nombres y los tipos de dato de cada columna de los datos JSON con formato MongoDB.

    • En el archivo de esquema, asigne a la primera columna (clave primaria) el nombre id del tipo STRING. Agregue los campos restantes a un campo denominado kv_json_ de tipo JSON, que cumpla con el formato de datos de Spring. Para obtener más información, consulte el modelo de persistencia del marco de datos de Spring.

    • Guarde el archivo de esquema y anote su ruta de acceso completa.

    En este ejemplo se utiliza el siguiente esquema definido por el usuario:

    CREATE TABLE IF NOT EXISTS sampleMongoDBSpringImp(id STRING, kv_json_ JSON, PRIMARY KEY(SHARD(id)))

    Para el ejemplo de datos de Spring indicado anteriormente, debe incluir las siguientes transformaciones:

    • Transformación renameFields para convertir la columna _id en id

    • Transformación ignoreFields para ignorar la columna _class y no incluirla en la tabla de receptor

    • Transformación aggregateFields para agregar los campos restantes (distintos de id) a un campo de tipo JSON

    Para obtener más información sobre los parámetros, consulte Transformation Configuration Templates. NoSQL Database Migrator crea una tabla con el esquema personalizado en el fregadero.

    {
  "source": {
    "type": "file",
    "format": "mongodb_json",
    "schemaInfo": {
      "schemaPath": "<complete/path/to/the/schema/file>"
    },
    "dataPath": "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink": {
    "type": "nosqldb_cloud",
    "endpoint": "us-ashburn-1",
    "table": "sampleMongoDBSpringImp",
    "compartment": "ocid1.compartment.oc1..aaaaaaaaadeskhnnfkenws4k2vdyklcc32hfpzzz4z3zum3ubhmpz6zxnoza",
    "includeTTL": true,
    "schemaInfo": {
      "readUnits": 100,
      "writeUnits": 60,
      "storageSize": 1,
      "useSourceSchema": true
    },
    "credentials": "<complete/path/to/the/oci/config/file>",
    "credentialsProfile": "DEFAULT",
    "writeUnitsPercent": 90,
    "overwrite": false,
    "requestTimeoutMs": 5000
  },
  "transforms": {
    "renameFields": {
      "_id": "id"
    },
    "ignoreFields": ["_class"],
    "aggregateFields": {
      "fieldName": "kv_json_",
      "skipFields": ["id"]
    }
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  3. Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator.

  4. Ejecute el comando runMigrator transfiriendo el archivo de configuración. Utilice la opción --config o -c.

    $./runMigrator --config <complete/path/to/the/JSON/config/file>

  5. La utilidad continúa con la migración de datos, como se muestra a continuación.

    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampleMongoDBSpringImp (id STRING, kv_json_ JSON, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
migration started
[mongo file source] : start parsing MongoDB JSON records from file: mongodbspring.json
Migration success for source mongodbspring. read=3,written=3,failed=0
Migration is successful for all the sources.
migration completed.
Records provided by source=3, Records written to sink=3, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 393ms
Migration completed.

Verificación

Para verificar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service y verificar que la tabla sampleMongoDBImp se ha creado con los datos de origen. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure.

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

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

Caso de uso

Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database Cloud Service en la 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 o directorio que contenga los datos JSON exportados de DynamoDB desde un sistema de archivos especificando la ruta de acceso 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"}}}

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

Ejemplo

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

Requisitos

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 de origen y receptor identificados. Para obtener más información, consulte Source Configuration Templates y Sink Configuration Templates.

    Nota: Si los elementos de tabla JSON exportados por 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 de fregadero. Para obtener más información, consulte Migrating TTL Metadata for Table Rows.

    Aquí, defina el parámetro de configuración defaultSchema en true. Por lo tanto, NoSQL Database Migrator 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 muestra un error.

    Para obtener más información sobre el esquema por defecto para un origen JSON exportado de DynamoDB, consulte el tema Identificar el origen y el disipador en Flujo de trabajo para Oracle NoSQL Data Migrator.

        {
     "source" : {
      "type" : "file",
      "format" : "dynamodb_json",
      "ttlAttributeName" : "ttl",
      "dataPath" : "complete/path/to/the/DynamoDB/Formatted/JSON/file"
     },
     "sink" : {
      "type" : "nosqldb_cloud",
      "endpoint" : "us-sanjose-1",
      "table" : "sampledynDBImp",
      "compartment" : "ocid
1.compartment.oc1..aaaaaaaa......smq",
      "includeTTL" : true,
      "schemaInfo" : {
       "readUnits" : 10,
       "writeUnits" : 10,
       "storageSize" : 1,
       "schemaPath" : "complete/path/to/the/DDl/file"
      },
      "credentials" : "/home/<username>/.oci/config",
      "credentialsProfile" : "DEFAULT",
      "writeUnitsPercent" : 90,
      "overwrite" : true,
      "requestTimeoutMs" : 5000
     },
     "abortOnError" : true,
     "migratorVersion" : "1.8.0"
    }

    En este ejemplo se utiliza el siguiente esquema por defecto:

    CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))

  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. 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] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
[INFO] [cloud 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.

Verificación

Para validar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service y verificar que la tabla sampledynDBImp se ha creado con los datos de origen.

  1. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y receptor identificados. Para obtener más información, consulte Source Configuration Templates y Sink Configuration Templates.

    Nota: Si los elementos de tabla JSON exportados por 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 de fregadero.

    Aquí, defina el parámetro de configuración defaultSchema en false. Por lo tanto, especifique el archivo que contiene la sentencia DDL de la tabla de receptor en el parámetro schemaPath. Consulte Asignación de tipos DynamoDB a tipos de Oracle NoSQL 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 fregadero 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.

    Nota:

    • Si la tabla de base de datos de Dynamo tiene un tipo de datos que no está 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 en una columna JSON. Para obtener más información, consulte aggregateFields.

        Generated configuration is
    {
     "source" : {
      "type" : "file",
      "format" : "dynamodb_json",
      "ttlAttributeName" : "ttl",
      "dataPath" : "complete/path/to/the/DynamoDB/Formatted/JSON/file"
     },
     "sink" : {
      "type" : "nosqldb_cloud",
      "endpoint" : "us-sanjose-1",
      "table" : "sampledynDBImp",
      "compartment" : "ocid
1.compartment.oc1..aaaaaaaa......smq",
      "includeTTL" : true,
      "schemaInfo" : {
       "readUnits" : 10,
       "writeUnits" : 10,
       "storageSize" : 1,
       "schemaPath" : "complete/path/to/the/DDl/file"
      },
      "credentials" : "/home/<username>/.oci/config",
      "credentialsProfile" : "DEFAULT",
      "writeUnitsPercent" : 90,
      "overwrite" : true,
      "requestTimeoutMs" : 5000
     },
     "abortOnError" : true,
     "migratorVersion" : "1.8.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 archivos de configuración independientes. 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] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
[INFO] [cloud 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.

Verificación

Para validar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service y verificar que la tabla sampledynDBImp se ha creado con los datos de origen.

Migración del archivo JSON de 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 de DynamoDB almacenado en un almacén de AWS S3 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 en la 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 Oracle NoSQL 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 de acceso 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.

Ejemplo:

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

Requisitos

Procedimiento

Para migrar los datos JSON de DynamoDB a Oracle NoSQL Database Cloud Service, utilice una de las siguientes opciones:

  1. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y receptor identificados. Para obtener más información, consulte Source Configuration Templates y Sink Configuration Templates.

    Nota: Si los elementos del archivo JSON de DynamoDB en 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 de fregadero. Para obtener más información, consulte Migrating TTL Metadata for Table Rows.

    Defina defaultSchema en TRUE y, por lo tanto, la utilidad Migrator 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.8.0"
    }

    Para un origen JSON de DynamoDB, el esquema por defecto para 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 fregadero 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 existe

    DDBSortKey_type = valor proporcionado para el tipo de datos 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 agregados en una columna JSON de NoSQL

  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. Utilice 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.

Verificación

Puede conectarse a la consola de Oracle NoSQL Database Cloud Service y verificar que la nueva tabla se ha creado con los datos de origen.

  1. Prepare el archivo de configuración (en formato JSON) con los detalles de origen y receptor identificados. Para obtener más información, consulte Source Configuration Templates y Sink Configuration Templates.

    Nota: Si los elementos del archivo JSON de DynamoDB en 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 de receptor. Para obtener más información, consulte Migrating TTL Metadata for Table Rows.

    Para especificar un archivo de esquema definido por el usuario en la plantilla de configuración de fregadero, defina defaultSchema en FALSE y especifique schemaPath como un archivo que contenga la sentencia DDL. Para obtener más información, consulte Asignación de tipos DynamoDB a tipos NoSQL de Oracle.

    Nota: Si la tabla de base de datos de Dynamo tiene un tipo de datos que no está soportado en NoSQL, la migración falla.

    A continuación se muestra un archivo de esquema de ejemplo.

    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 fregadero 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 producirá un error.

    Nota:

    • 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 en una columna JSON. Para obtener más información, 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.8.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. Utilice 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.

Verificación

Puede conectarse a la consola de Oracle NoSQL Database Cloud Service y verificar que la nueva tabla se ha creado con los datos de origen.

Migración 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.

Casos prácticos

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 con fines de prueba antes de que se pueda iniciar la nueva región para el entorno de producción.

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

Para ejecutar la utilidad runMigrator, transfiera 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

En este ejemplo, las regiones se encuentran en distintos arrendamientos. 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 migrador (tanto las plantillas de configuración de origen como las de fregadero), puede proporcionar la URL de punto final de servicio o el ID de región de las regiones. Para obtener una lista de las 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 los detalles de origen y receptor identificados. Consulte Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates.

    {
  "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.8.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]$./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 fregadero con el mismo esquema que la tabla de origen, ya que ha configurado el parámetro useSourceSchema como true en la plantilla de configuración del fregadero.

    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.

    Nota:

    • Si la tabla ya existe en el fregadero 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 de sobrescritura como true en la plantilla de configuración.

    • Si la tabla ya existe en el fregadero 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.

Migración 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.

Casos prácticos

Una empresa de nueva creación planea utilizar Oracle NoSQL Database Cloud Service como su solución de almacenamiento de datos. La empresa desea utilizar Oracle NoSQL Database Migrator para copiar datos de una tabla de Oracle NoSQL Database Cloud Service en OCI Object Storage con el fin de 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 en un Cloud Shell de 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.

Para ejecutar la utilidad runMigrator, transfiera 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

Procedimiento

Para migrar de Oracle NoSQL Database Cloud Service a OCI Object Storage, realice lo siguiente desde la ventana de Cloud Shell:

  1. Prepare un archivo de configuración del migrador, migrator-config.json, con el origen de Oracle NoSQL Database Cloud Service y el fregadero de OCI Object Storage. Para obtener más información sobre las plantillas, consulte Source Configuration Templates y Sink Configuration Templates. Asegúrese de definir el parámetro useDelegationToken en true en las plantillas de configuración de origen y de 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.8.0"
}

  2. Desde Cloud Shell, 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.

    [~/nosql-migrator]$./runMigrator --config <complete/path/to/the/config/file>

  4. La utilidad NoSQL Database Migrator continúa con la migración de datos. Dado que 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. 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.

    Nota:

    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 fregadero, 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 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 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 NoSQL Database Migrator, copiará la imagen en un repositorio de Container Registry, creará un cluster de OKE y desplegará la imagen de Migrator 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

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 de NDCS. Para obtener más información sobre 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 tanto en las plantillas de configuración de origen como 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.

    Nota: 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.8.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. Despliegue 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.8.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.

    Nota:

    Puede ejecutar la migración de datos de forma iterativa 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

Nota: 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.

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 de 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 de credenciales 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" : "1.8.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 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.

    Nota:

    Según el parámetro chunkSize de la plantilla de configuración de 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 Cloud Service

En este ejemplo se muestra el uso del migrador de Oracle NoSQL Database para copiar datos de un archivo CSV a Oracle NoSQL Database Cloud Service.

Ejemplo

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 su origen está en formato CSV, buscan una forma de migrarlo a Oracle NoSQL Database Cloud Service.

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 de manera interactiva desde la utilidad runMigrator.

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

Requisitos

Procedimiento

Para migrar datos del archivo course.csv a Oracle NoSQL Database Cloud 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.8.0]$./runMigrator

  3. Como no ha proporcionado el archivo de configuración como parámetro de tiempo de ejecución, la utilidad le 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, en función de las peticiones de datos de la utilidad, puede elegir 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]/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. Según las peticiones de datos de la utilidad, seleccione la opción nosqldb_cloud para la configuración de Sink.

    Select the sink:
1) nosqldb

2) nosqldb_cloud

#? 2

  7. Proporcione la URL de punto final o el ID de región de su arrendamiento y seleccione el tipo de autenticación para que la utilidad Migrator acceda a Oracle NoSQL Database Cloud Service.

    Configuration for sink type=nosqldb_cloud
Enter endpoint URL or region ID of the Oracle NoSQL Database Cloud: us-ashburn-1
Select the authentication type:
1) credentials_file

2) instance_principal

3) delegation_token

4) session_token

5) oke_workload_identity

#? 1

  8. Según las peticiones de datos de la utilidad, proporcione el nombre del archivo de credenciales que se va a utilizar para la autenticación, el perfil de credenciales, el ID de compartimento y el nombre de la tabla en la que desea copiar los datos en el fregadero.

    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 []: ua_nosql
Enter table name: course

  9. Introduzca su opción para definir el valor de TTL. El valor por defecto es n.

    Include TTL data? If you select 'yes' TTL value provided by the
source will be set on imported rows. (y/n) [n]: y
Would you like to provide TTL reference time?(y/n) [n]: n

  10. Según 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 de acceso 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]/mytable_schema.ddl

  11. Introduzca los valores de rendimiento y la asignación de almacenamiento para la tabla de receptor.

    Would you like to use on demand read and write units? (y/n) [n]: n
Enter read throughput in KB of new table: 100
Enter write throughput in KB of new table: 60
Enter storage size in GB of new table: 1
Enter percentage of table write units to be used for migration operation.
(1-100) [90]: 90

  12. Introduzca las opciones para determinar si se deben sobrescribir o no los registros si la tabla ya está disponible en el fregadero. También puede agregar transformaciones a los datos de origen.

    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
Would you like to continue migration if any data fails to be migrated?
 (y/n) [n]: n

  13. La utilidad muestra la configuración generada en la pantalla.

    {
  "source" : {
    "type" : "file",
    "format" : "csv",
    "dataPath" : "[~/nosql-migrator]/course.csv",
    "hasHeader" : false,
    "csvOptions" : {
      "encoding" : "UTF-8",
      "trim" : false
    }
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "course",
    "compartment" : "ua_nosql",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "schemaPath" : "[~/nosql-migrator]/mytable_schema.ddl"
    },
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.8.0"
}

  14. Por último, la utilidad le solicita que especifique si desea continuar o no con la migración mediante el archivo de configuración generado. La opción por defecto es y.

    Nota:

    Si selecciona n, no se inicia la migración de datos. El archivo de configuración generado se guarda en el directorio Migrator. Use uno de los siguientes comandos para ejecutar la utilidad Migration con la opción de archivo de configuración.

    ./runMigrator -c ./migrator-config.json

    ./runMigrator --config ./migrator-config.json

    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

  15. NoSQL Database Migrator copia los datos del archivo CSV en Oracle NoSQL Database Cloud Service.

    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: create table if not exists course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id)),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
migration started
[csv file source] : start parsing CSV records from file: course.csv
Migration success for source course. read=4,written=4,failed=0
Migration is successful for all the sources.
migration completed.
Records provided by source=4, Records written to sink=4, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 395ms
Migration completed.

Verificación

Para verificar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service y acceder a la tabla course. La tabla contiene los datos de origen. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure en el documento de Oracle NoSQL Database Cloud Service.

Temas relacionados