22
Approche de migration d’une BDR vers une BD noSQL
Elaboré par:
Sotor Fatima-Zehrae
Kellouch Oumaima
Harrak Mohamed
Heragua Ayoub
Bergou Younes
AGENDA
Introduction
Plan
BD Relationnelle
BD noSQL
Mogration d'une BDR vers une BD noSQL
Conctution
Introduction
Introduction
Une base de données permet de stocker et de retrouver l'intégralité de données brutes ou d'informations en rapport avec un thème ou une activité.
Ces informations peuvent être de natures différentes et plus ou moins reliées entre elles. Une base de données peut être localisée sur un même support informatisé, ou réparties sur plusieurs machines (BD NoSQL par exemple).
En effet, leurs données peuvent y être très structurées (BD relationnelles par exemple), ou bien sous forme de données brutes déstructurées (BD NoSQL Redis par exemple) qui, dans ce cas, seront ensuite parcourues de manière organisée via des moteurs spécifiques (comme Elasticsearch).
BD Relationelle
Une base de données relationnelle est un ensemble de tables formellement décrites à partir desquelles il est possible d'accéder aux données ou de les réassembler de différentes manières sans avoir à réorganiser les tables de la base de données.
L'API standard d'une base de données relationnelle est le langage SQL. Les instructions SQL sont utilisées à la fois pour les requêtes interactives d'informations et pour la collecte de données.
L'avantage principal des bases de données relationnelles est qu'elles permettent aux utilisateurs de facilement classer et stocker des données qui peuvent ensuite être interrogées et filtrées pour extraire des informations spécifiques.
Les bases de données relationnelles sont également faciles à étendre et ne dépendent pas de l'organisation physique. Après la création de la BD, une nouvelle catégorie de données peut être ajoutée sans que toutes les applications existantes soient modifiées
Les bases de données relationnelles s’appuient sur les propriétés ACID, ces propriétés bien que nécessaires à la logique du relationnel nuisent fortement aux performances, en parlant surtout aux propriétés de cohérences, car elles sont très difficiles à mettre en place dans les environnements distribués avec plusieurs serveurs, alors pour assurer cette cohérence il faut que les serveurs doivent être des miroirs les uns des autres, de ce fait deux problèmes apparaissent :
1. Le coût de stockage est énorme car chaque donnée est présente sur chaque serveur.
2. Le coût d’insertion, modification et suppression est très grand car en ne peut valider une transaction que si on est sûre et certain qu’elle a été effectuée sur tous les serveurs De plus certains types de requêtes ne sont pas du tout optimisés dans ce type(BDR) de base de données.
Problème lié aux propriétés ACID en milieu distribué
BD noSQL
NoSQL est une approche de la conception de base de données pouvant prendre en charge une grande variété de modèles de données, y compris les formats clé-valeur, document, en colonnes et en graphe.
NoSQL constitue une alternative aux bases de données relationnelles traditionnelles dans lesquelles les données sont placées dans des tables et dont le schéma de données est conçu avant la construction de la BD. Les bases de données NoSQL sont utiles pour travailler avec de grands ensembles de données distribuées.
Les bases de données NoSQL ont été créés en réponse aux limitations de la technologie de base de données relationnelle traditionnelle.
Comparées aux bases de données relationnelles, les bases de données NoSQL sont plus évolutives et offrent des performances supérieures, et leur modèle de données corrige plusieurs faiblesses du modèle relationnel.
Parmi les avantages des BD NoSQL, on a:
- La gestion d’un volume important de données structurées, semi-structurées et non structurées.
- l’utilisation d’une architecture efficace et évolutive au lieu d'une architecture monolithique coûteuse
Les bases de données documentaires ressemblent aux bases de données hiérarchiques par la structure de leurs documents. La différence vient du fait que la hiérarchie ne se fait plus au niveau de la table mais au niveau des documents eux-mêmes. Qui plus, avec des fonctions comme MapReduce, il est plus simple de parcourir et de rechercher les données
La différence entre les bases de données orientées documents et les bases de données relationnelles, c’est qu’il n y a pas un schéma de base de données dans l’orienté document, c'est-à-dire que deux documents peuvent avoir des propriétés différentes comme l’illustre l’image ci-dessous
Migration d’une BDR vers une BD nosql
dans la plupart des cas, il ne s'agit pas de remplacer SQL par une solution NoSQL, mais plutôt, de faire une transition de l'un à l'autre, si l'application et le cas d'utilisation dictent la nécessité d'un changement.
En général, cette transition sera stimulée par le besoin de flexibilité - à la fois dans le modèle de scalabilité et le modèle de données - lorsque l'on construit des applications web modernes et des applications mobiles
Voici certaines exigences correspondant au besoin d'avoir une base NoSQL:
- Développement rapide d'applications
- Évolutivité
- Une performance constante
- La fiabilité de fonctionnement
La principale difficulté se résume essentiellement à comprendre les différences entre les systèmes SGBDR traditionnels et les bases de données documents. La différence la plus importante est le modèle de données:
Chaque enregistrement dans une BD relationnelle est conforme à un schéma avec un nombre fixe de champs. Les données sont dé normalisées dans plusieurs tables.
L'avantage est qu'il y a moins de données en double dans la BD.
L'inconvénient est qu'un changement dans le schéma signifie effectuer plusieurs "alter table" coûteux qui exigent de verrouiller plusieurs tables simultanément afin d'assurer qu'un changement ne laisse pas la base de données dans un état incohérent
Avec les bases de données documents, d'autre part, chaque document peut avoir une structure complètement différente des autres documents.
Aucune gestion supplémentaire n'est nécessaire sur la base de données pour gérer les changements sur les schémas.
L’approche de migration d’une BDR vers unes BD NoSql consiste à prendre une BDR existante comme entrée c’est-à-dire son modèle conceptuel de données combiné à toute la sémantique requise, et de générer un modèle de données équivalent qui rend compte des caractéristiques essentielles de la base de données NoSQL. L'approche doit générer non seulement le schéma cible : c’est la traduction des schémas, mais aussi de produire les instances de données pour la base de données cible à partir des données de la base de départ.
Concernant la conversion des données, elle se décline en trois phases : l’extraction des données, le traitement ou enrichissement des données et l’injection des données dans la base de destination.
Concernant, la traduction du schéma source, elle s’est faite au moyen des règles de traduction relatives aux entités et aux différents types d’associations à savoir :
− Une entité se traduit par une famille de colonne
− Les associations de types plusieurs à un de dimension 2, donnent lieu à une famille de colonne.
− Les associations de types plusieurs à plusieurs de dimension 2, se traduisent en deux familles de colonnes.
− Les associations de type un à un qui se traduisent en une famille de colonnes.
Aussi, pendant la phase de traduction du schéma source, deux structures de données sont à construire : il s’agit de la matrice de dépendance relationnelle et la table de correspondance des clés. La première structure de données, précise l’ordre dans lequel la migration des données doit faire, et la deuxième structure, permet de gérer non seulement la correspondance entre les entités des bases source et destination, mais aussi la gestion des champs clés lors de la conversion des données.
Conclusion
Contrution
Les bases de données relationnelles ont été utilisées pendant des décennies pour stocker des données, et elles représentent toujours une solution viable pour de nombreux cas d'utilisation.
NoSQL quant à lui est choisi aujourd'hui notamment pour des raisons d'évolutivité et de performance.