Architectures

des BD
réparties

1
Conception de BDD

Il n'existe pas de méthode miracle pour trouver la solution optimale.

L'administrateur doit donc prendre des décisions en fonction de

critères techniques et organisationnels avec pour objectif de minimiser:
• le nombre de transferts entre sites
• les temps de transfert,
• le volume de données transférées,
• les temps moyens de traitement des requêtes,
• le nombre de copies de fragments,
• etc...

2
Conception de BDD

Conception descendante (top down design).

On commence par:
1. Définir un schéma conceptuel global de la base de données
répartie,
2. Distribuer le schéma sur les différents sites en des schémas
conceptuels locaux.

L’approche top down est intéressante quand on part du néant. Si

les BDs existent déjà la méthode bottom up est utilisée.
3
Conception de BDD

Conception ascendante (bottom up design)

• L’approche se base sur le fait que la répartition est déjà faite, mais il
faut réussir à intégrer les différentes bases de données existantes en
une seule BD globale.

• En d’autres termes, les schémas conceptuels locaux existent et il faut

réussir à les unifier dans un schéma conceptuel global.

4
Design de BDD

Les données sont placées sur les sites de deux façons:

• Partitionnée: la base de données est divisée en partitions disjointes

dont chacune est placée sur un site différent.

• Répliquée: peut-être soit entièrement répliqué où toute la base de

données est stockée à chaque site, ou partiellement répliqué où
chaque partition de la base de données est stockée sur plusieurs
sites, mais pas sur tous les sites.

5
Design de BDD

• Pour les BDD nous avons un répertoire qui contient en plus des
meta-informations sur les données, des informations sur la
localisation des données.
• Même le répertoire peut être globale ou local pour chaque site, centr
alisé ou distribué sur plusieurs sites avec une ou plusieurs copies.

• Contrôle des données distribuées: implique la gestion des vues,

contrôle d'accès et application de l'intégrité.

6
Design de BDD

• Traitement de requête distribué: avec la conception d'algorithmes

qui analysent les requêtes et les convertissent en une série
d'opérations de manipulation de données.

• Les facteurs à prendre en compte pour les requêtes distribués sont la

distribution des données, les coûts de communication et le manque
d'informations disponibles localement.

• L'objectif est l'optimisation de la requête.

7
Design de BDD
• Contrôle de l'accès concurrent distribuée: implique la synchronisation des
accès aux bases de données distribués, de sorte que l'intégrité de la base
de données soit maintenue.

• Deux solutions:
 Pessimiste: synchroniser l'exécution des requêtes des utilisateurs avant le début de
l'exécution.
 Optimiste: exécuter les requêtes puis vérifier si l'exécution a compromis la cohérence de
la base de données.
• Deux approches: Locking l'exclusion mutuelle des accès aux données
et Timestamping où les exécutions des transactions sont ordonnées en
fonction des horodatages.
8
Design de BDD Ressource 1

Processus Processus
1 2

Ressource 2

• Difficulté de l'accès concurrent – Détection de deadlocks

• Le deadlock est une situation dans laquelle un ensemble de processus est

bloqué car chaque processus détient une ressource et attend une autre
ressource acquise par un autre processus.

• WaitingFor et AssignedTo pour chaque processus/ressource.

9
Design de BDD
• La fiabilité implique pour les BDD lorsqu'une panne se produit et que divers
sites deviennent inopérants ou inaccessibles, les bases de données sur les
sites opérationnels restent cohérentes et à jour.

• Réplication (partiel ou complet): ce fait principalement par deux protocoles:

 Eager en forçant les mises à jour à être appliquées à toutes les répliques avant
la fin de la transaction.
 Lazy ils peuvent être paresseux pour que la transaction mette à jour une copie
(appelée le Master) à partir de laquelle les mises à jour sont propagées aux
autres après que la transaction est terminée.

10
 Intégration des multibases de données
nécessite un réexamen de certaines
des techniques fondamentales des
Design de BDD bases de données et des défis de
conception et traitement des requêtes.

Exemple: Combinaison de plusieurs

types de bases de données comme
MongoDB, Neo4J, SQLServer

11
 Architecture logique 12

BD centralisée BD distribuée
3 niveaux 4 niveaux
Schéma Schéma Schéma Schéma
externe externe externe externe

Schéma Schéma
conceptuel global

Schéma Schéma Schéma

Schéma conceptuel conceptuel conceptuel
physique local local local

Schéma Schéma Schéma

Physique Physique Physique
local local local

Schéma externe: chaque application ne voit que la partie (schéma) des données du système global qui la concerne.
 Architecture logique 13

BD centralisée BD distribuée
3 niveaux 4 niveaux
Schéma Schéma Schéma Schéma
externe externe externe externe

Schéma Schéma
conceptuel global

Schéma Schéma Schéma

Schéma conceptuel conceptuel conceptuel
physique local local local

Schéma Schéma Schéma

Physique Physique Physique
local local local

Schéma global: contient ensemble des types de données; Pas forcément matérialisé et donc chaque base locale
implémente sa partie
Design de BDD

• Le Big Data est caractérisé par: Volume: La taille des données; Variété:
Données hétérogènes (pdf, audio, …); Vélocité ou vitesse: le rythme de
génération de données; Variabilité: L’incohérence que montrent
les mêmes données à des moments différents.

• Ces efforts prennent généralement deux formes : développement des

plates-formes informatiques à usage général (évolutives comme Google File
System ou HDFS) , et l'autre des SGBD spéciaux qui n'ont pas toutes les
fonctionnalités relationnelles, avec des capacités de gestion des données
plus flexibles (les systèmes NoSQL).

14
Architecture des BDD
Typologie de BDDs:
concerne l’étude de l’autonomie, la distribution entre les sites et la nature des
données

• Autonomie.
• Distribution.
• Hétérogénéité.

15
Architecture des BDD
Autonomie:
Fait référence au degré avec lequel une des bases locales peut travailler
indépendamment des autres, en parle de la distribution du contrôle
(SGBD) et pas des données. On peut distinguer trois niveaux:

1. Intégration avancée: Une image globale et unique est offerte aux

utilisateurs. Dans ces systèmes étroitement intégrés, les gestionnaires de
données sont mis en œuvre de manière à ce que l'un d'eux contrôle le
traitement de chaque demande d'utilisateur, même si cette demande est
traitée par plus d'un gestionnaire de données.

16
Architecture des BDD
Autonomie:

2. Autonomie partielle: Les SGBD locaux peuvent opérer indépendamment,

mais ils participent à une collection de bases qui coopèrent et partagent leurs
données locales.

3. Isolation totale: Le SGBD ignore l'existence des autres bases locales. Il n'y
a pas de contrôle global quant à l'exécution d'une transaction sur les
différentes bases locales.

17
Architecture des BDD
Distribution:
Fait référence à la distribution des machines:

Client/Serveur: type de communication pour lequel une machine offre

des services appelée serveur et des machines qui demandent des services
appelées clients.
Inconvénient: sensible aux problèmes de pannes des serveurs.

Peer2Peer: toutes les machines ont une importance équivalente.

Inconvénient: engendre énormément de communication pour toute décision.

18
Architecture des BDD
Hétérogénéité:
Fait référence au modèle de données, les moteurs de requêtes et les
protocoles de gestion des transactions.
Hétérogénéité matérielle et différences dans les protocoles de mise en réseau.

Exemples:
Modèle de données: relationnel, orienté objet ou non relationnel.
Requête: Même dans le model relationnel il y a T-SQL , PL-SQL … etc

19
 Distribution
SGBD NoSQL SGBD P2P

Architecture
des BDD client/serveur

Système
Schéma BD répartie: MultiDataBase

Autonomie

sqlite

Hétérogénéité

20
Architecture des BDD

Il y a idéalement quatre architectures qui peuvent néanmoins se joindre et se

confondre dans la réalité.

• Client/Serveur.
• Peer2Peer.
• Base de données fédérée ou multiple.
• Cloud.

21
Architecture des BDD
Client/Serveur:

C'est une architecture a deux niveaux, elle distingue les fonctionnalités qui
incombe au serveur de celle du client.

Le serveur de BD se charge du traitement de requêtes, optimisation,

management des transactions et du stockage.

Le client (GUI ou ligne de commande) se charge du requêtage.

22
Architecture des BDD
• Client/Serveur:

• Multi-Client/ Un serveur: l'architecture la

plus simple où chaque client manage sa
propre connection.
• Multi-Client/ Multi-Serveur, deux stratégies
sont possibles:
 soit les clients prennent toute la
responsabilité du choix du
serveur, cela donne plus de travail au
client en parle de "client lourd".
 Soit les serveurs prennent en
charge toute la responsabilité.
23
Architecture des BDD
• Client/Serveur:

Avantages quand les serveurs prennent en

charge toute la responsabilité:

 Améliorer la performance et l'intégration

du couple Base de Données/ Système
d'exploitation.

 Exploiter les avancées des équipements

avec GPU et les FPGA pour augmenter
les performances la disponibilité
des données.
24