alphaspirit - Fotolia
AWS crée un pont direct depuis MongoDB vers DynamoDB
Manœuvre de séduction auprès des utilisateurs de la base NoSQL, AWS a inclut le support de MongoDB à son outil de migration de données. Une passerelle directe vers DynamoDB.
Illustration de la montée en puissance des bases de données NoSQL dans les entreprises, AWS a décidé d’inclure à son service de migration de données, AWS Database Migration Services (DMS), la base orientée document MongoDB. Il s’agit de la première base NoSQL supportée par ce service Cloud, et de la première passerelle tirée directement vers le Cloud AWS pour ce type d’architecture. Un vrai clin d’œil aux utilisateurs de MongoDB, la 1er base NoSQL derrière les cadres du SQL, si l’on en croit le baromètre DB Engines.
Pierre angulaire de la transition des bases de données vers le Cloud, ce service d’AWS a pour vocation de fluidifier les procédures de migration de données d'une base de données vers une autre, hébergée par sur la plateforme Cloud de la marque. Le service supporte aussi bien les migrations de bases homogènes, vers des moteurs équivalents, que des migrations de bases hétérogènes, où le moteur source diffère de celui vers lequel sont transférées les données (la plateforme cible en somme). Dans le cas de MongoDB en tant que moteur source, AWS place logiquement sa base NoSQL, DynamoDB, en tant que moteur cible.
Jusqu’alors, DMS ne supportait que les bases sources Oracle, SQL Server, PostgreSQL, MySQL (ou compatible comme MariaDB), SAP ASE, ou encore l’entrepôt de données Teradata. Selon Jeff Barr, évangéliste chez AWS, ce service, lancé en mars 2016, aurait permis de migrer 20 000 bases uniques vers des services de la marque, comme RDS (et ses déclinaisons), Aurora, DynamoDB ou encore RedShift (l’entrepôt de données Cloud d’AWS).
Deux méthodes de migration
Pour des migrations de données hétérogènes, AWS mis au point un autre outil nommé Schema Conversion Tool (SCT), qui convertit les schémas de données de la base source vers ceux de la base cible, et – cela est un point clé -, le code spécifique à chaque plateforme. L’outil supporte par exemple la conversion d’Oracle vers Aurora, MySQL, PostgreSQL et Oracle sur AWS ; ou encore SQL Server, vers Aurora, MySQL ou PostgreSQL, Netezza et Greenplum vers RedShift.
Par exemple, l’outil permet de « convertir du code PL/SQL Oracle et T-SQL SQL Server en un code équivalent dans le dialecte SQL d'Amazon Aurora ou de MySQL », souligne une FAQ. Le code qui n’a pas été converti est alors mis en évidence pour être modifié à la main, par le développeur.
En fonction du scenario recherché, AWS propose deux méthodes de migration des données depuis MongoDB, comme le précise la documentation. Chacune adaptée aux spécificités structurelles de la base NoSQL (sa notion de collections de documents JSON, par exemple). La première (Document Mode) consiste à migrer les documents JSON tels quels, et de transformer les données du documents dans une colonne. La seconde (Table Mode) définit un nombre de documents et les transforme en colonnes d’une table.
Inclure MongoDB dans une logique de consolidation
Toutefois, l’autre intérêt de ce support est aussi d’intégrer le NoSQL dans la réplication des données en continu et la consolidation des bases de données, autres cas d’usage du service AWS. Si le premier scenario favorise la mise en place de récupération après sinistre, le second vient concrétiser l’idée que les bases NoSQL sont généralement associées à d’autres bases de données de type SQL dans les entreprises. DMS pourrait donc permettre d’harmoniser un tel environnement sur la plateforme AWS.
Restera enfin à maîtriser le modèle tarifaire du service afin de ne pas faire gonfler la facture. Comme le précise AWS, seuls « les ressources de calcul utilisées au cours du processus de migration et le stockage de journaux supplémentaire » sont prises en compte. Ressources qui peuvent être sollicitées dans le cas de grands volumes de données d’une base NoSQL.
Database Migration Service s’adosse aux instances à la demande d’AWS, du type t2.micro à c4.4.xlarge. Si le transfert de données entrant est gratuit, celui portant sur les données sortantes est facturé – d’une zone de disponibilité à l’autre et d’une région à l’autre.