Uso de Oracle NoSQL Database Migrator
Obtenga información sobre Oracle NoSQL Database Migrator y cómo utilizarlo para la migración de datos.
Oracle NoSQL Database Migrator es una herramienta que permite migrar tablas NoSQL de Oracle de un origen de datos a otro. Esta herramienta puede funcionar en tablas de Oracle NoSQL Database Cloud Service, Oracle NoSQL Database locales y AWS S3. La herramienta Migrator admite varios formatos de datos y tipos de medios físicos diferentes. Los formatos de datos soportados son archivos JSON, Parquet, JSON con formato MongoDB, JSON con formato DynamoDB y CSV. Los tipos de medios físicos soportados son archivos, OCI Object Storage, Oracle NoSQL Database local, Oracle NoSQL Database Cloud Service y AWS S3.
En este artículo se incluyen los siguientes temas:
Temas relacionados
Descripción general
Oracle NoSQL Database Migrator permite mover tablas NoSQL de Oracle de un origen de datos a otro, como Oracle NoSQL Database local o en la nube o incluso un archivo JSON simple.
Puede haber muchas situaciones que requieran que migre las tablas NoSQL desde o a una instancia de Oracle NoSQL Database. Por ejemplo, un equipo de desarrolladores que mejoren una aplicación de NoSQL Database puede que desee probar su código actualizado en la instancia local de Oracle NoSQL Database Cloud Service (NDCS) mediante cloudim. Para verificar todos los casos de prueba posibles, deben configurar los datos de prueba de forma similar a los datos reales. Para ello, deben copiar las tablas NoSQL del entorno de producción a su instancia de NDCS local, el entorno de cloudim. En otra situación, es posible que los desarrolladores de NoSQL necesiten mover los datos de sus aplicaciones de la ubicación local a la nube y viceversa, ya sea para el desarrollo o las pruebas.
En todos estos casos y muchos más, puede utilizar Oracle NoSQL Database Migrator para mover las tablas NoSQL de un origen de datos a otro, como Oracle NoSQL Database local o en la nube o incluso un archivo JSON simple. También puede copiar tablas NoSQL de un archivo de entrada JSON con formato MongoDB, un archivo de entrada JSON con formato DynamoDB (almacenado en el origen S3 de AWS o desde archivos) o un archivo CSV en la NoSQL Database local o en la nube.
Como se muestra en la siguiente figura, la utilidad NoSQL Database Migrator actúa como un conector o conducto entre el origen de datos y el destino (denominado receptor). Básicamente, esta utilidad exporta datos del origen seleccionado e importa esos datos al receptor. Esta herramienta está orientada a tablas, es decir, puede mover los datos solo a nivel de tabla. Una única tarea de migración funciona en una única tabla y soporta la migración de datos de tabla del origen al receptor en varios formatos de datos.
Terminología utilizada con Oracle NoSQL Database Migrator
Obtenga información detallada sobre los diferentes términos utilizados en el diagrama anterior.
- Origen: entidad desde la que se exportan las tablas NoSQL para la migración. Algunos ejemplos de orígenes son Oracle NoSQL Database local o en la nube, archivo JSON, archivo JSON con formato MongoDB, archivo JSON con formato DynamoDB y archivos CSV.
- Fregadero: entidad que importa las tablas NoSQL desde NoSQL Database Migrator. Algunos ejemplos para los receptores son el archivo Oracle NoSQL Database local o en la nube y JSON.
La herramienta NoSQL Database Migrator admite diferentes tipos de orígenes y receptores (es decir, medios físicos o repositorios de datos) y formatos de datos (es decir, cómo se representan los datos en el origen o el receptor). Los formatos de datos soportados son archivos JSON, Parquet, JSON con formato MongoDB, JSON con formato DynamoDB y CSV. Los tipos de origen y de receptor soportados son archivos, OCI Object Storage, Oracle NoSQL Database local y Oracle NoSQL Database Cloud Service.
- Conducto de migración: NoSQL Database Migrator transferirá los datos de un origen al receptor. Esto se puede visualizar como un conducto de migración.
- Transformaciones: puede agregar reglas para modificar los datos de la tabla NoSQL en el canal de migración. Estas reglas se llaman transformaciones. Oracle NoSQL Database Migrator solo permite transformaciones de datos en campos o columnas de nivel superior. No permite transformar los datos en los campos anidados. Algunos ejemplos de transformaciones permitidas son:
- Borrar o ignorar una o más columnas,
- Cambie el nombre de una o más columnas, o
- Agregue varias columnas en un solo campo, normalmente un campo JSON.
- Archivo de configuración: un archivo de configuración es donde se definen todos los parámetros necesarios para la actividad de migración en formato JSON. Más tarde, pasará este archivo de configuración como un único parámetro al comando
runMigratordesde la CLI. Un formato de archivo de configuración típico es similar al que se muestra a continuación.{ "source": { "type" : <source type>, //source-configuration for type. See Source Configuration Templates . }, "sink": { "type" : <sink type>, //sink-configuration for type. See Sink Configuration Templates . }, "transforms" : { //transforms configuration. See Transformation Configuration Templates . }, "migratorVersion" : "<migrator version>", "abortOnError" : <true|false> }Agrupar Parámetros Obligatorio (Y/N) Finalidad Valores soportados sourcetypeS Representa el origen desde el que migrar los datos. El origen proporciona datos y metadatos (si los hay) para la migración. Para conocer el valor typepara cada origen, consulte Supported Sources and Sinks.sourceconfiguración de origen para el tipo S Define la configuración para el origen. Estos parámetros de configuración son específicos del tipo de origen seleccionado anteriormente. Consulte Source Configuration Templates (Plantillas de configuración de origen) para obtener la lista completa de parámetros de configuración para cada tipo de origen. sinktypeS Representa el receptor al que migrar los datos. El sumidero es el destino o destino de la migración. Para conocer el valor typepara cada origen, consulte Supported Sources and Sinks.sinksink-configuration para tipo S Define la configuración del receptor. Estos parámetros de configuración son específicos del tipo de receptor seleccionado anteriormente. Consulte Sink Configuration Templates para obtener una lista completa de los parámetros de configuración para cada tipo de receptor. transformsconfiguración de transformaciones N Define las transformaciones que se aplicarán a los datos del conducto de migración. Consulte Plantillas de configuración de transformación para obtener la lista completa de transformaciones soportadas por el migrador de datos NoSQL. - migratorVersionN Versión del migrador de datos NoSQL - - abortOnErrorN Especifica si se debe detener la actividad de migración en caso de error.
El valor predeterminado es true, lo que indica que la migración se detiene cuando encuentra un error de migración.
Si establece este valor en false, la migración continúa incluso en caso de registros con fallos u otros errores de migración. Los registros con fallos y los errores de migración se registrarán como ADVERTENCIAS en el terminal de la CLI.
true, false Note:
Como el archivo JSON es sensible a mayúsculas/minúsculas, todos los parámetros definidos en el archivo de configuración son sensibles a mayúsculas/minúsculas a menos que se especifique lo contrario.
Orígenes y receptores soportados
En este tema se proporciona la lista de orígenes y receptores soportados por Oracle NoSQL Database Migrator.
Puede utilizar cualquier combinación de un origen y un receptor válidos de esta tabla para la actividad de migración. Sin embargo, debe asegurarse de que al menos uno de los extremos, es decir, el origen o el receptor, debe ser un producto NoSQL de Oracle. No puede utilizar el NoSQL Database Migrator para mover los datos de la tabla NoSQL de un archivo a otro.
|
Tipo |
Formato |
Origen válido | Fregadero válido |
|---|---|---|---|
|
Oracle NoSQL Database |
NA | S | S |
|
Oracle NoSQL Database Cloud Service |
NA | S | S |
|
Sistema de archivos |
JSON |
S | S |
|
MongoDB JSON |
S | N | |
|
DynamoDB JSON |
S | N | |
|
Parquet( |
N | S | |
|
CSV |
S | N | |
|
OCI Object Storage |
JSON |
S | S |
|
MongoDB JSON |
S | N | |
|
Parquet( |
N | S | |
|
CSV |
S | N | |
| AWS S3 (en inglés) |
DynamoDB JSON |
S | N |
Note:
Muchos parámetros de configuración son comunes en la configuración de origen y receptor. Para facilitar la referencia, la descripción de dichos parámetros se repite para cada fuente y fregadero en las secciones de documentación, que explican los formatos de archivo de configuración para varios tipos de fuentes y fregaderos. En todos los casos, la sintaxis y la semántica de los parámetros con el mismo nombre son idénticas.Seguridad del origen y el receptor
Algunos de los tipos de fuente y receptor tienen información de seguridad opcional u obligatoria para fines de autenticación.
Todos los orígenes y receptores que utilizan servicios de Oracle Cloud Infrastructure (OCI) pueden utilizar determinados parámetros para proporcionar información de seguridad opcional. Esta información se puede proporcionar mediante un archivo de configuración de OCI o un principal de instancia.
Los orígenes y los receptores de Oracle NoSQL Database necesitan información de seguridad obligatoria si la instalación es segura y utiliza una autenticación basada en Oracle Wallet. Esta información se puede proporcionar agregando un archivo jar al directorio <MIGRATOR_HOME>/lib.
Autenticación basada en cartera
Si una instalación de Oracle NoSQL Database utiliza la autenticación basada en Oracle Wallet, debe incluir archivos jar adicionales que formen parte de la instalación de EE. Para obtener más información, consulte Oracle Wallet.
Sin los archivos jar, obtendrá el siguiente mensaje de error:
No se han encontrado kvstore-ee.jar y kvstore-ee-<version>.jar en el directorio lib. Copie kvstore-ee.jar y kvstore-ee-<version>.jar en el directorio lib
kvstore-ee.jar y kvstore-ee-<version>.jar del paquete del servidor EE en el directorio <MIGRATOR_HOME>/lib. <MIGRATOR_HOME> es el directorio nosql-migrator-M.N.O/ creado mediante la extracción del paquete Oracle NoSQL Database Migrator y M.N.O representa los números release.major.minor del software. Por ejemplo, nosql-migrator-1.1.0/lib.
Note:
La autenticación basada en cartera solo está soportada en Enterprise Edition (EE) de Oracle NoSQL Database.Identificación con principales de instancia
Los principales de instancia son una función de servicio IAM que permite que las instancias sean actores (o principales) autorizados que puedan realizar acciones en recursos de servicio. Cada una de las instancias informáticas tiene su propia identidad y se autentica con los certificados que tiene agregados.
Oracle NoSQL Database Migrator proporciona una opción para conectarse a una nube NoSQL y a orígenes y receptores de OCI Object Storage mediante la autenticación de principal de instancia. Solo está soportado cuando la herramienta NoSQL Database Migrator se utiliza en una instancia informática de OCI, por ejemplo, la herramienta NoSQL Database Migrator que se ejecuta en una máquina virtual alojada en OCI. Para activar esta función, utilice el atributo useInstancePrincipal del origen de nube NoSQL y del archivo de configuración de receptor. Para obtener más información sobre los parámetros de configuración para diferentes tipos de fuentes y receptores, consulte Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates (Plantillas de configuración de fregadero).
Para obtener más información sobre los principales de la instancia, consulte Llamada a servicios desde una Instancia.
Flujo de trabajo para Oracle NoSQL Database Migrator
Obtenga información sobre los distintos pasos necesarios para utilizar la utilidad Oracle NoSQL Database Migrator para migrar los datos de NoSQL.
El flujo de alto nivel de las tareas implicadas en el uso de NoSQL Database Migrator se muestra en la siguiente figura.
Descargue la utilidad de migración de datos NoSQL
runMigrator desde la interfaz de línea de comandos.
Note:
La utilidad Oracle NoSQL Database Migrator requiere la ejecución de Java 11 o versiones posteriores.Identificar el Origen y el Fregadero
- Identificar esquema de tabla de receptor: si el receptor es Oracle NoSQL Database local o en la nube, debe identificar el esquema de la tabla de receptor y asegurarse de que los datos de origen coinciden con el esquema de destino. Si es necesario, utilice transformaciones para asignar los datos de origen a la tabla de receptor.
- Esquema por defecto: NoSQL Database Migrator proporciona una opción para crear una tabla con el esquema por defecto sin necesidad de predefinir el esquema para la tabla. Esto resulta útil principalmente al cargar archivos de origen JSON en Oracle NoSQL Database.
Si el origen es un archivo JSON con formato MongoDB, el esquema por defecto de la tabla será el siguiente:
CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))Dónde:
- tablename = valor proporcionado para el atributo de tabla en la configuración.
- ID = valor _id de cada documento del archivo de origen JSON exportado mongoDB.
- DOCUMENT = Para cada documento del archivo exportado mongoDB, el contenido que excluye el campo _id se agrega a la columna DOCUMENT.
Si el origen es un archivo JSON con formato DynamoDB, el esquema por defecto de la tabla será el siguiente:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type],DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))Dónde:
- TABLE_NAME = valor proporcionado para la tabla de receptor en la configuración
- DDBPartitionKey_name = valor proporcionado para la clave de partición en la configuración
- DDBPartitionKey_type = valor proporcionado para el tipo de datos de la clave de partición en la configuración
- DDBSortKey_name = valor proporcionado para la clave de ordenación en la configuración si la hay
- DDBSortKey_type = valor proporcionado para el tipo de dato de la clave de ordenación en la configuración si existe
- DOCUMENT = Todos los atributos excepto la partición y la clave de ordenación de un elemento de tabla de base de datos Dynamo agregado a una columna JSON NoSQL
Si el formato de origen es un archivo CSV, no se admite un esquema por defecto para la tabla de destino. Puede crear un archivo de esquema con una definición de tabla que contenga el mismo número de columnas y tipos de datos que el archivo CSV de origen. Para obtener más información sobre la creación de archivos de esquema, consulte Proporcionar esquema de tabla.
Para todos los demás orígenes, el esquema por defecto será el siguiente:CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))Dónde:
- tablename = valor proporcionado para el atributo de tabla en la configuración.
- ID = Valor LONG generado automáticamente.
- DOCUMENT = El registro JSON proporcionado por el origen se agrega a la columna DOCUMENT.Note:
Si el valor _id no se proporciona como cadena en el archivo JSON con formato MongoDB, NoSQL Database Migrator lo convierte en una cadena antes de insertarlo en el esquema por defecto.
- Esquema por defecto: NoSQL Database Migrator proporciona una opción para crear una tabla con el esquema por defecto sin necesidad de predefinir el esquema para la tabla. Esto resulta útil principalmente al cargar archivos de origen JSON en Oracle NoSQL Database.
- Proporcionar esquema de tabla: NoSQL Database Migrator permite al origen proporcionar definiciones de esquema para los datos de tabla mediante el atributo schemaInfo. El atributo schemaInfo está disponible en todos los orígenes de datos que no tienen un esquema implícito ya definido. Los almacenes de datos del fregadero pueden elegir cualquiera de las siguientes opciones.
- Utilice el esquema por defecto definido por el NoSQL Database Migrator.
- Utilice el esquema proporcionado por el origen.
- Sustituya el esquema proporcionado por el origen definiendo su propio esquema. Por ejemplo, si desea transformar los datos del esquema de origen en otro esquema, debe sustituir el esquema proporcionado por el origen y utilizar la capacidad de transformación de la herramienta NoSQL Database Migrator.
El archivo de esquema de tabla, por ejemplo,mytable_schema.ddlpuede incluir sentencias DDL de tabla. La herramienta NoSQL Database Migrator ejecuta este archivo de esquema de tabla antes de iniciar la migración. La herramienta de migración no soporta más de una sentencia DDL por línea en el archivo de esquema. Por ejemplo,CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))Note:
La migración fallará si la tabla está presente en el receptor y el DDL enschemaPathes diferente de la tabla. - Crear tabla de receptor: una vez identificado el esquema de tabla de receptor, cree la tabla de receptor mediante la CLI de administrador o mediante el atributo
schemaInfodel archivo de configuración de receptor. Consulte Sink Configuration Templates.Note:
Si el origen es un archivo CSV, cree un archivo con los comandos DDL para el esquema de la tabla de destino. Proporcione la ruta del archivo en el parámetro schemaInfo.schemaPath del archivo de configuración del receptor.
Migración de metadatos de TTL para filas de tabla
El tiempo de actividad (TTL) es un mecanismo que permite hacer caducar automáticamente las filas de la tabla. El TTL se expresa como la cantidad de tiempo que los datos pueden estar activos en la tienda. Los datos que han alcanzado su valor de timeout de caducidad ya no se pueden recuperar y no aparecerán en ninguna estadística de almacén.
Tabla: Migración de metadatos de TTL
| Tipos de Origen | Parámetro de configuración de origen | Parámetro de configuración de fregadero |
|---|---|---|
| Oracle NoSQL Database | includeTTL |
includeTTL |
| Oracle NoSQL Database Cloud Service | includeTTL |
includeTTL |
| Archivo JSON con formato DynamoDB | ttlAttributeName |
includeTTL |
| Archivo JSON con formato DynamoDB almacenado en AWS S3 | ttlAttributeName |
includeTTL |
Exportación de metadatos TTL en Oracle NoSQL Database y Oracle NoSQL Database Cloud Service
NoSQL Database Migrator proporciona el parámetro de configuración includeTTL para soportar la exportación de metadatos TTL de la fila de tabla.
_metadata no se incluye explícitamente en los datos exportados porque su valor de caducidad es siempre 0. NoSQL Database Migrator exporta el tiempo de caducidad de cada fila como el número de milisegundos desde la época de UNIX (1 de enero de 1970). Por ejemplo,//Row 1
{
"id" : 1,
"name" : "xyz",
"age" : 45,
"_metadata" : {
"expiration" : 1629709200000 //Row Expiration time in milliseconds
}
}
//Row 2
{
"id" : 2,
"name" : "abc",
"age" : 52,
"_metadata" : {
"expiration" : 1629709400000 //Row Expiration time in milliseconds
}
}
//Row 3 No Metadata for below row as it will not expire
{
"id" : 3,
"name" : "def",
"age" : 15
}Importación de metadatos de TTL
Opcionalmente, puede importar metadatos de TTL mediante el parámetro de configuración includeTTL en la plantilla de configuración del receptor.
El tiempo de referencia predeterminado de la operación de importación es el tiempo actual en milisegundos, obtenido de System.currentTimeMillis(), de la máquina en la que se está ejecutando la herramienta NoSQL Database Migrator. Sin embargo, también puede definir un tiempo de referencia personalizado mediante el parámetro de configuración ttlRelativeDate si desea ampliar el tiempo de caducidad e importar filas que, de lo contrario, vencerían inmediatamente. La extensión se calcula de la siguiente manera y se agrega a la hora de caducidad.
Extended time = expiration time - reference timeLa operación de importación maneja los siguientes casos de uso al migrar filas de tabla que contienen metadatos TTL. Estos casos de uso solo son aplicables cuando el parámetro de configuración includeTTL está definido en true.
- Caso de uso 1: no hay información de metadatos TTL presente en la fila de la tabla de importación.
Si la fila que desea importar no contiene información de TTL, NoSQL Database Migrator define el TTL=0 para la fila.
- Caso de uso 2: el valor de TTL de la fila de la tabla de origen ha caducado en relación con el tiempo de referencia cuando se importa la fila de la tabla.
La fila de la tabla caducada se ignora y no se escribe en el almacén.
- Caso de uso 3: el valor de TTL de la fila de la tabla de origen no ha caducado en relación con el tiempo de referencia cuando se importa la fila de la tabla.
La fila de la tabla se importa con un valor TTL. Sin embargo, es posible que el valor de TTL importado no coincida con el valor de TTL exportado original debido a las restricciones de hora y día entero en la clase TimeToLive. Por ejemplo,
Considere una fila de tabla exportada:{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC } }La hora de referencia durante la importación es 1734480000000, que es el miércoles, 18 de diciembre de 2024 a las 12:00:00 a. m.
Fila de tabla importada{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1734739200000 //Saturday, December 21, 2024 12:00:00 AM } }
Importación de metadatos TTL en el archivo JSON con formato DynamoDB y en el archivo JSON con formato DynamoDB almacenado en AWS S3
NoSQL Database Migrator proporciona un parámetro de configuración adicional, ttlAttributeName, para soportar la importación de metadatos de TTL de los elementos de archivo JSON con formato DynamoDB.
Los archivos JSON exportados de DynamoDB incluyen un atributo específico en cada elemento para almacenar el registro de hora de caducidad de TTL. Para importar de manera opcional los valores de TTL de los archivos JSON exportados DynamoDB, debe proporcionar el nombre del atributo específico como valor para el parámetro de configuración ttlAttributeName en los archivos de configuración de origen DynamoDB-Formatted JSON File o DynamoDB-Formatted JSON File almacenados en los archivos de configuración de origen S3 de AWS. Además, debe definir el parámetro de configuración includeTTL en la plantilla de configuración del receptor. Los sumideros válidos son Oracle NoSQL Database y Oracle NoSQL Database Cloud Service. NoSQL Database Migrator almacena información de TTL en el objeto JSON _metadata para el elemento importado.
-
Caso de uso 1: el valor del parámetro de configuración ttlAttributeName se define en el nombre de atributo TTL especificado en el archivo JSON exportado DynamoDB.
NoSQL Database Migrator importa el tiempo de caducidad de este elemento como el número de milisegundos desde la época de UNIX (1 de enero de 1970).
Por ejemplo, considere un elemento en el archivo JSON exportado DynamoDB:{ "Item": { "DeptId": { "N": "1" }, "DeptName": { "S": "Engineering" }, "ttl": { "N": "1734616800" } } }En este caso, el atributottlespecifica el valor de tiempo de actividad del elemento. Si define el parámetro de configuración ttlAttributeName comottlen el archivo JSON con formato DynamoDB o en el archivo JSON con formato DynamoDB almacenado en el archivo de configuración de origen S3 de AWS, NoSQL Database Migrator importa el tiempo de caducidad del elemento de la siguiente manera:{ "DeptId": 1, "document": { "DeptName": "Engineering" } "_metadata": { "expiration": 1734616800000 } }Note:
Puede proporcionar el parámetro de configuración ttlRelativeDate en la plantilla de configuración del receptor como la hora de referencia para calcular la hora de caducidad. - Caso de uso 2: se define el valor del parámetro de configuración ttlAttributeName; sin embargo, el valor no existe como atributo en el elemento del archivo JSON exportado DynamoDB.
NoSQL Database Migrator no importa la información de metadatos de TTL para el elemento proporcionado.
- Caso de uso 3: el valor del parámetro de configuración ttlAttributeName no coincide con el nombre de atributo en el elemento del archivo JSON exportado DynamoDB.
NoSQL Database Migrator gestiona la importación de una de las siguientes maneras según la configuración del receptor:
- Copia el atributo como un campo normal si está configurado para importar mediante el esquema por defecto.
- Omite el atributo si está configurado para importar mediante un esquema definido por el usuario.
Importación de datos a un receptor con una columna IDENTITY
Puede importar los datos de un origen válido a una tabla de receptor (servicios locales/en la nube) con una columna IDENTITY. La columna IDENTITY se crea como GENERATED SIEMPRE COMO IDENTITY o GENERATED BY DEFAULT AS IDENTITY. Para obtener más información sobre la creación de tablas con una columna IDENTITY, consulte Creating Tables With an IDENTITY Column en la SQL Reference Guide.
Antes de importar los datos, asegúrese de que la tabla de Oracle NoSQL Database en el receptor esté vacía si existe. Si hay datos preexistentes en la tabla de receptor, la migración puede provocar problemas como sobrescribir los datos existentes en la tabla de receptor u omitir los datos de origen durante la importación.
Tabla de fregadero con la columna IDENTITY como GENERATED SIEMPRE AS IDENTITY
Considere una tabla de reducción con la columna IDENTITY creada como GENERATED SIEMPRE AS IDENTITY. La importación de datos depende de si el origen proporciona o no los valores a la columna IDENTITY y al parámetro de transformación ignoreFields en el archivo de configuración.
Por ejemplo, desea importar datos de un origen de archivo JSON a la tabla de Oracle NoSQL Database como receptor. El esquema de la tabla de receptor es:
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Condición de origen | Acción del Usuario | Resultado de migración |
|---|---|---|
|
CASO 1: Los datos de origen no proporcionan un valor para el campo IDENTITY de la tabla de receptores. Ejemplo: archivo de origen JSON |
Cree o genere el archivo de configuración. |
Migración de datos correcta. Los valores de la columna IDENTITY se generan automáticamente. Datos migrados en la tabla de receptor de Oracle NoSQL Database |
|
CASO 2: Los datos de origen proporcionan valores para el campo IDENTITY de la tabla de receptores. Ejemplo: archivo de origen JSON |
Cree o genere el archivo de configuración. Proporciona una transformación ignoreFields para la columna ID en la plantilla de configuración de receptor.
|
Migración de datos correcta. Los valores de ID proporcionados se omiten y los valores de columna IDENTITY se generan automáticamente. Datos migrados en la tabla de receptor de Oracle NoSQL Database
migrateID: |
|
Puede crear/generar el archivo de configuración sin la transformación ignoreFields para la columna IDENTITY. |
La migración de datos falla con el siguiente mensaje de error: "Cannot set value for a generated always identity column". |
Para obtener más información sobre los parámetros de configuración de transformación, consulte el tema Plantillas de configuración de transformación.
Tabla de fregadero con la columna IDENTITY como GENERATED BY DEFAULT AS IDENTITY
Considere una tabla de reducción con la columna IDENTITY creada como GENERATED BY DEFAULT AS IDENTITY. La importación de datos depende de si el origen proporciona o no los valores a la columna IDENTITY y al parámetro de transformación ignoreFields.
Por ejemplo, desea importar datos de un origen de archivo JSON a la tabla de Oracle NoSQL Database como receptor. El esquema de la tabla de receptor es:
CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
(ID))| Condición de origen | Acción del Usuario | Resultado de migración |
|---|---|---|
|
CASO 1: Los datos de origen no proporcionan un valor para el campo IDENTITY de la tabla de receptores. Ejemplo: archivo de origen JSON |
Cree o genere el archivo de configuración. |
Migración de datos correcta. Los valores de la columna IDENTITY se generan automáticamente. Datos migrados en la tabla de receptor de Oracle NoSQL Database
migrateID: |
|
CASO 2: Los datos de origen proporcionan valores para el campo IDENTITY de la tabla de receptor y es un campo Primary Key. Ejemplo: archivo de origen JSON |
Cree o genere el archivo de configuración. Proporcione una transformación ignoreFields para la columna de ID en la plantilla de configuración de receptor (Recomendado).
|
Migración de datos correcta. Los valores de ID proporcionados se omiten y los valores de columna IDENTITY se generan automáticamente. Datos migrados en la tabla de receptor de Oracle NoSQL Database
migrateID: |
|
Puede crear/generar el archivo de configuración sin la transformación ignoreFields para la columna IDENTITY. |
Migración de datos correcta. Los valores Cuando intenta insertar una fila adicional en la tabla sin proporcionar un valor de ID, el generador de secuencias intenta generar automáticamente el valor de ID. El valor inicial del generador de secuencias es 1. Como resultado, el valor de ID generado puede duplicar potencialmente uno de los valores de ID existentes en la tabla de receptor. Puesto que se trata de una violación de la restricción de clave primaria, se devuelve un error y la fila no se inserta. Consulte Sequence Generator para obtener más información. Para evitar la violación de la restricción de clave primaria, el generador de secuencias debe iniciar la secuencia con un valor que no entre en conflicto con los valores de ID existentes en la tabla de receptor. Para utilizar el atributo START WITH para realizar esta modificación, consulte el siguiente ejemplo: Ejemplo: datos migrados en la tabla de receptor
migrateID de Oracle NoSQL Database:Para buscar el valor adecuado para que el generador de secuencias lo inserte en la columna de ID, recupere el valor máximo del campo
ID mediante la siguiente consulta:Salida:
El valor máximo de la columna
ID en la tabla de receptor es 3. Desea que el generador de secuencias comience a generar los valores de ID más allá de 3 para evitar la duplicación. Actualice el atributo START WITH del generador de secuencias a 4 mediante la siguiente sentencia:Esto iniciará la secuencia en 4. Ahora, cuando inserta filas en la tabla de reducción sin proporcionar los valores de ID, el generador de secuencias genera automáticamente los valores de ID a partir de 4, evitando la duplicación de los IDs. |
Para obtener más información sobre los parámetros de configuración de transformación, consulte el tema Plantillas de configuración de transformación.
Ejecute el comando runMigrator
El archivo ejecutable runMigrator está disponible en los archivos NoSQL Database Migrator extraídos. Debe instalar Java 11 o una versión superior y bash en el sistema para ejecutar correctamente el comando runMigrator.
runMigrator de dos formas:
- Mediante la creación del archivo de configuración mediante las opciones de tiempo de ejecución del comando
runMigrator, como se muestra a continuación.[~]$ ./runMigrator configuration file is not provided. Do you want to generate configuration? (y/n) [n]: y ... ...- Al llamar a la utilidad
runMigrator, proporciona una serie de opciones de tiempo de ejecución y crea el archivo de configuración en función de las opciones que haya elegido para cada opción. - Una vez que la utilidad crea el archivo de configuración, tiene la opción de continuar con la actividad de migración en la misma ejecución o guardar el archivo de configuración para una migración futura.
- Independientemente de su decisión de continuar o diferir la actividad de migración con el archivo de configuración generado, el archivo estará disponible para ediciones o personalización para cumplir con sus requisitos futuros. Puede utilizar el archivo de configuración personalizado para la migración más adelante.
- Al llamar a la utilidad
- 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
-co--config. Debe crear el archivo de configuración manualmente antes de ejecutar el comandorunMigratorcon la opción-co--config. Para obtener ayuda con los parámetros de configuración de origen y receptor, consulte Referencia de Oracle NoSQL Database Migrator.[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
Note:
NoSQL Database Migrator consume unidades de lectura al realizar la exportación de datos de la tabla de Oracle NoSQL Cloud Service a cualquier disco válido.Progreso de Logging Migrator
La herramienta NoSQL Database Migrator proporciona opciones que permiten imprimir mensajes de rastreo, depuración y progreso en una salida estándar o en un archivo. Esta opción puede ser útil para realizar un seguimiento del progreso de la operación de migración, especialmente para tablas o juegos de datos muy grandes.
- Niveles de Log
Para controlar el comportamiento de registro mediante la herramienta NoSQL Database Migrator, transfiera el parámetro --log-level o -l de tiempo de ejecución al comando
runMigrator. Puede especificar la cantidad de información de log que desea escribir transfiriendo el valor de nivel de log adecuado.$./runMigrator --log-level <loglevel>Por ejemplo:$./runMigrator --log-level debugTabla: niveles de log soportados para NoSQL Database Migrator
Nivel de Log Descripción Advertencia Imprime errores y advertencias. info (por defecto) Imprime el estado de progreso de la migración de datos, como la validación del origen, la validación del receptor, la creación de tablas y el recuento del número de registros de datos migrados. debug Permite imprimir información adicional de depuración. all Imprime todo. Este nivel activa todos los niveles de registro. - Archivo Log:
Puede especificar el nombre del archivo log mediante el parámetro --log-file o -f. Si --log-file se transfiere como parámetro de tiempo de ejecución al comando
runMigrator, NoSQL Database Migrator escribe todos los mensajes de log en el archivo o en la salida estándar.$./runMigrator --log-file <log file name>Por ejemplo:$./runMigrator --log-file nosql_migrator.log
demostraciones de casos de uso para Oracle NoSQL Database Migrator
Descubra cómo realizar la migración de datos con Oracle NoSQL Database Migrator para casos de uso específicos. Puede encontrar instrucciones sistemáticas detalladas con ejemplos de código para realizar la migración en cada uno de los casos de uso.
En este artículo se incluyen los siguientes temas:
Migración de Oracle NoSQL Database Cloud Service a un archivo JSON
En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar datos y la definición de esquema de una tabla NoSQL de Oracle NoSQL Database Cloud Service (NDCS) en un archivo JSON.
Caso de uso
Una organización decide entrenar un modelo mediante los datos de Oracle NoSQL Database Cloud Service (NDCS) para predecir comportamientos futuros y proporcionar recomendaciones personalizadas. Pueden realizar una copia periódica de los datos de las tablas NDCS en un archivo JSON y aplicarla al motor de análisis para analizar y entrenar el modelo. Esto les ayuda a separar las consultas analíticas de las rutas críticas de baja latencia.
Ejemplo
Para la demostración, veamos cómo migrar la definición de datos y esquema de una tabla NoSQL denominadamyTable desde NDCS a un archivo JSON.- Identifique el origen y el sumidero de la migración.
- Origen: Oracle NoSQL Database Cloud Service
- Fregadero: archivo JSON
- Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración de OCI. Guarde el archivo de configuración en
/home/.oci/config. Consulte Adquisición de credenciales.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifique el punto final de región y el nombre del compartimento para Oracle NoSQL Database Cloud Service.
- punto final:
us-phoenix-1 - compartimento:
developers
- punto final:
myTable de Oracle NoSQL Database Cloud Service a un archivo JSON:
Para validar la migración, puede navegar hasta el directorio del receptor especificado y ver el esquema y los datos.
-- Exported myTable Data. JSON files are created in the supplied data path
[~/nosqlMigrator]$cat myTable_1_5.json
{
"id" : 10,
"document" : {
"course" : "Computer Science",
"name" : "Neena",
"studentid" : 105
}
}
{
"id" : 3,
"document" : {
"course" : "Computer Science",
"name" : "John",
"studentid" : 107
}
}
{
"id" : 4,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 6,
"document" : {
"course" : "Bio-Technology",
"name" : "Rekha",
"studentid" : 104
}
}
{
"id" : 7,
"document" : {
"course" : "Computer Science",
"name" : "Ruby",
"studentid" : 100
}
}
{
"id" : 5,
"document" : {
"course" : "Journalism",
"name" : "Rani",
"studentid" : 106
}
}
{
"id" : 8,
"document" : {
"course" : "Computer Science",
"name" : "Tom",
"studentid" : 103
}
}
{
"id" : 9,
"document" : {
"course" : "Computer Science",
"name" : "Peter",
"studentid" : 109
}
}
{
"id" : 1,
"document" : {
"course" : "Journalism",
"name" : "Tracy",
"studentid" : 110
}
}
{
"id" : 2,
"document" : {
"course" : "Bio-Technology",
"name" : "Raja",
"studentid" : 108
}
}-- Exported myTable Schema
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))Migración de Oracle NoSQL Database local a Oracle NoSQL Database Cloud Service
En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar datos y la definición de esquema de una tabla NoSQL de Oracle NoSQL Database a Oracle NoSQL Database Cloud Service (NDCS).
Caso de uso
Como desarrollador, está explorando opciones para evitar la sobrecarga de la gestión de recursos, clusters y recolección de basura para las cargas de trabajo KVStore de la base de datos NoSQL existentes. Como solución, decide migrar las cargas de trabajo locales existentes de KVStore a Oracle NoSQL Database Cloud Service porque NDCS las gestiona automáticamente.
Ejemplo
Para la demostración, veamos cómo migrar la definición de datos y esquema de una tabla NoSQL denominadamyTable de la base de datos NoSQL KVStore a NDCS. También utilizaremos este caso de uso para mostrar cómo ejecutar la utilidad runMigrator transfiriendo un archivo de configuración creado previamente.- Identifique el origen y el sumidero de la migración.
- Origen: Oracle NoSQL Database
- Fregadero: Oracle NoSQL Database Cloud Service
- Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración de OCI. Guarde el archivo de configuración en
/home/.oci/config. Consulte Adquisición de credenciales en Uso de Oracle NoSQL Database Cloud Service.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifique el punto final de región y el nombre del compartimento para Oracle NoSQL Database Cloud Service.
- punto final:
us-phoenix-1 - compartimento:
developers
- punto final:
- Identifique los siguientes detalles para KVStore local:
- storeName:
kvstore - helperHosts:
<hostname>:5000 - tabla:
myTable
- storeName:
myTable de la base de datos NoSQL KVStore a NDCS:
Para validar la migración, puede conectarse a la consola de NDCS y verificar que myTable se ha creado con los datos de origen.
Migración del origen de archivo JSON a Oracle NoSQL Database Cloud Service
En este ejemplo se muestra el uso de Oracle NoSQL Database Migrator para copiar datos de un origen de archivo JSON a Oracle NoSQL Database Cloud Service.
Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database Cloud Service como su plataforma de base de datos NoSQL. Dado que el contenido de origen está en formato de archivo JSON, están buscando una forma de migrarlo a Oracle NoSQL Database Cloud Service.
En este ejemplo, aprenderá a migrar los datos de un archivo JSON denominado SampleData.json. Ejecute la utilidad runMigrator transfiriendo un archivo de configuración creado previamente. Si el archivo de configuración no se proporciona como parámetro de tiempo de ejecución, la utilidad runMigrator le solicita que genere la configuración mediante un procedimiento interactivo.
- Identifique el origen y el sumidero de la migración.
- Fuente: Archivo de origen JSON.
SampleData.jsones el archivo de origen. Contiene varios documentos JSON con un documento por línea, delimitados por un nuevo carácter de línea.{"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-03-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-02T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-02T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-02T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":7,"val_json":{"array":["a","b","c"],"date":"2023-02-20T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-01-20T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-01-22T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} {"id":4,"val_json":{"array":["j","k","l"],"date":"2023-02-03T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-03T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-02-03T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}} - Fregadero: Oracle NoSQL Database Cloud Service.
- Fuente: Archivo de origen JSON.
- Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración. Guarde el archivo de configuración en
/home/user/.oci/config. Para obtener más información, consulte Adquisición de credenciales en Uso de Oracle NoSQL Database Cloud Service.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... region=us-ashburn-1 key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifique el punto final de región y el nombre del compartimento para Oracle NoSQL Database Cloud Service.
- punto final:
us-ashburn-1 - compartimento:
Training-NoSQL
- punto final:
- Identifique los siguientes detalles para el archivo de origen JSON:
-
schemaPath:
<absolute path to the schema definition file containing DDL statements for the NoSQL table at the sink>.En este ejemplo, el archivo DDL esschema_json.ddl.create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id));Oracle NoSQL Database Migrator proporciona una opción para crear una tabla con el esquema por defecto si no se proporciona
schemaPath. Para obtener más información, consulte el tema Identificación del origen y el fregadero en Flujo de trabajo para Oracle NoSQL Database Migrator. - Ruta de datos:
<absolute path to a file or directory containing the JSON data for migration>.
-
SampleData.json a Oracle NoSQL Database Cloud Service, realice lo siguiente:
Migrate_JSON se crea con los datos de origen. Para conocer el procedimiento de acceso a la consola, consulte el artículo sobre acceso al servicio desde la consola de Infrastructure en el documento Oracle NoSQL Database Cloud Service.
Figura - Tablas de la consola de Oracle NoSQL Database Cloud Service
Figura - Datos de la tabla de la consola de Oracle NoSQL Database Cloud Service
Migración de un archivo JSON MongoDB a Oracle NoSQL Database Cloud Service
En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar datos con formato Mongo-DB en Oracle NoSQL Database Cloud Service (NDCS).
Caso de uso
Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database Cloud Service como su plataforma de base de datos NoSQL. Como sus tablas y datos de NoSQL están en MongoDB, buscan una forma de migrar esas tablas y datos a Oracle NDCS.
Puede copiar un archivo o directorio que contenga los datos JSON exportados de MongoDB para la migración especificando el archivo o directorio en la plantilla de configuración de origen.
{"_id":0,"name":"Aimee Zank","scores":[{"score":1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}
MongoDB soporta dos tipos de extensiones en formato JSON de archivos: modo canónico y modo relajado. Puede proporcionar el archivo JSON con formato MongoDB generado mediante la herramienta mongoexport en modo canónico o relajado. Ambos modos están soportados por el NoSQL Database Migrator para la migración.
Para obtener más información sobre el archivo MongoDB Extended JSON (v2), consulte mongoexport_formats.
Para obtener más información sobre la generación del archivo JSON con formato MongoDB, consulte mongoexport.
Ejemplo
Para la demostración, veamos cómo migrar un archivo JSON con formato MongoDB a NDCS. Para este ejemplo, utilizaremos un archivo de configuración creado manualmente.- Identifique el origen y el sumidero de la migración.
- Origen: archivo JSON con formato MongoDB
- Fregadero: Oracle NoSQL Database Cloud Service
- Extraiga los datos de Mongo DB mediante la utilidad mongoexport. Consulte mongoexport para obtener más información.
- Cree una tabla NoSQL en el fregadero con un esquema de tabla que coincida con los datos del archivo JSON con formato Mongo-DB. Como alternativa, puede indicar al NoSQL Database Migrator que cree una tabla con la estructura de esquema por defecto definiendo el atributo
defaultSchemaen true.Note:
Para un origen MongoDB-Formatted JSON, el esquema por defecto de la tabla será el siguiente:CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))Dónde:tablename= valor de la configuración de la tabla.ID= valor_iddel archivo de origen JSON exportado mongoDB.DOCUMENT= todo el contenido del archivo de origen JSON exportado mongoDB se agrega a la columnaDOCUMENT, excluyendo el campo_id.
- Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración de OCI. Guardar el archivo de configuración en
/home/.oci/config. Consulte Adquisición de credenciales en Uso de Oracle NoSQL Database Cloud Service.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifique el punto final de región y el nombre del compartimento para Oracle NoSQL Database Cloud Service.
- punto final:
us-phoenix-1 - compartimento:
developers
- punto final:
Para migrar los datos JSON con formato MongoDB a Oracle NoSQL Database Cloud Service:
Para validar la migración, puede conectarse a la consola de NDCS y verificar que myTable se ha creado con los datos de origen.
Migración del archivo JSON DynamoDB a Oracle NoSQL Database
En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar el archivo JSON DynamoDB en NoSQL Database.
Caso de uso:
Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database en la base de datos DynamoDB. La organización desea migrar sus tablas y datos de DynamoDB a Oracle NoSQL Database (local).
Consulte Asignación de la tabla DynamoDB a la tabla NoSQL de Oracle para obtener más información.
Puede migrar un archivo o directorio que contenga los datos JSON exportados de DynamoDB desde un sistema de archivos especificando la ruta en la plantilla de configuración de origen.
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}
Copie los datos de la tabla DynamoDB exportada del almacenamiento S3 de AWS en un sistema de archivos montado local.
Por ejemplo:
Para esta demostración, aprenderá a migrar un archivo JSON DynamoDB a Oracle NoSQL Database (local). Para este ejemplo, utilizará un archivo de configuración creado manualmente.
Requisitos
- Identifique el origen y el sumidero de la migración.
- Origen: DynamoDB JSON File
- Sink: Oracle NoSQL Database (local)
- Para importar datos de la tabla DynamoDB a Oracle NoSQL Database, primero debe exportar la tabla DynamoDB a S3. Consulte los pasos proporcionados en Exportación de datos de tabla DynamoDB a Amazon S3 para exportar la tabla. Durante la exportación, seleccione el formato como DynamoDB JSON. Los datos exportados contienen datos de tabla DynamoDB en varios archivos
gzip, como se muestra a continuación./ 01639372501551-bb4dd8c3 |-- 01639372501551-bb4dd8c3 ==> exported data prefix |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started - Debe descargar los archivos de AWS S3. La estructura de los archivos después de la descarga será como se muestra a continuación.
download-dir/01639372501551-bb4dd8c3 |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started
Procedimiento
- Prepare el archivo de configuración (en formato JSON) con los detalles del origen y del receptor identificados. Para obtener detalles, consulte Source Configuration Templates y Sink Configuration Templates.
Note:
Si los elementos de tabla JSON exportados de DynamoDB contienen el atributo TTL, para importar opcionalmente los valores de TTL, especifique el atributo en el parámetro de configuración ttlAttributeName de la plantilla de configuración de origen y defina el parámetro de configuración includeTTL en true en la plantilla de configuración del receptor.Puede seleccionar una de estas dos opciones.- Opción 1: importación de la tabla DynamoDB como documento JSON mediante la configuración del esquema por defecto.
Aquí, definirá el parámetro de configuración defaultSchema en true. Por lo tanto, NoSQL Database Migrator crea el esquema por defecto en el receptor. Debe especificar el tipo de columna
DDBPartitionKeyy el tipo de columna NoSQL correspondiente. De lo contrario, se muestra un error.Para obtener más información sobre el esquema por defecto para un origen de JSON exportado DynamoDB, consulte el tema Identificación del origen y el fregadero en Flujo de trabajo para Oracle NoSQL Database Migrator.{ "source" : { "type" : "file", "format" : "dynamodb_json", "ttlAttributeName" : "ttl", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"], "table" : "sampledynDBImp", "includeTTL" : true, "schemaInfo" : { "DDBPartitionKey" : "Id:INTEGER", "defaultSchema" : true }, "overwrite" : true, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.6.5" }En este ejemplo se utiliza el siguiente esquema por defecto:CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) - Opción 2: importación de la tabla DynamoDB como columnas fijas mediante un archivo de esquema proporcionado por el usuario.
Aquí, definirá el parámetro de configuración defaultSchema en false. Por lo tanto, especifique el archivo que contiene la sentencia DDL de la tabla del receptor en el parámetro schemaPath. Consulte Asignación de tipos DynamoDB a tipos NoSQL de Oracle para obtener más información.
En este ejemplo se utiliza el siguiente esquema definido por el usuario:CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))NoSQL Database Migrator utiliza el archivo de esquema para crear la tabla en el receptor como parte de la migración. Siempre que se proporcionen los datos de clave primaria, se insertará el registro JSON de entrada. De lo contrario, se muestra un error.
Note:
- Si la tabla de base de datos Dynamo tiene un tipo de dato no soportado en NoSQL Database, la migración falla.
- Si los datos de entrada no contienen un valor para una columna concreta (que no sea la clave primaria), se utilizará el valor por defecto de la columna. El valor por defecto debe formar parte de la definición de columna al crear la tabla. Por ejemplo,
id INTEGER not null default 0. Si la columna no tiene una definición por defecto, se inserta SQL NULL si no se proporcionan valores para la columna. - Si está modelando la tabla DynamoDB como documento JSON, asegúrese de utilizar la transformación
AggregateFieldspara agregar datos de clave no primaria a una columna JSON. Para obtener detalles, consulte aggregateFields.
{ "source" : { "type" : "file", "format" : "dynamodb_json", "ttlAttributeName" : "ttl", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"], "table" : "sampledynDBImp", "includeTTL" : true, "schemaInfo" : { "schemaPath" : "<full path of the schema file with the DDL statement>" }, "overwrite" : true, "requestTimeoutMs" : 5000 }, "transforms": { "aggregateFields" : { "fieldName" : "document", "skipFields" : ["Id"] } }, "abortOnError" : true, "migratorVersion" : "1.6.5" }
- Opción 1: importación de la tabla DynamoDB como documento JSON mediante la configuración del esquema por defecto.
- Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator.
- Ejecute el comando
runMigratortransfiriendo archivos de configuración independientes para las opciones 1 y 2. Utilice la opción--configo-c../runMigrator --config <complete/path/to/the/JSON/config/file> - La utilidad continúa con la migración de datos, como se muestra en el siguiente ejemplo:
[INFO] creating source from given configuration: [INFO] source creation completed [INFO] creating sink from given configuration: [INFO] sink creation completed [INFO] creating migrator pipeline [INFO] [nosqldb sink] : start loading DDLs [INFO] [nosqldb sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id))) [INFO] [nosqldb sink] : completed loading DDLs [INFO] migration started [INFO] Start writing data to OnDB Sink [INFO] executing for source:DynamoSample [INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz [INFO] Writing data to OnDB Sink completed. [INFO] migration completed. Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0. Elapsed time: 0min 0sec 45ms Migration completed.
Validación
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoreSELECT * FROM sampledynDBImpSalida
_metadata para cada elemento importado.{"Id":102,"document":{"Address":{"City":"Wales","DoorNum":1024,"Street":"32 main","Zip":560014},"Age":48,"FavColors":["Blue"],"FavNumbers":[10],"FirstName":"John","LastName":"White","Phones":[["222-222"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}
{"Id":101,"document":{"Address":{"City":"London","DoorNum":201,"Street":"21 main","Zip":570004},"Age":22,"FavColors":["Red","Green"],"FavNumbers":[10],"FirstName":"Fred","LastName":"Smith","Phones":[["555-222","123-567"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}Migración del archivo JSON DynamoDB en AWS S3 a Oracle NoSQL Database Cloud Service
En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator para copiar el archivo JSON DynamoDB almacenado en un almacén S3 de AWS en Oracle NoSQL Database Cloud Service (NDCS).
Caso de uso:
Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database Cloud Service con una base de datos DynamoDB. La organización desea migrar sus tablas y datos de DynamoDB a Oracle NoSQL Database Cloud Service.
Consulte Asignación de la tabla DynamoDB a la tabla NoSQL de Oracle para obtener más información.
Puede migrar un archivo que contenga los datos JSON exportados de DynamoDB desde el almacenamiento S3 de AWS especificando la ruta en la plantilla de configuración de origen.
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"}}}
La tabla DynamoDB se exporta al almacenamiento S3 de AWS como se especifica en Exportación de datos de tabla DynamoDB a Amazon S3.
Por ejemplo:
Para esta demostración, aprenderá a migrar un archivo JSON DynamoDB en un origen S3 de AWS a NDCS. Para este ejemplo, utilizará un archivo de configuración creado manualmente.
Requisitos
- Identifique el origen y el sumidero de la migración.
- Origen: DynamoDB JSON File en AWS S3
- Disipador: Oracle NoSQL Database Cloud Service
- Identifique la tabla de AWS DynamoDB que se debe migrar a NDCS. Inicie sesión en la consola de AWS con sus credenciales. Vaya a DynamoDB. En Tablas, seleccione la tabla que desea migrar.
- Cree un cubo de objeto y exporte la tabla a S3. Desde la consola de AWS, vaya a S3. En cubos, cree un nuevo cubo de objeto. Vuelva a DynamoDB y haga clic en Exportaciones a S3. Proporcione la tabla de origen y el cubo S3 de destino y haga clic en Exportar.
Consulte los pasos proporcionados en Exportación de datos de la tabla DynamoDB a Amazon S3 para exportar la tabla. Durante la exportación, seleccione el formato como DynamoDB JSON. Los datos exportados contienen datos de la tabla DynamoDB en varios archivos
gzip, como se muestra a continuación./ 01639372501551-bb4dd8c3 |-- 01639372501551-bb4dd8c3 ==> exported data prefix |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started - Necesita credenciales aws (incluidos el ID de clave de acceso y la clave de acceso secreta) y archivos de configuración (credenciales y, opcionalmente, configuración) para acceder a AWS S3 desde el migrator. Consulte Set and view configuration settings para obtener más información sobre los archivos de configuración. Consulte Creación de un par de claves para obtener más información sobre la creación de claves de acceso.
- Identifique sus credenciales de OCI en la nube y capturelas en el archivo de configuración de OCI. Guarde el archivo de configuración en el directorio
.ocidel directorio raíz (~/.oci/config). Consulte Consulta de credenciales para obtener más información.[DEFAULT] tenancy=ocid1.tenancy.oc1.... user=ocid1.user.oc1.... fingerprint= 43:d1:.... key_file=</fully/qualified/path/to/the/private/key/> pass_phrase=<passphrase> - Identifique el punto final de la región y el nombre del compartimento para Oracle NoSQL Database. Por ejemplo,
- punto final: us-phoenix-1
- compartimento: desarrolladores
Procedimiento
- Prepare el archivo de configuración (en formato JSON) con los detalles del origen y del receptor identificados. Para obtener detalles, consulte Source Configuration Templates y Sink Configuration Templates.
Note:
Si los elementos del archivo JSON DynamoDB de AWS S3 contienen el atributo TTL, para importar opcionalmente los valores de TTL, especifique el atributo en el parámetro de configuración ttlAttributeName de la plantilla de configuración de origen y defina el parámetro de configuración includeTTL en true en la plantilla de configuración del receptor. Para obtener más información, consulte Migración de metadatos TTL para filas de tabla.Puede seleccionar una de estas dos opciones.- Opción 1: importación de la tabla DynamoDB como documento JSON mediante la configuración del esquema por defecto.
Aquí, defaultSchema es
TRUEy, por lo tanto, el migrador crea el esquema por defecto en el fregadero. Debe especificar el tipo de columna DDBPartitionKey y el tipo de columna NoSQL correspondiente. De lo contrario, se devuelve un error.{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : true, "readUnits" : 100, "writeUnits" : 60, "DDBPartitionKey" : "<PrimaryKey:Datatype>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "abortOnError" : true, "migratorVersion" : "1.6.5" }Para un origen JSON DynamoDB, el esquema por defecto de la tabla será el que se muestra a continuación:CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, [DDBSortKey_name DDBSortKey_type], DOCUMENT JSON, PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))Dónde
TABLE_NAME = valor proporcionado para la 'tabla' del receptor en la configuración
DDBPartitionKey_name = valor proporcionado para la clave de partición en la configuración
DDBPartitionKey_type = valor proporcionado para el tipo de datos de la clave de partición en la configuración
DDBSortKey_name = valor proporcionado para la clave de ordenación en la configuración si la hay
DDBSortKey_type = valor proporcionado para el tipo de dato de la clave de ordenación en la configuración si existe
DOCUMENT = Todos los atributos excepto la partición y la clave de ordenación de un elemento de tabla de base de datos de Dynamo agregado a una columna JSON NoSQL
- Opción 2: importación de la tabla DynamoDB como columnas fijas mediante un archivo de esquema proporcionado por el usuario.
Aquí, defaultSchema es
FALSEy se especifica schemaPath como un archivo que contiene la sentencia DDL. Para obtener más información, consulte Asignación de tipos DynamoDB a tipos NoSQL de Oracle para obtener más información.Note:
Si la tabla de base de datos Dynamo tiene un tipo de datos que no está soportado en NoSQL, la migración falla.Un ejemplo de archivo de esquema se muestra a continuación.CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, PRIMARY KEY(SHARD(AccountId)));El archivo de esquema se utiliza para crear la tabla en el receptor como parte de la migración. Siempre que se proporcionen los datos de clave primaria, se insertará el registro JSON de entrada; de lo contrario, se devolverá un error.Note:
- Si los datos de entrada no contienen un valor para una columna concreta (que no sea la clave primaria), se utilizará el valor por defecto de la columna. El valor por defecto debe formar parte de la definición de columna al crear la tabla. Por ejemplo,
id INTEGER not null default 0. Si la columna no tiene una definición por defecto, se inserta SQL NULL si no se proporcionan valores para la columna. - Si está modelando la tabla DynamoDB como documento JSON, asegúrese de utilizar la transformación
AggregateFieldspara agregar datos de clave no primaria a una columna JSON. Para obtener detalles, consulte aggregateFields.
{ "source" : { "type" : "aws_s3", "format" : "dynamodb_json", "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>", "credentials" : "</path/to/aws/credentials/file>", "credentialsProfile" : <"profile name in aws credentials file"> }, "sink" : { "type" : "nosqldb_cloud", "endpoint" : "<region_name>", "table" : "<table_name>", "compartment" : "<compartment_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "credentials" : "<complete/path/to/the/oci/config/file>", "credentialsProfile" : "DEFAULT", "writeUnitsPercent" : 90, "requestTimeoutMs" : 5000 }, "transforms": { "aggregateFields" : { "fieldName" : "document", "skipFields" : ["AccountId"] } }, "abortOnError" : true, "migratorVersion" : "1.6.5" } - 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,
- Opción 1: importación de la tabla DynamoDB como documento JSON mediante la configuración del esquema por defecto.
- Abra el símbolo del sistema y navegue hasta el directorio donde extrajo la utilidad Database Migrator NoSQL.
- Ejecute el comando
runMigratortransfiriendo el archivo de configuración mediante la opción--configo-c.[~/nosqlMigrator]$./runMigrator --config <complete/path/to/the/JSON/config/file> - La utilidad continúa con la migración de datos, como se muestra a continuación.
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
Validación
Puede conectarse a la consola de NDCS y verificar que la nueva tabla se ha creado con los datos de origen.
Migre entre regiones de Oracle NoSQL Database Cloud Service
En este ejemplo se muestra el uso de Oracle NoSQL Database Migrator para realizar la migración entre regiones.
Ejemplo
Una organización utiliza Oracle NoSQL Database Cloud Service para almacenar y gestionar sus datos. Decide replicar datos de una región existente en una región más reciente para realizar pruebas antes de que se pueda iniciar la nueva región para el entorno de producción.
En este caso de uso, aprenderá a utilizar el NoSQL Database Migrator para copiar datos de la tabla user_data de la región Ashburn en la región Phoenix.
Ejecute la utilidad runMigrator transfiriendo un archivo de configuración creado previamente. Si no proporciona el archivo de configuración como parámetro de tiempo de ejecución, la utilidad runMigrator le solicita que genere la configuración mediante un procedimiento interactivo.
- Descargue Oracle NoSQL Database Migrator de la página Descargas de Oracle NoSQL y extraiga el contenido de su máquina. Para obtener más información, consulte Flujo de trabajo para Oracle NoSQL Database Migrator.
- Identifique el origen y el sumidero de la migración.
- Origen: tabla
user_dataen la región Ashburn.La tablauser_dataincluye los siguientes datos:{"id":40,"firstName":"Joanna","lastName":"Smith","otherNames":[{"first":"Joanna","last":"Smart"}],"age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085},"connections":[70,30,40],"email":"joanna.smith123@reachmail.com","communityService":"**"} {"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"Good"},{"first":"Johny2","last":"Brave"},{"first":"Johny3","last":"Kind"},{"first":"Johny4","last":"Humble"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"email":"john.smith@reachmail.com","communityService":"****"} {"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"BeGood"}],"age":22,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"email":"jane.smith201@reachmail.com","communityService":"*****"} {"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"BeGood"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"email":"adam.smith201reachmail.com","communityService":"***"}Identifique el punto final de región o el punto final de servicio y el nombre de compartimento para el origen.- punto final:
us-ashburn-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- punto final:
- Fregadero: tabla
user_dataen la región Phoenix.Identifique el punto final de región o el punto final de servicio y el nombre del compartimento para el receptor.- punto final:
us-phoenix-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identificar el esquema de la tabla de receptor.
Puede utilizar el mismo nombre de tabla y esquema que la tabla de origen. Para obtener información sobre otras opciones de esquema, consulte el tema Identificación del origen y el fregadero en Flujo de trabajo para Oracle NoSQL Database Migrator
- punto final:
- Origen: tabla
- Identifique sus credenciales de OCI en la nube para ambas regiones y capturelas en el archivo de configuración. Guarde el archivo de configuración en la máquina en la ubicación
/home/<user>/.oci/config. Para obtener más información, consulte Adquisición de credenciales.
Note:
- Si las regiones están en arrendamientos diferentes, debe proporcionar perfiles diferentes en el archivo
/home/<user>/.oci/configcon las credenciales de nube de OCI adecuadas para cada uno de ellos. - Si las regiones están en el mismo arrendamiento, puede tener un único perfil en el archivo
/home/<user>/.oci/config.
En este ejemplo, las regiones están en arrendamientos diferentes. El perfil DEFAULT incluye credenciales de OCI para la región Ashburn y DEFAULT2 incluye credenciales de OCI para la región Phoenix.
endpoint del archivo de configuración del migrator (tanto plantillas de configuración de origen como de receptor), puede proporcionar la URL de punto final de servicio o el ID de región de las regiones. Para obtener la lista de regiones de datos soportadas para Oracle NoSQL Database Cloud Service y sus URL de punto final de servicio, consulte Regiones de datos y URL de servicio asociadas en el documento Oracle NoSQL Database Cloud Service.[DEFAULT]
user=ocid1.user.oc1....
fingerprint=fd:96:....
tenancy=ocid1.tenancy.oc1....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=abcd
[DEFAULT2]
user=ocid1.user.oc1....
fingerprint=1b:68:....
tenancy=ocid1.tenancy.oc1....
region=us-phoenix-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=23456user_data de la región Ashburn a la región Phoenix, realice lo siguiente:
Para validar la migración, puede conectarse a la consola de Oracle NoSQL Database Cloud Service en la región Phoenix. Verifique que los datos de origen de la tabla user_data de la región Ashburn se copian en la tabla user_data de esta región. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure.
Migre de Oracle NoSQL Database Cloud Service a OCI Object Storage
En este ejemplo se muestra el uso de Oracle NoSQL Database Migrator desde Cloud Shell.
Caso de uso
Una empresa emergente planea utilizar Oracle NoSQL Database Cloud Service como su solución de almacenamiento de datos. La compañía desea utilizar Oracle NoSQL Database Migrator para copiar datos de una tabla de Oracle NoSQL Database Cloud Service en OCI Object Storage para realizar copias de seguridad periódicas de sus datos. Como medida rentable, desean ejecutar la utilidad NoSQL Database Migrator desde Cloud Shell, a la que pueden acceder todos los usuarios de OCI.
En este caso de uso, aprenderá a copiar la utilidad NoSQL Database Migrator a Cloud Shell en la región suscrita y a realizar una migración de datos. Puede migrar los datos de origen de la tabla de Oracle NoSQL Database Cloud Service a un archivo JSON en OCI Object Storage.
Ejecute la utilidad runMigrator transfiriendo un archivo de configuración creado previamente. Si no proporciona el archivo de configuración como parámetro de tiempo de ejecución, la utilidad runMigrator le solicita que genere la configuración mediante un procedimiento interactivo.
- Descargue Oracle NoSQL Database Migrator de la página Descargas de Oracle NoSQL en su máquina local.
- Inicie Cloud Shell desde el menú Herramientas de desarrollador de la consola en la nube. El explorador web abre el directorio de inicio. Haga clic en el menú de Cloud Shell en la esquina superior derecha de la ventana de Cloud Shell y seleccione la opción de carga en la lista desplegable. En la ventana emergente, arrastre y suelte el paquete de Oracle NoSQL Database Migrator desde la máquina local o haga clic en la opción Seleccionar de la computadora, seleccione el paquete de la máquina local y haga clic en el botón Cargar. También puede arrastrar y soltar el paquete Oracle NoSQL Database Migrator directamente desde la máquina local al directorio raíz de Cloud Shell. Extraiga el contenido del paquete.
- Identifique el origen y el receptor de la copia de seguridad.
-
Origen: tabla
NDCSuploaden la región Oracle NoSQL Database Cloud Service Ashburn.Para la demostración, tenga en cuenta los siguientes datos en la tablaNDCSupload:{"id":1,"name":"Jane Smith","email":"iamjane@somemail.co.us","age":30,"income":30000.0} {"id":2,"name":"Adam Smith","email":"adam.smith@mymail.com","age":25,"income":25000.0} {"id":3,"name":"Jennifer Smith","email":"jenny1_smith@mymail.com","age":35,"income":35000.0} {"id":4,"name":"Noelle Smith","email":"noel21@somemail.co.us","age":40,"income":40000.0}Identifique el punto final y el ID de compartimento para el origen. Para el punto final, puede proporcionar el identificador de región o el punto final de servicio. Para obtener la lista de regiones de datos soportadas en Oracle NoSQL Database Cloud Service, consulte Regiones de datos y URL de servicio asociadas.
- punto final:
us-ashburn-1 - ID de compartimento:
ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
- punto final:
-
Sink: archivo JSON en el cubo de OCI Object Storage.
Identifique el punto final de región, el espacio de nombres, el cubo y el prefijo para OCI Object Storage. Para obtener más información, consulte Acceso a Oracle Cloud Object Storage. Para obtener una lista de los puntos finales del servicio OCI Object Storage, consulte Puntos finales de Object Storage.
- punto final:
us-ashburn-1 - cubo:
Migrate_oci - prefijo:
Delegation - espacio de nombres: <> Si no proporciona un espacio de nombres, la utilidad utiliza el espacio de nombres por defecto del arrendamiento.
Note:
Si el cubo de almacenamiento de objetos está en un compartimento diferente, asegúrese de que tiene los privilegios para escribir objetos en el cubo. Para obtener más información sobre la configuración de las políticas, consulte Escritura de objetos en Object Storage. - punto final:
-
NDCSupload de Oracle NoSQL Database Cloud Service en un archivo JSON en el cubo de OCI Object Storage mediante Cloud Shell, realice lo siguiente:
Para validar la copia de seguridad de datos, conéctese a la consola de Oracle NoSQL Database Cloud Service. Navegue por los menús, Storage > Object Storage & Archive Storage > Buckets. Acceda a los archivos desde el directorio NDCSupload/Delegation en el cubo Migrate_oci. Para conocer el procedimiento para acceder a la consola, consulte el artículo Acceso al servicio desde la consola de Infrastructure.
Migración de OCI Object Storage a Oracle NoSQL Database Cloud Service mediante la autenticación de OKE
En este ejemplo se muestra cómo utilizar Oracle NoSQL Database Migrator con la autenticación de identidad de carga de trabajo de OKE para copiar datos de un archivo JSON en la tabla OCI Object Storage a Oracle NoSQL Database Cloud Service.
Casos prácticos
Como desarrollador, está explorando una opción para restaurar datos de un archivo JSON en el cubo de OCI Object Storage (SO OCI) a la tabla de Oracle NoSQL Database Cloud Service (NDCS) mediante NoSQL Database Migrator en una aplicación en contenedores. Una aplicación en contenedores es un entorno virtualizado que agrupa la aplicación y todas sus dependencias (como bibliotecas, binarios y archivos de configuración) en un paquete. Esto permite que la aplicación se ejecute de forma consistente en los distintos entornos, independientemente de la infraestructura subyacente.
Desea ejecutar NoSQL Database Migrator en un pod de Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). Para acceder de forma segura a los servicios del sistema operativo OCI y NDCS desde el pod de OKE, utilizará el método de autenticación de identidad de carga de trabajo (WIA).
En esta demostración, creará una imagen de docker para el NoSQL Database Migrator, copiará la imagen en un repositorio de Container Registry, creará un cluster de OKE y desplegará la imagen del migrador en el pod de cluster de OKE para ejecutar la utilidad Migrator. Aquí, proporcionará un archivo de configuración de NoSQL Database Migrator creado manualmente para ejecutar la utilidad Migrator como una aplicación en contenedores.
- Identifique el origen y el sumidero de la migración.
- Origen: archivo de esquema y archivos JSON en el cubo del sistema operativo OCI.
Identifique el punto final de región, el espacio de nombres, el cubo y el prefijo del cubo del sistema operativo OCI en el que están disponibles los archivos JSON y el esquema de origen. Para obtener más información, consulte Acceso al almacenamiento de objetos de Oracle Cloud. Para obtener la lista de puntos finales del servicio del sistema operativo OCI, consulte Puntos finales de Object Storage.
- punto final:
us-ashburn-1 - cubo:
Migrate_oci - prefijo:
userSession - espacio de nombres:
idhkv1iewjzjEl nombre del espacio de nombres de un cubo es el mismo que el espacio de nombres de su arrendamiento y se genera automáticamente cuando se crea su arrendamiento. Puede obtener el nombre del espacio de nombres de la siguiente manera:- En la consola de Oracle NoSQL Database Cloud Service, vaya a Almacenamiento> Cubos.
- Seleccione Compartimento en Ámbito de lista y seleccione el cubo. La página Detalles de cubo muestra el nombre en el parámetro Espacio de nombres.
Si no proporciona un nombre de espacio de nombres del sistema operativo OCI, la utilidad Migrator utiliza el espacio de nombres por defecto del arrendamiento.
- punto final:
- Fregadero: tabla
usersen Oracle NoSQL Database Cloud Service.Identifique el punto final de región o el punto final de servicio y el nombre del compartimento para el fregadero:
- punto final:
us-ashburn-1 - compartimento:
ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma
Identifique el esquema de tabla de receptor:
Para utilizar el nombre de tabla y el esquema almacenados en el cubo del sistema operativo OCI, defina el parámetro useSourceSchema en true. Para obtener más información sobre otras opciones de esquema, consulte el tema Identificar el origen y el fregadero en Flujo de trabajo para el migrador de Oracle NoSQL Database.
Note:
Asegúrese de tener los privilegios de escritura en el compartimento en el que va a restaurar los datos en la tabla de NDCS. Para obtener más información, consulte Gestión de compartimentos. - punto final:
- Origen: archivo de esquema y archivos JSON en el cubo del sistema operativo OCI.
- Prepare una imagen de Docker para el NoSQL Database Migrator y muévala a Container Registry.
- Obtenga el espacio de nombres del arrendamiento desde la consola de OCI.
Conéctese a la consola de Oracle NoSQL Database Cloud Service. En la barra de navegación, seleccione el menú Perfil y, a continuación, seleccione Arrendamiento: <Nombre de Tenany>.
Copie el nombre del espacio de nombres de Object Storage, que es el espacio de nombres de arrendamiento, en el portapapeles.
- Cree una imagen de Docker para la utilidad Migrator.
Navegue hasta el directorio donde extrajo la utilidad NoSQL Database Migrator. El paquete Migrator incluye un archivo docker denominado Dockerfile. Desde una interfaz de comandos, utilice el siguiente comando para crear una imagen de Docker de la utilidad Migrator:
#Command: docker build -t nosqlmigrator:<tag> .#Example: docker build -t nosqlmigrator:1.0 .Puede especificar un identificador de versión para la imagen de Docker en la opcióntag. Compruebe la imagen de Docker mediante el comando:#Command: Docker images#Example output ------------------------------------------------------------------------------------------ REPOSITORY TAG IMAGE ID CREATED SIZE localhost/nosqlmigrator 1.0 e1dcec27a5cc 10 seconds ago 487 MB quay.io/podman/hello latest 83fc7ce1224f 10 months ago 580 kB docker.io/library/openjdk 17-jdk-slim 8a3a2ffec52a 2 years ago 406 MB ------------------------------------------------------------------------------------------ - Genere un token de autorización.
Necesita un token de autenticación para conectarse a Container Registry y almacenar la imagen de Docker del migrador. Si aún no tiene un token de autenticación, debe generar uno. Para obtener más información, consulte Obtención de un token de autenticación.
- Almacene la imagen de Docker del migrador en Container Registry.
Para acceder a la imagen de Docker del migrador desde el pod de Kubernetes, debe almacenar la imagen en cualquier registro público o privado. Por ejemplo, Docker, Artifact Hub, OCI Container Registry, etc. son algunos registros. En esta demostración, se utiliza Container Registry. Para obtener más información, consulte Visión general de Container Registry.
- Desde la consola de OCI, cree un repositorio en Container Registry. Para obtener más información, consulte Creación de un repositorio.
Para esta demostración, cree el repositorio
okemigrator.Figura - Repositorio en Container Registry
- Inicie sesión en Container Registry desde la interfaz de comandos con el siguiente comando:
#Command: docker login <region-key>.ocir.io -u <tenancy-namespace>/<user name>password: <Auth token>#Example: docker login iad.ocir.io -u idhx..xxwjzj/rx..xxxxh@oracle.com password: <Auth token>#Output: Login Succeeded!En el comando anterior,
region-key: especifica la clave para la región en la que está utilizando Container Registry. Para obtener más información, consulte Disponibilidad por región.tenancy-namespace: especifica el espacio de nombres de arrendamiento que ha copiado de la consola de OCI.user name: especifica el nombre de usuario de la consola de OCI.password: especifica el token de autenticación. - Etiquete y transfiera la imagen de Docker del migrador a Container Registry mediante los siguientes comandos:
#Command: docker tag <Migrator Docker image> <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag> docker push <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>#Example: docker tag localhost/nosqlmigrator:1.0 iad.ocir.io/idhx..xxwjzj/okemigrator:1.0 docker push iad.ocir.io/idhx..xxwjzj/okemigrator:1.0En el comando anterior,
repo: especifica el nombre del repositorio que ha creado en Container Registry.tag: especifica el identificador de versión para la imagen de Docker.#Output: Getting image source signatures Copying blob 0994dbbf9a1b done | Copying blob 37849399aca1 done | Copying blob 5f70bf18a086 done | Copying blob 2f263e87cb11 done | Copying blob f941f90e71a8 done | Copying blob c82e5bf37b8a done | Copying blob 2ad58b3543c5 done | Copying blob 409bec9cdb8b done | Copying config e1dcec27a5 done | Writing manifest to image destination
- Desde la consola de OCI, cree un repositorio en Container Registry. Para obtener más información, consulte Creación de un repositorio.
- Obtenga el espacio de nombres del arrendamiento desde la consola de OCI.
- Configurar un cluster de OKE con WIA a NDCS y OCI OS.
- Crear un clúster de Kubernetes mediante OKE.
Desde la consola de OCI, defina y cree un cluster de Kubernetes basado en la disponibilidad de los recursos de red mediante OKE. Necesita un cluster de Kubernetes para ejecutar la utilidad Migrator como una aplicación en contenedores. Para obtener más información sobre la creación de clusters, consulte Creación de clusters de Kubernetes mediante flujos de trabajo de consola.
Para esta demostración, puede crear un cluster gestionado de un solo nodo mediante el flujo de trabajo Creación rápida que se detalla en el enlace anterior.
Figura - Cluster de Kubernetes para el contenedor del migrador
- Configure WIA desde la consola de OCI para acceder a otros recursos de OCI desde el cluster de Kubernetes.
Para otorgar acceso a la utilidad Migrator al cubo del sistema operativo NDCS y OCI mientras se ejecuta desde los pods de cluster de Kubernetes, debe configurar WIA. Realice los siguientes pasos:
- Configure el archivo de configuración kubeconfig del cluster.
- Desde la consola de OCI, abra el cluster de Kubernetes que ha creado y haga clic en el botón Acceder a cluster.
- En el cuadro de diálogo Acceso al cluster, haga clic en Acceso a Cloud Shell.
- Haga clic en Iniciar Cloud Shell para mostrar la ventana de Cloud Shell.
- Ejecute el comando de interfaz de línea de comandos de Oracle Cloud Infrastructure para configurar el archivo kubeconfig Puede copiar el comando desde el cuadro de diálogo Access Your Cluster. Puede esperar la siguiente salida:
#Example: oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aaa...muqzq --file $HOME/.kube/config --region us-ashburn-1 --token-version 2.0.0 --kube-endpoint PUBLIC_ENDPOINT#Output: New config written to the Kubeconfig file /home/<user>/.kube/config
- Copie el OCID del cluster de la opción
cluster-iddel comando anterior y guárdelo para utilizarlo en otros pasos.ocid1.cluster.oc1.iad.aaa...muqzq - Cree un espacio de nombres para la cuenta de servicio de Kubernetes mediante el siguiente comando en la ventana de Cloud Shell:
#Command: kubectl create namespace <namespace-name>#Example: kubectl create namespace migrator#Output: namespace/migrator created - Cree una cuenta de servicio de Kubernetes para la aplicación Migrator en un espacio de nombres mediante el siguiente comando en la ventana de Cloud Shell:
#Command: kubectl create serviceaccount <service-account-name> --namespace <namespace-name>#Example: kubectl create serviceaccount migratorsa --namespace migrator#Output: serviceaccount/migratorsa created - Defina una política de IAM desde la consola de OCI para permitir que la carga de trabajo acceda a los recursos de OCI desde el cluster de Kubernetes.
Desde la consola de OCI, navegue por los menús Identidad y seguridad > Identidad > Políticas. Cree las siguientes políticas para permitir el acceso a los recursos
nosql-familyyobject-family. Utilice el OCID del cluster, el espacio de nombres y los valores de cuenta de servicio de los pasos anteriores.#Command: Allow <subject> to <verb> <resource-type> in <location> where <conditions>#Example: Allow any-user to manage nosql-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'} Allow any-user to manage object-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}Para obtener más información sobre la creación de políticas, consulte Uso de la consola para crear políticas.
- Configure el archivo de configuración kubeconfig del cluster.
- Crear un clúster de Kubernetes mediante OKE.
Para migrar del archivo JSON del cubo del sistema operativo OCI a la tabla NDCS, realice lo siguiente desde la ventana de Cloud Shell:
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.
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.
- Identifique el origen y el receptor de la migración.
- Origen: tabla
usersen Oracle NoSQL Database. - Fregadero: archivo JSON en el cubo del sistema operativo OCI
Identifique el punto final, el espacio de nombres, el cubo y el prefijo de la región para el sistema operativo OCI. Para obtener más información, consulte Acceso al almacenamiento de objetos de Oracle Cloud. Para obtener la lista de puntos finales del servicio del sistema operativo OCI, consulte Puntos finales de Object Storage.
- punto final:
us-ashburn-1 - cubo:
Migrate_oci - prefijo:
userSession - espacio de nombres:
idhkv1iewjzjEl nombre del espacio de nombres de un cubo es el mismo que el espacio de nombres de su arrendamiento y se genera automáticamente cuando se crea su arrendamiento. Puede obtener el nombre del espacio de nombres de la siguiente manera:- En la consola de Oracle NoSQL Database Cloud Service, vaya a Almacenamiento> Cubos.
- Seleccione Compartimento en Ámbito de lista y seleccione el cubo. La página Detalles de cubo muestra el nombre en el parámetro Espacio de nombres.
Si no proporciona un nombre de espacio de nombres del sistema operativo OCI, la utilidad Migrator utiliza el espacio de nombres por defecto del arrendamiento.
Note:
Asegúrese de que tiene privilegios para escribir objetos en el cubo del sistema operativo OCI. Para obtener más información sobre la configuración de las políticas, consulte Escritura en Object Storage. - punto final:
- Origen: tabla
- Genere un token de sesión siguiendo estos pasos:
- Instalar y configurar OCI CLI. Consulte Inicio rápido.
- Utilice uno de los siguientes comandos de la CLI de OCI para generar un token de sesión. Para obtener más información sobre las opciones disponibles, consulte Autenticación basada en token para la CLI.
#Create a session token using OCI CLI from a web browser: oci session authenticate --region <region_name> --profile-name <profile_name>#Example: oci session authenticate --region us-ashburn-1 --profile-name SESSIONPROFILEo
#Create a session token using OCI CLI without a web browser: oci session authenticate --no-browser --region <region_name> --profile-name <profile_name>#Example: oci session authenticate --no-browser --region us-ashburn-1 --profile-name SESSIONPROFILEEn el comando anterior,
region_name: especifica el punto final de región para el sistema operativo OCI. Para obtener una lista de las regiones de datos soportadas en Oracle NoSQL Database Cloud Service, consulte Regiones de datos y URL de servicio asociadas.profile_name: especifica el perfil que utiliza el comando de la CLI de OCI para generar un token de sesión.El comando de la CLI de OCI crea una entrada en el archivo de configuración de OCI en la ruta de acceso$HOME/.oci/config, como se muestra en el siguiente ejemplo:[SESSIONPROFILE] fingerprint=f1:e9:b7:e6:25:ff:fe:05:71:be:e8:aa:cc:3d:0d:23 key_file=$HOME/.oci/sessions/SESSIONPROFILE/oci_api_key.pem tenancy=ocid1.tenancy.oc1..aaaaa ... d6zjq region=us-ashburn-1 security_token_file=$HOME/.oci/sessions/SESSIONPROFILE/tokensecurity_token_fileapunta a la ruta del token de sesión que ha generado mediante el comando de la CLI de OCI anterior.Note:
- Si el perfil ya existe en el archivo de configuración de OCI, el comando de la CLI de OCI sobrescribe el perfil con la configuración relacionada con el token de sesión al generar el token de sesión.
- Especifique lo siguiente en la plantilla de configuración de fregadero:
- Ruta de acceso al archivo de configuración de OCI del parámetro credentials.
- Perfil utilizado al generar el token de sesión en el parámetro credentialsProfile.
"credentials" : "$HOME/.oci/config" "credentialsProfile" : "SESSIONPROFILE"La utilidad Migrator recupera automáticamente los detalles del token de sesión generado mediante los parámetros anteriores. Si no especifica el parámetro credentials, la utilidad Migrator busca el archivo de credenciales en la ruta de acceso
$HOME/.oci. Si no especifica el parámetro credentialsProfile, la utilidad Migrator utiliza el nombre de perfil por defecto (DEFAULT) del archivo de configuración de OCI. - El token de sesión es válido durante 60 minutos. Para ampliar la duración de la sesión, puede refrescar la sesión. Para obtener más información, consulte Refrescamiento de un token.
Para migrar de la tabla de Oracle NoSQL Database a un archivo JSON en el cubo del sistema operativo OCI:
Para verificar la copia de seguridad de los datos, conéctese a la consola de Oracle NoSQL Database Cloud Service. Navegue por los menús, Storage > Object Storage & Archive Storage > Buckets. Acceda a los archivos desde el directorio userSession en el cubo Migrate_oci. Para conocer el procedimiento para acceder a la consola, consulte Acceso al servicio desde la consola de Infrastructure
Migración de un archivo CSV a Oracle NoSQL Database
En este ejemplo se muestra el uso de Oracle NoSQL Database Migrator para copiar datos de un archivo CSV en Oracle NoSQL Database.
Ejemplo
Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database como su plataforma de base de datos NoSQL. Dado que el contenido de origen está en formato de archivo CSV, están buscando una forma de migrarlo a Oracle NoSQL Database.
En este ejemplo, aprenderá a migrar los datos de un archivo CSV denominado course.csv, que contiene información sobre varios cursos ofrecidos por una universidad. El archivo de configuración se genera desde la utilidad runMigrator.
También puede preparar el archivo de configuración con los detalles de origen y receptor identificados. Consulte Oracle NoSQL Database Migrator Reference.
- Identifique el origen y el receptor de la migración.
- Fuente: Archivo CSV
En este ejemplo, el archivo de origen es
course.csvcat [~/nosql-migrator-1.5.0]/course.csv 1,"Computer Science", "San Francisco", "2500" 2,"Bio-Technology", "Los Angeles", "1200" 3,"Journalism", "Las Vegas", "1500" 4,"Telecommunication", "San Francisco", "2500" - Fregadero: Oracle NoSQL Database
- Fuente: Archivo CSV
- El archivo CSV debe tener el formato
RFC4180. - Cree un archivo que contenga los comandos DDL para el esquema de la tabla de destino,
course. La definición de tabla debe coincidir con el archivo de datos CSV relativo al número de columnas y sus tipos.En este ejemplo, el archivo DDL es
mytable_schema.ddlcat [~/nosql-migrator-1.5.0]/mytable_schema.ddl create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
course.csv a Oracle NoSQL Database Service, realice los siguientes pasos:
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
sql-> select * from course;
{"id":4,"name":"Telecommunication","location":"San Francisco","fees":2500}
{"id":1,"name":"Computer Science","location":"San Francisco","fees":2500}
{"id":2,"name":"Bio-Technology","location":"Los Angeles","fees":1200}
{"id":3,"name":"Journalism","location":"Las Vegas","fees":1500}
4 rows returned