Nous assistons à une étonnante renaissance. Les bases de données, longtemps considérées comme obsolètes, sont soudain devenues les chouchoutes du secteur. Des années après que les experts ont déclaré les bases de données quasiment mortes, une nouvelle génération de start-up a attiré l’attention de Wall Street. Pourtant, les responsables informatiques peinent encore à migrer efficacement leurs charges de travail existantes vers ces systèmes.
Le verrouillage propriétaire lié aux bases de données est légendaire. Aucun autre secteur n’exerce une influence aussi forte sur ses utilisateurs. Naturellement, le verrouillage propriétaire rend les clients dépendants de la technologie existante. Mais il tient également la concurrence et les nouveaux acteurs à distance. Le CEO de Snowflake a déploré de manière célèbre la difficulté à pénétrer ce marché lorsqu’il a déclaré : « Teradata a [made] rendu la sortie de sa plateforme extrêmement difficile. »
Avec l’avènement de la virtualisation des bases de données (DBV) – à ne pas confondre avec la virtualisation des données –, une nouvelle méthodologie est entrée en scène. La DBV prétend briser le verrouillage propriétaire des technologies d’entrepôt de données. Dans quelle mesure est-elle applicable et comment les responsables informatiques peuvent-ils évaluer cette technologie ? Voici cinq choses à savoir sur la DBV.
À lire également : Comment la virtualisation des bases de données facilite la migration d’un entrepôt de données vers le cloud
- 1) Comment fonctionne la DBV ?
- 2) Quand utiliser la DBV plutôt qu’une migration classique ?
- 3) La DBV peut-elle couvrir ma charge de travail ?
- 4) En quoi la DBV diffère-t-elle de la virtualisation des données ?
- 5) La DBV peut-elle reconfigurer les EDW sur n’importe quelle technologie ?
- Choisir la bonne approche pour les migrations
1) Comment fonctionne la DBV ?
Une plateforme de DBV se situe entre la base de données et les applications. Elle permet à des applications conçues pour une base de données de s’exécuter nativement sur une autre. Toutes les requêtes et communications sont traduites en temps réel. Par exemple, des applications conçues pour Teradata peuvent s’exécuter directement sur Microsoft Azure Synapse sans même « savoir » qu’elles ne fonctionnent plus sur Teradata.
La DBV est totalement transparente, avec pour objectif que les applications ne nécessitent aucune modification ou seulement des ajustements minimes. Cela inclut non seulement le SQL standard, mais aussi les extensions propriétaires. Et pour être efficace en pratique, elle doit également prendre en charge les chargeurs, les pilotes et les utilitaires.
Comme les systèmes de DBV assurent la traduction des requêtes et des données, ils peuvent fonctionner avec une surcharge relativement faible. Le traitement effectif des données est toujours réalisé sur l’entrepôt de données lui-même et exploite les capacités de traitement massivement parallèle (MPP) de ce système.
2) Quand utiliser la DBV plutôt qu’une migration classique ?
Lors d’une migration classique, tout le code SQL, les pilotes, les outils et les utilitaires existants sont remplacés par leurs équivalents du nouveau système cible. Pour les systèmes d’entrepôt de données compacts qui n’hébergent qu’un petit nombre d’applications, cette approche peut être préférable. Les magasins de données utilisés par un nombre limité d’utilisateurs peuvent également s’y prêter.
En revanche, dans le cas d’entrepôts de données d’entreprise (EDW) complexes, la DBV peut nettement surpasser la migration classique. La DBV permet de migrer les charges de travail en une fraction du temps, du coût et du risque.
3) La DBV peut-elle couvrir ma charge de travail ?
Certaines charges de travail utilisent massivement des fonctionnalités spécialisées. D’autres s’appuient sur des fonctionnalités antérieures aux efforts de standardisation. Autrement dit, aucune charge de travail d’entrepôt de données ne ressemble à une autre. Il peut donc être difficile d’évaluer la couverture offerte par un système de DBV.
Une documentation exhaustive des fonctionnalités prises en charge semble souhaitable, mais elle n’est en réalité pas très utile. La plupart des clients sont incapables de décrire succinctement les fonctionnalités actuellement utilisées par leurs charges de travail. Pour compliquer encore les choses, les auteurs d’origine des requêtes ou des fonctions ne travaillent souvent plus dans l’entreprise.
Cela ne doit toutefois pas constituer un obstacle à l’adoption de la DBV. Comme son adoption présente peu de risques, la DBV se prête très bien aux implémentations de validation de principe (POC). Les clients n’ont pas besoin de modifier leurs applications pour utiliser la DBV. Ils peuvent tester directement leurs applications réelles dans le cadre d’une POC.
Une POC peut alors identifier rapidement les éventuelles lacunes de couverture. Il est important de comprendre que, si une couverture de 100 % semble souhaitable, un taux élevé dans les 90 % est généralement suffisant. La résolution des problèmes restants ne demande souvent qu’un effort négligeable.
À lire également : Les meilleurs logiciels de veille stratégique
4) En quoi la DBV diffère-t-elle de la virtualisation des données ?
La virtualisation des données est une approche quelque peu apparentée, mais très différente. Pour que la virtualisation des données soit efficace, toutes les applications doivent d’abord être réécrites et adopter un dialecte SQL abstrait. Ce n’est qu’alors qu’elle empêche le verrouillage propriétaire futur. Ses principaux domaines d’application sont les scénarios « greenfield », qui ne nécessitent pas de prendre en compte les applications existantes.
À l’inverse, la DBV brise le verrouillage propriétaire existant. Elle laisse les applications en l’état. Avec le temps, cela peut conduire à un assortiment varié de technologies applicatives différentes. Toutefois, ce point peut ne pas être très préoccupant et se trouve largement compensé par l’adoption de nouvelles technologies de données.
5) La DBV peut-elle reconfigurer les EDW sur n’importe quelle technologie ?
Tous les quelques années, une nouvelle technologie remet en question la suprématie des systèmes d’entrepôt de données d’entreprise. Souvent, le nouvel arrivant surpasse la pile existante sur une dimension notable. Par exemple, la nouvelle technologie peut être plus évolutive. Une autre peut simplifier le partage des données. Une autre encore séduira davantage les développeurs open source.
En règle générale, des équipes d’experts peuvent concevoir des solutions sur mesure pour déplacer les charges de travail d’un EDW vers la plupart des nouvelles technologies. Cependant, plus l’écart fonctionnel est important, plus il faut d’ingénierie logicielle pour exploiter ces systèmes. Par exemple, déplacer un EDW vers un système NoSQL peut être techniquement faisable, mais n’est pas toujours judicieux sur le plan économique.
Pour que la DBV soit efficace, les systèmes source et cible doivent être suffisamment similaires. Cela ne nécessite toutefois pas des fonctionnalités équivalentes. La DBV peut compenser l’absence de la plupart des fonctionnalités avancées, comme les procédures stockées, les macros ou même les types de données non pris en charge. Actuellement, les solutions PaaS cloud-native sont les plus performantes dans le contexte de la DBV.
Choisir la bonne approche pour les migrations
Lors du choix d’un nouveau système cible pour un EDW existant, de nombreux facteurs doivent être pris en compte. L’un d’eux est souvent négligé : l’approche de migration. La DBV est particulièrement efficace pour briser le verrouillage propriétaire des entrepôts de données historiques.
En intégrant l’approche de migration à leur choix du système cible, les responsables informatiques peuvent optimiser l’adoption rapide tout en maîtrisant les risques et les coûts.
À lire également : Prévisions technologiques pour 2022 : cloud, données, cybersécurité, IA et plus encore
À propos de l’auteur :
Mike Waas est le fondateur et CEO de Datometry