Cours BD Avancées DR SARR UASZ

Master en Informatique
Les Bases de Données

avancées (BDA)
Par
Dr Edouard Ngor SARR
Enseignant-chercheur en Informatique
Université Assane SECK de Ziguinchor
Edouard-ngor.sarr@univ-zig.sn
CERIDES UCAO & Check4Decision Project
Fevrier 2023
Sommaire
Introduction
Partie 1: Bases de données Reparties
TD/TP 1: Répartition de bases de données
Partie 2: Bases de données répliquées
TD/TP 2: Réplication de bases de données
Partie 3: Les Big Data & NoSQL
Partie 4: Les SGBD InMemory
Introduction
BDA: Les Bases de données reparties
Introduction
• La gestion de bases de données avec le temps, s'est confrontée à
divers problèmes
– Les besoins en distribution :
• Entreprise de plus en plus multinationales
– L'augmentation du volume de données

• Augmentation exponentielle du volume de l’information
– L'augmentation du volume de traitements

• Augmentation du volume des transactions (10 fois dans les
5 prochaines années).
• Augmentation du nombre de clients
Dr Edouard Ngor SARR 4

Introduction
• Conséquences
– la lenteur des applications
– Les périphériques de stockage submergés, ne répondant pas
assez vite.
• Paradoxe
– es débits des liaisons réseaux évoluaient beaucoup plus vite
que les capacités des périphériques de stockage.
– Capacité des DRAM : 4 fois tous les 4 ans,
– Débit des disques : 2 fois sur les 10 dernières années.
• Solution
– Multiplier les sources de données et les faire communiquer
par réseau, afin de bénéficier de traitements parallèles,
minimisant ainsi les temps de réponses.
Partie 1:
Les bases de données reparties
Définitions
• BD réparties
– Plusieurs bases sur plusieurs sites physiques (SGBD), mais
une seule base de données « logique ».
– Les ordinateurs (appelés sites) communiquent via le réseau.
• Chaque site
– Est autonome
• Son propre SGBD
– Pas forcement le même que les autres sites
• Ses propres données
– Une ou plusieurs bases de données
– peut exécuter des transactions locales
– participer à l’exécution de transactions globales

Définitions
• Un système de bases de données réparties ne doit donc
en aucun cas être confondu avec :
– Un système client-Serveur
• La base de données se trouve dans le serveur
• Ce serveur est accessible à distance (les clients) via le
réseau
– Une multibase
• Plusieurs BDs inter-opèrent avec une application via un
langage commun et sans modèle commun.
– Une BD fédérée
• Plusieurs BDs hétérogènes sont accédées comme une
seule via une vue commune
• Exemple des SID
Objectifs d’un BDR

• Pourquoi une Base de Données Distribuée ?
– Performance
• Coûts de transfert réduits en rapprochant les données de
leurs traitements
• Ex: clients de la succursale de Dakar dans une BD située à
Dakar
– Fiabilité et disponibilité
• En cas de panne, les autres sites peuvent assurer la
disponibilité des données
• Extensibilité (Scalabilité)
– Si les besoins en stockage et calcul augmentent, on
peut rajouter
– un nouveau nœud, au lieu de remplacer le serveur
Principes de base
• Autonomie locale
– Chaque BD locale est complète, autonome et peut évoluer
indépendamment des autres
• Egalité entre sites et Fonctionnement continu
– Un site en panne ne doit pas empêcher le fonctionnement des
autres sites (mais perturbations possibles)
– Permet résistance aux pannes
• Localisation transparente
– Accès uniforme aux données quel que soit leur site de
stockage
• Fragmentation transparente
– Des données (d’une même table) éparpillées doivent être
vues comme un tout
Principes de base
• Requêtes distribuées et Transactions réparties
– L’exécution d’une requête peut être répartie
(automatiquement) entre plusieurs sites (si les données sont
réparties)
– Le mécanisme de transactions peut être réparti entre
plusieurs sites (si ...)
• Indépendance vis-à-vis du matériel, du SE, du SGBD et
du réseau
– Le SGBD fonctionne sur les différentes plateformes utilisées
– Le SGBD fonctionne sur les différents SE...
– Le SGBD est accessible à travers les différents types de
réseau utilisés
– La base peut être distibuée sur des SGBD hétérogènes
Complexité de la répartition
• Transparence de la répartition
– Les applications ne doivent pas se soucier du fait que les
données sont réparties sur plusieurs sites
– Les nœuds peuvent avoir des schémas / SGBD différents
– Répartition du dictionnaire de données
• Gestion des transactions réparties
– Maintenir les propriété d’atomicité, isolation et durabilité des
– transactions est plus complexe dans un contexte réparti
• Evaluation de requêtes réparties
– Les plans d’exécution doivent tenir compte
– Localisation des données sur chaque site
– Coût de transfert des données

Difficultés de la répartition
• Coût
– Matériels
– Finance
– Bande passante réseau
• Administration complexe:
– Mise en œuvre
– Développement
• Distribution du contrôle
• Difficulté de migration
• Surcharge
– Echange de messages augmente le temps de calcul

Architectures reparties
• Trois architectures
– SGBD répartis homogènes

– Multi-SGBD

– SGBD fédérés

Approches de Conception des BDR

• Approche descendante (Fragmentation)
– Conception du schéma conceptuel global
– Distribution pour obtenir des schémas conceptuels locaux
– BDD :Schéma global – Affectation aux sites – Allocation
• La fragmentation
– Processus de décomposition d'une base de donnée en un
ensemble de sous-bases de données.
– Doit être sans perte d'information.
– Les règles de fragmentation sont les suivantes :
• La complétude : pour toute donnée d’une relation R, il existe
un fragment Ri de la relation R qui possède cette donnée.
• La reconstruction : pour toute relation décomposée en un
ensemble de fragments Ri, il existe une opération de
reconstruction.

– Découpé une table en fragments répartis sur plusieurs sites
– Co-localisation des données avec leurs traitements
– Favorise l’extensibilité du système (vs données centralisées)
– Trois types de fragmentation:
• Fragmentation horizontale
• Fragmentation verticale
• Fragmentation mixte






– Fragmentation Horizontale




– Fragmentation Verticale
• La fragmentation doit respecter trois principales règles.
– Pour toute donnée de la relation originale R il doit avoir une sous
relation Ri la contenant.
– Pour toute fragmentation de la relation R en plusieurs sous
relations Ri il doit avoir un procédé inverse de reconstitution de la
relation principale R.
– Aucune donnée ne doit se trouver dans plus d'un fragment sauf
dans le cas d'une fragmentation verticale ou la clé primaire doit
être présente partout.
Une fragmentation est correcte lorsqu’elle est :
– Complète : chaque élément de R doit se trouver dans un fragment
– Reconstructible : Pouvoir recomposer R à partir de ses fragments
– Disjointe : chaque élément de R ne doit pas être dupliqué


– Fragmentation Verticale


– Fragmentation Mixte
• La fragmentation mixte consiste à utiliser conjointement
les deux méthodes citées ci-dessus.


– Mise en Œuvre avec les Triggers


• Approche ascendante (Intégration)
– Intégration de bases de données existantes en une seule BD
globale.
– Les schémas conceptuels locaux existent et il faut réussir à les
unifier dans un schéma conceptuel global.


• L’intégration de schéma se fait en 5 étapes
– La traduction des BDs locales en Schémas locaux:
• Identification et la définition des schémas local
– Le Pré-intégration
• Identification des éléments reliés et établissement des règles de
conversion.
– La Comparaison:
• Identification des conflits de noms (synonymes et homonymes)
et des conflits structurels (types, clés, dépendances)
– La conformance
• Résolution des conflits de noms et des conflits structurels
• Définition de règles de traduction
– La fusion et restructuration


Les transactions reparties

• Une transaction
– Un ensemble d'opérations effectuées de manière indivisible sur une
base de données.
– Est soit validée par un Commit, soit annulé par un rollback soit
interrompue par un abort.
• Une transaction doit validée quatre propriétés :
– Atomicité: Toutes les opérations d'une transaction sont menées de
façon indivisible ;
– Cohérence: La transaction doit amener le système d'un état
cohérent vers un état cohérent.
– Isolation: Une transaction en cours ne peut révéler ses résultats à
d'autres transactions si toutes ces opérations n'ont pas été validées.
– Durabilité: Tout résultat produit par une transaction doit être
permanent et ne doit souffrir d'aucune altération, quelques soient
les pannes du système.

• Une transaction reparties
• Constituée de plusieurs transactions locales.
– Une transaction répartie se décompose en une séquence de
transactions centralisées
• La règle ACID est aussi valable en local comme en global
– La gestion en est donc un peu plus compliquée.
• Chaque transaction centralisée est atomique
– Mais une somme de comportements atomiques n'est
pas forcement atomique!
• Besoin de protocoles de terminaison spécifique pour assurer
l'atomicité globale
• Protocole le plus utilisé
– V2P ou Validation deux phases (2 Phase-Commit)

• Validation en 2 phases
– une phase de préparation et une phase de validation
– garantit, à la fin de la transaction, l'entière validation ou
restauration de l'ensemble des modifications apportées aux
ressources
• Explications
– Dans la première phase dite phase de préparation, le site
coordonnateur demande aux sites participants de se préparer
à la validation.
• Lorsqu'il reçoit les notifications positives, Le site
coordinateur lance alors la phase de validation en donnant
l'ordre correspondant aux sites.
• Dans le cas contraire il donne l'ordre d'interrompre les
transactions.

– Cas normal


– Panne d’un participant


– Panne d’un participant (suite)


– Panne du coordinateur


• Alternative de la Validation en 2 phases
• Transaction de compensation


• Bilan

Partie 2:
Les bases de données Répliquées
BDA: Les Bases de données répliquées
Définitions
• La réplication
– Consiste alors à placer plusieurs copies de l’objet sur
différents nœuds ou sites du réseau.
• Dans une base de données distribuée, la réplication permet
d’augmenter :
– la disponibilité des données : Si un site devient non
opérationnel à la suite d’une panne par exemple, une autre
copie est toujours accessible sur un autre site
– les performances d’accès : en augmentant la localité de
référence. Lorsque le coût de communication est un facteur
dominant, le placement d’une copie sur le site ou elle est le
plus souvent accédée favorise les accès locaux en évitant les
accès réseaux.

Problématique
• La réplication

Objectifs
• Augmenter la disponibilité des données
• Augmenter la localité des données et donc les performances
• Réduire la charge réseau (éviter de faire tout converger vers un
serveur unique)
• Supporter la déconnexion des clients mais
• Prend plus de place
• Nécessite des protocoles sophistiqués pour supporter les mises à
jour

Définitions
• Site primaire (ou maître ou référence):
• Accès en lecture et en écriture au niveau application.
• Les transactions de mise à jour sont de plusieurs ordres
notamment : DML, DDL, DCL, TCL
• Site secondaire (ou esclave ou cible).
• Accès au niveau application ce font en lecture seule.
• Que des requêtes SELECT.
• Le SGBD ou le réplicateur gère la mise à jour
• La propagation:
• La mise à jour d’une donnée de référence, sur une donnée
cible.
• Du serveur vers le client

Réplication Asynchrone
• L’écriture asynchrone
• Permet de limiter les temps d’écriture et de définir les intervalles
de synchronisation
• Plus flexible que la réplication synchrone.
• Permet à un site de fonctionner même si un site de réplication
n’est pas accessible.
• Il y a donc un risque pour la cohérence des données.
• C’est un problème sérieux, caractéristique des systèmes en
général, du NoSQL en particulier.
• Les mises à jour se font dans des transactions séparées.
• Le serveur initiateur renvoie la réponse au client immédiatement
après la mise à jour sur sa base de données. Il propage ensuite
la mise à jour aux autres nœuds.
• L’utilisateur peut ainsi déclarer que la synchronisation sera
effectuée la nuit, à une heure de faible affluence.
• Si le site distant est victime d’une panne, l’absence de
synchronisation n’empêche pas la consistance de la base maître
et esclave dans des états de consistance.
• Par contre, le planning de réplication est dans ce cas plus
complexe, puisqu’il s’agit de gérer les conflits émanant d’un
éventuel accès en écriture sur une base esclave entre deux mises
à jour.
• Les algorithmes de réplication asynchrone sont souvent
déterministes : ils appliquent les mises à jour en étant sûrs
qu’elles ne donneront pas d’incohérences.


Réplication Synchrone
• « Réplication en temps réel ».
• Les mises à jour sont effectuées en une seule transaction.
• Il y a une coordination forte entre les nœuds (tous valident la
transaction en même temps ou aucun).
• Chaque requête est déployée sur l’ensemble des bases de
données avant la validation de la requête sur le serveur ou la
requête est exécutée.
• Assure un haut degré d’intégrité des données mais requiert une
disponibilité permanente des serveurs et de la bande passante.
• Mais Il est fortement dépendant des pannes du système
– Nécessite de gérer des transactions multi sites couteuses en
ressources.
• La réponse au client est renvoyée après que les serveurs se
soient coordonnés.
Réplication Synchrone
• « Réplication en temps réel ».
• Comme dans un système centralisé, avant d’accéder à une
donnée, on acquiert un verrou exclusif dessus.
• Avec le protocole RWA (Read One Write All)
– On améliore la disponibilité des lectures en ne demandant le
verrou que sur une copie pour les lectures et sur toutes les
copies pour les écritures.
– Ce protocole est adapté aux pannes avec sa variante ROWA-A
(Read OneWrite All Available), ou seules les copies disponibles
sont mises à jour.
• Dès qu’une copie redevient disponible, elle doit d’abord
être synchronisée avant d’être de nouveau utilisable.

Réplication Asymétrique
• Mono Maitre
– Répartir la charge entre plusieurs esclaves pour améliorer les
performances.
– Dans cet environnement, toutes les écritures et mises à jour doivent
avoir lieu sur le serveur maître.
– La lecture, cependant peut prendre place sur un ou plusieurs
esclaves.
– Ce modèle peut améliorer la performance des écritures (puisque le
maître est dédié aux mises à jour), tout en augmentant la vitesse de
lecture à travers un nombre croissant d’esclaves.
– Au niveau sécurité des données, les données sont répliquées vers
l’esclave et l’esclave peut interrompre le processus de réplication,
– il est possible d’exécuter des services de sauvegarde sur l’esclave
sans corrompre les données de base correspondantes.

Réplication Asymétrique
• Mono Maitre

Réplication Symétrique
• Multi-Serveur
– il n'y a ni base principale ni base secondaire.
– Dans cette approche, les mises à jour peuvent être exécutées
sur n’importe quelle réplique, permet d’améliorer aussi bien
les performances des transactions de lecture seule que
d’écriture.
– L’inconvénient de cette approche est qu’elle requiert des
mécanismes de contrôle de concurrence distribués plus
complexes pour garantir la cohérence mutuelle.

Réplication Symétrique
• Multi-Serveur

Synchrone Asymétrique / Symétrique

• Synchrone Asymétrique
– Une modification sur le site primaire sera propagée aux sites
secondaires à l’aide par exemple d’un trigger sur la table
modifiée.
– La table est modifiée en temps réel sur les autres sites, ces
modifications faisant parties de la transaction.
• Synchrone Symétrique
– Pas de site maître
– Il est alors nécessaire de définir des priorités et de gérer les
blocages des sites en attendant qu’une modification soit
entièrement propagée.
– D’autre part, les triggers doivent différencier les mises à jour
issues d’une réplication des mises à jour de requête directes.

Asynchrone Asymétrique / Symétrique

• Asynchrone Asymétrique
– Temps différé
– Un seul maitre
– Les mises à jour sont stockées dans une file d’attente et ne
seront propagées que lors d’un déclenchement programmé.
• Asynchrone Symétrique
– Temps différé
– Plusieurs maitres
– Toute modification sur toute table de toute base est stockée
dans une file pour être rejouée ultérieurement.
– De fortes incohérences des données sont à craindre.

Cohérence d’un système répliqué

• La cohérence
– La capacité d’un système de gestion de données à refléter
fidèlement les opérations d’une application.
• Un système est cohérent si toute opération (validée) est
immédiatement visible et permanente.
– Si je fais une écriture de d suivie d’une lecture, je dois
constater les modifications effectuées ;
– si je refais une lecture en peu plus tard, ces modifications
doivent toujours être présentes.
• La cohérence dans les systèmes répartis dépend de deux
facteurs :
– la topologie du système (maître-esclave ou multi-nœud)
– le caractère asynchrone ou non des écritures.

• Trois niveaux de cohérence
– Cohérence forte (synchrone Asymétrique)
• Toutes les copies sont toujours en phase, le prix à payer étant
un délai pour chaque écriture.
– Cohérence faible (Asynchrone symétrique):
• Les copies ne sont pas en phase, et rien ne garantit qu’elles le
seront ; cette situation, trop problématique, a été abandonnée
– Cohérence à terme (Asynchrone Asymétrique):
• c’est le niveau de cohérence typique des systèmes NoSQL
• Les copies ne sont pas immédiatement en phase, mais le
système garantit qu’elles le seront « à terme ».
• Dans la cohérence à terme, il existe un risque, faible mais réel,
de constater de temps en temps un décalage entre une écriture
et une lecture.

• Trois niveaux de cohérence


• Trois niveaux de cohérence : la cohérence forte
Premier cas (A en haut à gauche) :
– La topologie est de type maître-esclave avec des écritures
synchrones.
– Toutes les écritures se font par une requête adressée au
nœud maître qui se charge de les distribuer aux nœuds
esclave.
– L’acquittement n’est envoyé au client que quand toutes les
copies sont en phase.
– Assure la cohérence forte, car toute lecture du document,
quel que soit le nœud sur lequel elle est effectuée, renvoie la
même version, celle qui vient d’être mise à jour.
– Cette cohérence se fait au prix de l’attente que la
synchronisation soit complète, et ce à chaque écriture.

• Trois niveaux de cohérence : Cohérence à terme
Dans le second cas (B):
– la topologie est toujours de type maître esclave avec des
écritures sont asynchrones.
– La cohérence n’est plus forte
• Si la lecture s’effectue avant la synchronisation, il est possible
que la version du document retournée soit non pas d mais d-1,
celle qui précède la mise à jour.
– C’est le mode d’opération des NoSQL, qui autorisent donc un
décalage potentiel entre l’écriture et la lecture.
– La garantie est cependant apportée que ce décalage est
temporaire et que toutes les versions vont être synchronisées
« à terme » (délai non précisé).
• On parle donc de cohérence à terme (eventual consistency en
anglais). Dr Edouard Ngor SARR 59

• Trois niveaux de cohérence : Cohérence faible
Enfin, le dernier cas (C):
– Il correspond à une topologie multi nœuds, en mode
asynchrone.
– Les écritures peuvent se faire sur n’importe quel nœud, ce qui
améliore la scalabilité du système.
– L’inconvénient : deux écritures concurrentes du même
document peuvent d’effectuer en parallèle sur deux nœuds
distincts.
– Au moment où la synchronisation s’effectue, le système va
découvrir (au mieux que les deux versions sont en conflit.
– Le conflit est reporté à l’application qui doit effectuer une
réconciliation (il n’existe pas de mode automatique de
réconciliation).
Modèles d’appartenance
Modèle d'appartenance fixe (PRIMARY COPY ou
MonoMaitre)
• Dans ce modèle, seul le site primaire peut mettre à jour, les sites
cibles ne recevant que des copies en lecture.

Modèles d’appartenance
Modèle d'appartenance dynamique (UPADTE
EVERYWHERE)
• Le site primaire peut être différent au cours du temps, en
fonction d'événements: panne d'un site, état de la donnée, etc.

Détection des modifications

Solution 1 : utilisation du journal
• les transactions qui modifient écrivent une marque spéciale dans
le journal
• détection périodique en lisant le journal, indépendamment de la
transaction qui a modifié
• modification de la gestion du journal
Solution 2 : utilisation de triggers

• la modification d'une donnée répliquée déclenche un trigger
• général et extensible
• la détection fait partie de la transaction et la ralentit

A suivre :
TPs & Projet A rendre
BD Reparties & Répliquées sous MySQL
et sous Oracle
Administration des bases de données
Liens Utiles
1. SIRES, M. M. E. I. O. COURS BASES DE DONNEES REPARTIES
Nakechbandi M., LITIS, Email: nakech@ free. fr.
2. SIRES, M. M. E. I. O. COURS BASES DE DONNEES REPARTIES.
3. Molli, P., Oster, G., & LORIA, I. L. (2005). Replication des données.
4. Moussa, R. (2005). Systèmes de Gestion de Bases de Données
Réparties & Mécanismes de Répartition avec Oracle.
5. https://phelepjeremy.wordpress.com/2018/01/15/replication-de-bases-
de-donnees-mysql-maitre-esclave/
6. http://libresavoir.org/index.php?title=R%C3%A9plication_des_bases_d
e_donn%C3%A9es_MySQL_%28installation_et_configuration%29#:~:
text=La%20r%C3%A9plication%20de%20bases%20de,s%C3%A9lecti
onn%C3%A9es)%20se%20synchronisent%20entre%20elles.
7. https://fr.wikibooks.org/wiki/MySQL/R%C3%A9plication
8. http://www.responsive-mind.fr/replication-mysql-master-master/

Master en Informatique
Les Bases de Données

avancées (BDA)
Par
Dr Edouard Ngor SARR
Enseignant-chercheur en Informatique
Université Assane SECK de Ziguinchor
Edouard-ngor.sarr@univ-zig.sn
CERIDES UCAO & Check4Decision Project
Fevrier 2023

Cours BD Avancées DR SARR UASZ

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours BD Avancées DR SARR UASZ

Transféré par

Droits d'auteur :

Formats disponibles

Master en Informatique

Les Bases de Données

– L'augmentation du volume de données

– L'augmentation du volume de traitements

Dr Edouard Ngor SARR 4

Dr Edouard Ngor SARR 7

Objectifs d’un BDR

Dr Edouard Ngor SARR 12

Dr Edouard Ngor SARR 13

Dr Edouard Ngor SARR 14

Dr Edouard Ngor SARR 15

Dr Edouard Ngor SARR 16

Approches de Conception des BDR

Approches de Conception des BDR

Dr Edouard Ngor SARR 18

Approches de Conception des BDR

Dr Edouard Ngor SARR 19

Approches de Conception des BDR

Dr Edouard Ngor SARR 20

Approches de Conception des BDR

Dr Edouard Ngor SARR 21

Approches de Conception des BDR

Dr Edouard Ngor SARR 22

Approches de Conception des BDR

Dr Edouard Ngor SARR 23

Approches de Conception des BDR

Dr Edouard Ngor SARR 24

Approches de Conception des BDR

Dr Edouard Ngor SARR 25

Approches de Conception des BDR

Dr Edouard Ngor SARR 26

Approches de Conception des BDR

Dr Edouard Ngor SARR 27

Approches de Conception des BDR

Approches de Conception des BDR

Dr Edouard Ngor SARR 29

Les transactions reparties

Les transactions reparties

Les transactions reparties

Les transactions reparties

Dr Edouard Ngor SARR 33

Les transactions reparties

Dr Edouard Ngor SARR 34

Les transactions reparties

Dr Edouard Ngor SARR 35

Les transactions reparties

Dr Edouard Ngor SARR 36

Les transactions reparties

Dr Edouard Ngor SARR 37

Les transactions reparties

Dr Edouard Ngor SARR 38

Dr Edouard Ngor SARR 40

Dr Edouard Ngor SARR 41

Dr Edouard Ngor SARR 42

Dr Edouard Ngor SARR 43

Dr Edouard Ngor SARR 45

Dr Edouard Ngor SARR 46

Dr Edouard Ngor SARR 48

Dr Edouard Ngor SARR 49

Dr Edouard Ngor SARR 50

Dr Edouard Ngor SARR 51

Dr Edouard Ngor SARR 52

Synchrone Asymétrique / Symétrique

Dr Edouard Ngor SARR 53