L'utilitaire Oracle NoSQL Database Migrator peut être téléchargé à partir de la page Téléchargements Oracle NoSQL. Une fois que vous l'avez téléchargé et décompressé sur votre ordinateur, vous pouvez accéder à la commande runMigrator à partir de l'interface de ligne de commande.

Avant d'utiliser le programme de migration, vous devez identifier la source de données et le récepteur. Par exemple, si vous voulez migrer une table NoSQL d'Oracle NoSQL Database sur site vers un fichier au format JSON, votre source sera Oracle NoSQL Database et le récepteur sera un fichier JSON. Assurez-vous que la source et le récepteur identifiés sont pris en charge par Oracle NoSQL Database Migrator en se référant à Sources et puits pris en charge. Il s'agit également d'une phase appropriée pour déterminer le schéma de votre table NoSQL dans la cible ou le récepteur, et pour les créer.

• Identifier le schéma de table de liens : Si le dissipateur est Oracle NoSQL Database sur site ou dans le cloud, vous devez identifier le schéma de la table de liens et vous assurer que les données source correspondent au schéma cible. Si nécessaire, utilisez des transformations pour mapper les données source avec la table d'évier.
  • Schéma par défaut : NoSQL Database Migrator permet de créer une table avec le schéma par défaut sans avoir à prédéfinir le schéma de la table. Cela est particulièrement utile lors du chargement de fichiers JSON dans Oracle NoSQL Database.
    Si la source est un fichier JSON au format MongoDB, le schéma par défaut de la table est le suivant :

    CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))

    Où :

    - tablename = valeur fournie pour l'attribut de table dans la configuration.

    - ID = valeur _id de chaque document du fichier source JSON exporté par mongoDB.

    - DOCUMENT = Pour chaque document du fichier exporté mongoDB, le contenu à l'exclusion du champ _id est agrégé dans la colonne DOCUMENT.

    Si la source est un fichier JSON au format DynamoDB, le schéma par défaut de la table sera le suivant :

    CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, 
    [DDBSortKey_name DDBSortKey_type],DOCUMENT JSON,
    PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))

    Où :

    - TABLE_NAME = valeur fournie pour la table de récepteur dans la configuration

    - DDBPartitionKey_name = valeur fournie pour la clé de partition dans la configuration

    - DDBPartitionKey_type = valeur fournie pour le type de données de la clé de partition dans la configuration

    - DDBSortKey_name = valeur fournie pour la clé de tri dans la configuration, le cas échéant

    - DDBSortKey_type = valeur fournie pour le type de données de la clé de tri dans la configuration, le cas échéant

    - DOCUMENT = Tous les attributs à l'exception de la clé de partition et de tri d'un élément de table de base de données Dynamo agrégé dans une colonne JSON NoSQL

    Si le format source est un fichier CSV, aucun schéma par défaut n'est pris en charge pour la table cible. Vous pouvez créer un fichier de schéma avec une définition de table contenant le même nombre de colonnes et de types de données que le fichier CSV source. Pour plus d'informations sur la création du fichier de schéma, reportez-vous à Fourniture d'un schéma de table.

    Pour toutes les autres sources, le schéma par défaut est le suivant :

    CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))

    Où :

    - tablename = valeur fournie pour l'attribut de table dans la configuration.

    - ID = valeur LONG générée automatiquement.

    - DOCUMENT = L'enregistrement JSON fourni par la source est agrégé dans la colonne DOCUMENT.

    Remarque
    
    Si la valeur _id n'est pas fournie en tant que chaîne dans le fichier JSON au format MongoDB, NoSQL Database Migrator la convertit en chaîne avant de l'insérer dans le schéma par défaut.
• Fourniture d'un schéma de table : NoSQL Database Migrator permet à la source de fournir des définitions de schéma pour les données de table à l'aide de l'attribut schemaInfo. L'attribut schemaInfo est disponible dans toutes les sources de données pour lesquelles aucun schéma implicite n'est déjà défini. Les banques de données Sink peuvent choisir l'une des options suivantes.
  • Utilisez le schéma par défaut défini par NoSQL Database Migrator.
  • Utilisez le schéma fourni par la source.
  • Remplacez le schéma fourni par la source en définissant son propre schéma. Par exemple, si vous souhaitez transformer les données du schéma source en un autre schéma, vous devez remplacer le schéma fourni par la source et utiliser la capacité de transformation de l'outil NoSQL Database Migrator.
  
  
  
  
  
  Le fichier de schéma de table, par exemple, mytable_schema.ddl peut inclure des instructions DDL de table. L'outil NoSQL Database Migrator exécute ce fichier de schéma de table avant de démarrer la migration. L'outil de migration ne prend pas en charge plusieurs instructions DDL par ligne dans le fichier de schéma. Par exemple,

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

• Créer une table de noeuds : une fois que vous avez identifié le schéma de la table de noeuds, créez la table de noeuds via l'interface de ligne de commande (CLI) d'administration ou à l'aide de l'attribut schemaInfo du fichier de configuration de récepteur. Reportez-vous à la section Sink Configuration Templates.
  Remarque
  
  Si la source est un fichier CSV, créez un fichier avec les commandes DDL pour le schéma de la table cible. Indiquez le chemin du fichier dans le paramètre schemaInfo.schemaPath du fichier de configuration du récepteur.

Vous pouvez choisir d'inclure les métadonnées de durée de vie des lignes de table ainsi que les données réelles lors de la migration des tables NoSQL. NoSQL Database Migrator fournit un paramètre de configuration prenant en charge l'export et l'import des métadonnées de durée de vie de ligne de table. En outre, l'outil permet de sélectionner le délai d'expiration relatif des lignes de la table pendant l'opération d'importation. Vous pouvez éventuellement exporter ou importer des métadonnées de durée de vie à l'aide du paramètre includeTTL.

Lorsqu'une table est exportée, les données de durée de vie sont exportées pour les lignes de la table dont le délai d'expiration est valide. Si une ligne n'expire pas, elle n'est pas incluse explicitement dans les données exportées car sa valeur d'expiration est toujours égale à 0. Les informations de durée de vie sont contenues dans l'objet JSON _metadata pour chaque ligne exportée. Le NoSQL Database Migrator exporte le délai d'expiration de chaque ligne en millisecondes depuis la période UNIX (1er janvier 1970). Par exemple,

//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
}

Dans les cas d'utilisation 2 et 3, l'heure de référence par défaut de l'opération d'import est l'heure actuelle, en millisecondes, obtenue à partir de System.currentTimeMillis(), de l'ordinateur sur lequel l'outil NoSQL Database Migrator est exécuté. Toutefois, vous pouvez également définir une heure de référence personnalisée à l'aide du paramètre de configuration ttlRelativeDate si vous souhaitez prolonger la durée d'expiration et importer les lignes qui expireraient immédiatement.

• Cas d'utilisation 1 : aucune information sur les métadonnées de durée de vie n'est présente dans la ligne de la table d'import.

  Lorsque vous importez un fichier JSON produit à partir d'une source externe ou exporté à l'aide de versions antérieures du migrateur, la ligne d'import ne contient pas d'informations de durée de vie. Mais comme le paramètre de configuration includeTTL est égal à true, le migrateur définit la durée de vie=0 pour la ligne de table, ce qui signifie que la ligne de la table d'import n'expire jamais.

• Cas d'utilisation 2 : la valeur de durée de vie de la ligne de la table source a expiré par rapport à l'heure de référence lorsque la ligne de la table est importée.

  Lorsque vous exportez une ligne de table dans un fichier et que vous essayez de l'importer après l'heure d'expiration de la ligne de table, la ligne de table est ignorée et n'est pas écrite dans le magasin.

• Cas d'utilisation 3 : la valeur de durée de vie de la ligne de la table source n'a pas expiré par rapport à l'heure de référence lorsque la ligne de la table est importée.

  Lorsque vous exportez une ligne de table dans un fichier et que vous tentez de l'importer avant l'heure d'expiration de la ligne de table, la ligne de table est importée avec une valeur de durée de vie. Toutefois, la nouvelle valeur de durée de vie de la ligne de table peut ne pas être égale à la valeur de durée de vie exportée en raison des contraintes d'heure et de fenêtre de jour entières dans la classe TimeToLive. Par exemple,

  Ligne de table exportée

  {
    "id" : 8,
    "name" : "xyz",
    "_metadata" : {
      "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC
    }
  }

  L'heure de référence lors de l'importation est 1629707962582, qui est le lundi 23 août 2021 8:39 :22.582 AM.

  Ligne de table importée

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

Vous pouvez exécuter la commande runMigrator de deux manières :

1. En créant le fichier de configuration JSON à l'aide des options d'exécution de la commande runMigrator, comme indiqué ci-dessous.

   [~]$ ./runMigrator
   configuration file is not provided. Do you want to generate configuration? (y/n)                                                                              
    
   [n]: y
   ...
   ...

   • Lorsque vous appelez l'utilitaire runMigrator, il fournit une série d'options d'exécution et crée le fichier JSON de configuration en fonction de vos choix pour chaque option.
   • Une fois que l'utilitaire a créé le fichier JSON de configuration, vous pouvez soit poursuivre l'activité de migration au cours de la même exécution, soit enregistrer le fichier de configuration pour une migration ultérieure.
   • Quelle que soit votre décision de poursuivre ou de différer l'activité de migration avec le fichier JSON de configuration généré, ce fichier sera disponible pour les modifications ou la personnalisation afin de répondre à vos besoins futurs. Vous pouvez utiliser le fichier JSON de configuration personnalisé pour la migration ultérieurement.
2. En transmettant un fichier de configuration JSON créé manuellement en tant que paramètre d'exécution à l'aide de l'option -c ou --config. Vous devez créer le fichier JSON de configuration manuellement avant d'exécuter la commande runMigrator avec l'option -c ou --config. Pour obtenir de l'aide sur les paramètres de configuration source et de récepteur, reportez-vous à la section Oracle NoSQL Database Migrator Reference.

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