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 autenticación basada en Oracle Wallet, necesita un archivo jar adicional que forme parte de la instalación de EE. Para obtener más información, consulte Oracle Wallet.
Sin este archivo jar, recibirá el siguiente mensaje de error:
No se pudo encontrar kvstore-ee.jar en el directorio lib. Copie kvstore-ee.jar en el directorio lib.
kvstore-ee.jar del paquete del servidor de 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
Note:
El soporte para migrar metadatos TTL para filas de tabla solo está disponible para Oracle NoSQL Database y Oracle NoSQL Database Cloud Service.Exportando metadatos de TTL
_metadata para cada fila exportada. 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 un parámetro de configuración, includeTTL. La operación de importación maneja los siguientes casos de uso al migrar filas de tabla que contienen metadatos TTL. Estos casos de uso se aplican solo cuando se especifica el parámetro de configuración includeTTL.
- Caso de uso 1: no hay información de metadatos TTL presente en la fila de la tabla de importación.
Al importar un archivo de origen JSON generado desde un origen externo o exportado mediante versiones anteriores del migrator, la fila de importación no tiene información de TTL. Sin embargo, dado que el parámetro de configuración includeTTL es igual a
true, el migrador define el valor TTL=0 para la fila de tabla, lo que significa que la fila de tabla de importación nunca caduca. - Caso de uso 2: el valor 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.
Al exportar una fila de tabla a un archivo e intentar importarla después de la hora de caducidad de la fila de tabla, la fila de tabla se ignora y no se escribe en el almacén.
- Caso de uso 3: el valor 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.
Al exportar una fila de tabla a un archivo e intentar importarla antes de la hora de caducidad de la fila de tabla, la fila de tabla se importa con un valor TTL. Sin embargo, el nuevo valor de TTL para la fila de tabla puede no ser igual al valor de TTL exportado debido a las restricciones de ventana de hora y día enteros en la clase TimeToLive. Por ejemplo,
Fila de tabla exportada{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC } }La hora de referencia durante la importación es 1629707962582, que es el lunes 23 de agosto de 2021 a las 8:39:22.582 a. m.
Fila de tabla importada{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC } }
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>
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 abrir los archivos de JSON Sink y ver el esquema y los datos.
-- Exported myTable Data
[~/nosqlMigrator]$cat myTableJSON
{
"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 receptor 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 Oracle NoSQL Database.
Caso de uso:
Después de evaluar varias opciones, una organización finaliza Oracle NoSQL Database a través de 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"}}}
{"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"}}}
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
- Enlace: Oracle NoSQL Database (local)
- Para importar datos de tabla DynamoDB a Oracle NoSQL Database, primero debe exportar la tabla DynamoDB a S3. 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 - 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 el origen identificado y el receptor details.See Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates (Plantillas de configuración de receptor).
Puede seleccionar una de estas dos opciones.
- Opción 1: importando la tabla DynamoDB como documento JSON mediante la configuración de esquema por defecto.
Aquí
defaultSchemaesTRUE, por lo que el migrador crea el esquema por defecto en el receptor. Debe especificar el tipo de columnaDDBPartitionKeyy NoSQL correspondiente. De lo contrario, se devuelve un error.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] "schemaInfo" : { "defaultSchema" : true, "DDBPartitionKey" : "<PrimaryKey:Datatype>", }, }, "abortOnError" : true, "migratorVersion" : "1.0.0" }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í
defaultSchemaesFALSEy especifica schemaPath como un archivo que contiene la sentencia DDL. 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.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- Opción 1: importando la tabla DynamoDB como documento JSON mediante la configuración de 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/nosql-migrator-1.0.0]$./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
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoredesc <table_name>
SELECT * from <table_name>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 el origen identificado y los detalles del receptor. Consulte Source Configuration Templates (Plantillas de configuración de origen) y Sink Configuration Templates (Plantillas de configuración de receptor).
Puede seleccionar una de estas dos opciones.
- Opción 1: importando la tabla DynamoDB como documento JSON mediante la configuración de esquema por defecto.
Aquí
defaultSchemaesTRUE, por lo que el migrador crea el esquema por defecto en el receptor. Debe especificar el tipo de columnaDDBPartitionKeyy 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.0.0" }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í
defaultSchemaesFALSEy especifica schemaPath como un archivo que contiene la sentencia DDL. 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.{ "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 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- Opción 1: importando la tabla DynamoDB como documento JSON mediante la configuración de 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/nosql-migrator-1.0.0]$./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 crea 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 Object Storage está en un compartimento diferente, asegúrese de que tiene privilegios para escribir objetos en el cubo. Para obtener más información sobre la configuración de las políticas, consulte Cómo permitir a los usuarios escribir objetos en cubos de 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 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 sumidero 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