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

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

• Identificar Esquema de Tabla de Sink: Si el sink es local o en la nube de Oracle NoSQL Database, debe identificar el esquema para la tabla de sink 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 destino.
  • 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 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))

    Donde:

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

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

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

    Si el origen es un archivo JSON con formato DynamoDB, el esquema por defecto para 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]))

    Donde:

    - TABLE_NAME = valor proporcionado para la tabla de vaciado 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 dato de la clave de partición en la configuración

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

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

    - 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 en una columna JSON NoSQL

    Si el formato de origen es un archivo CSV, no se admite un esquema predeterminado 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 del archivo 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.

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

  CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))

• Crear tabla de enlace: una vez que identifique el esquema de tabla de enlace interno, cree la tabla de enlace interno mediante la CLI de administrador o mediante el atributo schemaInfo del archivo de configuración de enlace externo. Consulte Sink Configuration Templates.
  Nota
  
  Si el origen es un archivo CSV, cree un archivo con los comandos DDL para el esquema de la tabla de destino. Proporcione la ruta de acceso del archivo en el parámetro schemaInfo.schemaPath del archivo de configuración de vaciado.

Puede elegir incluir los metadatos de TTL para las filas de tabla junto con los datos reales al realizar la migración de tablas NoSQL. NoSQL Database Migrator proporciona un parámetro de configuración para admitir la exportación e importación de metadatos TTL de fila de tabla. Además, la herramienta proporciona una opción para seleccionar el tiempo de caducidad relativo para las filas de la tabla durante la operación de importación. De manera opcional, puede exportar o importar metadatos de TTL mediante el parámetro includeTTL.

Cuando se exporta una tabla, los datos de TTL se exportan para las filas de la tabla que tienen un tiempo de caducidad válido. Si una fila no caduca, no se incluye explícitamente en los datos exportados porque su valor de caducidad es siempre 0. La información de TTL está incluida en el objeto JSON _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
}

En los casos de uso 2 y 3, la hora de referencia por defecto de la operación de importación es la hora actual en milisegundos, obtenida de System.currentTimeMillis(), de la máquina en la que se ejecuta la herramienta NoSQL Database Migrator. Sin embargo, también puede definir una hora de referencia personalizada con el parámetro de configuración ttlRelativeDate si desea ampliar la hora de caducidad e importar filas que, de lo contrario, caduquen inmediatamente.

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

  Al importar un archivo JSON producido a partir de un origen externo o exportado mediante versiones anteriores del migrador, 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 TTL=0 para la fila de la tabla, lo que significa que la fila de la tabla de importación nunca caduca.

• Caso de uso 2: el valor de TTL de la fila de la tabla de origen caduca en relación con la hora 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 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.

  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 la tabla no puede ser igual al valor de TTL exportado debido a las restricciones de hora de entero y ventana de día 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
    }
  }

  El tiempo de referencia durante la importación es 1629707962582, que es el lunes 23 de agosto de 2021 8:39:22.582 AM.

  Fila de tabla importada

  {
    "id" : 8,
    "name" : "xyz",
    "_metadata" : {
      "ttl" :  1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC
    }
  }

Puede ejecutar el comando runMigrator de dos maneras:

1. Creando el archivo de configuración JSON 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 JSON de configuración según sus opciones para cada opción.
   • Después de que la utilidad cree el archivo JSON de configuración, puede continuar con la actividad de migración en la misma ejecución o guardar el archivo de configuración para una futura migración.
   • Independientemente de su decisión de continuar o diferir la actividad de migración con el archivo JSON de configuración generado, el archivo estará disponible para modificaciones o personalizaciones con el fin de cumplir sus requisitos futuros. Puede utilizar el archivo JSON de configuración personalizado para la migración más adelante.
2. Al transferir un archivo de configuración de JSON creado manualmente como parámetro de tiempo de ejecución mediante la opción -c o --config. Debe crear el archivo JSON de configuración manualmente antes de ejecutar el comando runMigrator con la opción -c o --config. Para obtener ayuda con los parámetros de configuración de origen y de vaciado, consulte Referencia de Oracle NoSQL Database Migrator.

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