BD parallèles et réparties

Transcription

LOG660 - Bases de données de haute performance
BD parallèles et réparties
Département de génie logiciel et des TI
BD parallèles vs réparties
■
BD réparties
–
–
■
Les données se trouvent sur plusieurs sites (noeuds)
Chaque site possède un certain degré d’autonomie
BD parallèles
–
–
Exploitent le parallélisme à l’intérieur d’un même site
Peuvent utiliser plusieurs processeurs et/ou disques
© R. Godin, C. Desrosiers - Hiver 2011
2
Bases de données réparties
BD
locale
Réseau
Programme
d'application
Logiciel
intermédiaire
Pilote de
télécommunication
Réseau
SGBD réparti
SGBD réparti
Logiciel
intermédiaire
Pilote de
télécommunication
Logiciel
intermédiaire
Pilote de
télécommunication
Serveur de
données
Serveur de
données
Client
■
■
BD
locale
BD répartie dans deux sites
Chaque site peut avoir une architecture parallèle
3
Bénéfices de BD réparties
■
Performance
–
Coûts de transfert réduits en rapprochant les données de leurs
traitements
■
–
■
Parallélisme entre les sites (peu évident en pratique)
Fiabilité et disponibilité
–
■
Ex: clients des succursales de Montréal dans une BD située à
Montréal
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 noeud, au lieu de remplacer le serveur
4
Complexité des BD réparties
■
Transparence de la répartition
–
–
–
■
Gestion des transactions réparties
–
■
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
Maintenir les propriété d’atomicité, isolation et durabilité des
transactions est plus complexe dans un contexte réparti
Évaluation 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
5
Architectures réparties
1. SGBD répartis homogènes
2. Multi-SGBD
3. SGBD fédérés
6
SGBD répartis homogènes
Application 2
Application 1
Site 1
Site 2
(Oracle)
(Oracle)
Application 3
■
■
■
Toutes les BD suivent un même schéma et utilisent la même
technologie (ex: Oracle)
Accès aux données et gestion des transactions réparties souvent fait
de manière centralisée
Plus grande fiabilité et performance dû à un meilleure couplage
entre les sites
7
Multi-SGBD
Application 2
Application 1
Site 1
Site 2
(Oracle)
(MySQL)
Application 3
■
■
■
■
Chaque site est autonome et peut avoir un SGBD de type différent
Aucun interface (ex: schéma conceptuel) commun
Accès aux données fait à partir de requêtes ad-hoc spécialisées
Peut devenir très complexe à gérer
8
SGBD fédérés
BD répartie virtuelle
Application 1
Site 1
Site 2
(Oracle)
(MySQL)
Application 2
Application 3
Interface d’accès commun
■
■
■
Intègre plusieurs SGBD autonomes et potentiellement hétérogènes
en une seule BD virtuelle
Interface d’accès commun pour masquer l’hétérogénéité des BD et
la répartition des données
Mécanismes de coordination communs (ex: protocole XA 2-phases)
9
SGBD fédérés
■
Application type:
–
■
■
Consolidation des données après la fusion/acquisition de
compagnies
Inconvénients:
–
Intégration du schéma
–
Réécriture des requêtes complexes
–
Performance limitée.
Produits commerciaux:
–
IBM InfoSphere Federation Server, Oracle Data Service Integrator,
etc.
10
Architecture des schémas
Applications
Schéma
externe
Schéma
externe
...
Schéma
externe
Schéma
conceptuel
global
BD distribuée
Schéma de
localisation
Schéma
local
Schéma
local
...
Schéma
local
BD réparties
11
Duplication répartie
■
Copie partielle ou totale d’une ou plusieurs tables maîtresses
situées sur des sites distants
■
Accès plus rapide aux données car moins de transferts
■
Redondance assure la disponibilité des données si une des
copies n’est plus accessible
■
Permet de contrôler l’accès en limitant les données distantes qui
sont accessibles localement
■
La synchronisation entre la table maîtresse et sa copie locale
peut être synchrone ou asynchrone
12
Duplication répartie
■
■
Duplication synchrone (synchronous replication)
–
La sérialisabilité est assurée sur l’ensemble des noeuds
–
Une transaction est confirmée seulement lorsque tous les sites ont
été mis à jour
Duplication asynchrone (asynchronous replication)
–
Les mises-à-jour sont d’abord faites sur une copie primaire
Les sites de réplication sont mis-à-jour en différé, à partir de la
copie primaire, après la confirmation de la transaction
–
Ex. d’implémentation: vues matérialisées
–
13
Fragmentation répartie
■
Découpe 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)
■
Deux types de fragmentation:
1. Fragmentation horizontale
2. Fragmentation verticale
14
■
Fragmentation horizontale
Table
col 1
col 2
col 3
col 4
col 5
col 6
col 1
col 1
col 1
Fragment 1
Fragment 2
…
–
–
Chaque fragment contient un sous-ensemble de lignes
Ex: comptes des clients de Montréal sur le site de Montréal
15
■
Fragmentation verticale
Table
col 1
col 2
col 3
Fragment 1
–
–
–
col 4
col 5
col 6
col 1
col 1
Fragment 2
col 1
…
Chaque fragment contient un sous-ensemble de colonnes
Ex: la colonne des salaires sur le site de la comptabilité
Moins utilisé que la fragmentation horizontale
16
Transactions réparties
Transactions
réparties
Gestionnaire de
transaction
Gestionnaire de
transaction
Gestionnaire de
l'ordonnancement
Gestionnaire de
l'ordonnancement
Gestionnaire de
données
Gestionnaire de
données
BD et journal
BD et journal
Site
coordonnateur
Site participant
Site coordonnateur:
À l’origine de la transaction
répartie
Site participant:
Coopère avec le gestionnaire de
transaction du site coordonnateur
17
Protocole de confirmation en deux phases
(Two-phase commit – 2PC)
Site coordonnateur (usager)
Site participant (données)
Début
Ecrire préparer
au journal
Préparer à confirmer
Vote OK
Attente
Tous ont
répondu OK
Début
Ecrire prêt au
journal (vider
tampons journal)
Non Ecrire annuler
au journal
Annuler
Prêt
Confirmer
Oui
Ecrire confirmer
au journal
Oui
Accepter
Confirmé
Annulé
Confirmer?
Ecrire confirmer
au journal
Non
Ecrire annuler
au journal
Accepter
Confirmé
Annulé
Ecrire fin de
la transaction
au journal
18
Protocole de confirmation en deux phases
(Two-phase commit – 2PC)
■
Phase 1: demande de confirmation
–
■
Phase 2: confirmation
–
–
–
■
Le coordonnateur demande aux participants de confirmer ou
infirmer le succès des transactions locales
Le coordonnateur reçoit les réponses des sites participants
Si tous les participants ont confirmé le succès, le coordonnateur
autorise les participants à compléter les transactions locales
(écriture du commit dans leur journal)
Sinon, le coordonnateur demande aux participants d’annuler les
transactions locales
Note: les ressources sont bloquées (verrous) durant l’attente de
la confirmation
19
Optimisation de requête répartie
■
Requêtes répartie vs locales
–
–
■
■
Requête locale: le principal coût provient des écritures et lectures
(E/S) en mémoire secondaire (ex: disques durs)
Requête répartie: le coût des E/S peut être inférieur à celui des
transferts de données entre les sites
Parallélisme intra-opération
–
Parallélisation des sélections, jointures, etc.
–
Rarement avantageux dans les architectures réparties
Parallélisme inter-opération
–
Calcule simultanément plusieurs opérations d’une même requête
–
Plus avantageux dans le contexte réparti
20
Étapes
d’optimisation
Requête (ex:SQL)
Décomposition
Schéma
conceptuel &
externe global
Requête interne
globale
Localisation
des données
Schéma de
localisation
Site
coordonnateur
Requête sur
fragments
Optimisation
globale
Statistiques sur
fragments
Plan d'exécution
réparti
Optimisation locale
Shéma interne
local & statistiques
Site participant
Plan d'exécution
local
21
Optimisation globale (sans parallélisme)
■
■
Exemple: jointure entre les tables T1, T2 et T3
Chaque site Si contient une seule table Ti
Plan 1 :
Transférer T1 au site 2
T1 ⋈ T2 = R au site 2
Transférer R au site 3
R ⋈ T3 = Résultat final au site 3
Plan 2 :
T1 ⋈ T2 = R au site 1
R ⋈ T3 = Résultat final au site 3
Règle:
Transférer la plus petite
table d’abord
Plan 3 :
T1 ⋈ T2 ⋈ T3 = Résultat final au site 3
22
Stratégie par semi-jointure
Plan 1 (sans optimisation) :
T1  T2 = Résultat final au site 1
Plan 2 (stratégie par semi-jointure):
Transférer πA(T2) au site 1
T1  πA(T2) (= T1  T2) = R au site 2
R  T2 = Résultat final au site 2
■
Stratégie:
–
–
–
Transférer au site 1 seulement les colonnes de T2 nécessaires à la
semi-jointure (ensemble A)
Renvoyer ensuite au site 2 le résultat de la semi-jointure pour
compléter la jointure avec les autres colonnes
Note: le nombre de lignes de T1! T2 doit être petit comparé au
nombre de lignes de T2: taille de πA(T2) + taille de R < taille de T2
23
Parallélisme inter-opération et inter-site
■
Opération : T1 ! T2 ! T3 ! T4
T1 ! T2 = R au site 1
En parallèle, transférer T4 au site 3
T3 ! T4 = S au site 3
Transférer S au site 1
Ensuite, R ! S = Résultat final au site 1
24
BD répartie avec Oracle (DATABASE LINKS)
■
Permet à un usager local d’accéder aux tables d’une autre BD
sans qu’il soit usager de cette BD
■
Syntaxe:
CREATE [SHARED] [PUBLIC] DATABASE LINK nomLien
CONNECT TO compteUsager IDENTIFY BY motDePasse
USING nomService
–
SHARED: permet de partager la connexion entre plusieurs usagers
–
PUBLIC : rend le lien disponible à tous les usagers locaux
–
nomService : doit être défini dans un fichier de configuration de la
BD
25
BD répartie avec Oracle (DATABASE LINKS)
■
Exemple: accès au catalogue de produits en Grande-Bretagne
CREATE DATABASE LINK site.europe.uk
CONNECT TO Compte14 IDENTIFY BY ”abc123”
USING SID_siteUK
SELECT * FROM [email protected]
26
Transparence de localisation (SYNONYM)
■
Synonyme
–
–
Évite aux applications de devoir connaître la localisation des
données (transparence de localisation)
Permet de conserver les mêmes requêtes, même si le lien change
CREATE [PUBLIC] SYNONYM nomSynonyme
FOR [nomSchéma].nomObjet[@lienBD]
■
Exemple (suite):
CREATE SYNONYM CatalogueEurope
FOR [email protected]
SELECT * FROM CatalogueEurope
WHERE ...
27
Duplication avec vues matérialisées
■
Syntaxe:
CREATE MATERIALIZED VIEW nomVue
[REFRESH {FAST|COMPLETE|FORCE} [ON COMMIT|ON DEMAND]]
[FOR UPDATE]
–
–
–
–
–
–
FAST: mise-à-jour incrémentale de la copie locale
COMPLETE: mise-à-jour complète de la copie locale à chaque
rafraîchissement
FORCE: mise-à-jour incrémentale lorsque possible, sinon complète
ON COMMIT: rafraîchissement lorsqu’une transaction modifiant les
tables maîtresses fait un commit
ON DEMAND (défaut): rafraîchissement sur demande de l’usager
(l’instant peut être spécifié avec les clauses START et NEXT)
FOR UPDATE: permet de mettre à jour la copie locale (les changements
sont propagés aux tables maîtresses)
28
Duplication avec vues matérialisées
■
Exemple: copie locale du catalogue européen
CREATE MATERIALIZED VIEW CatalogueComplet
REFRESH FAST ON COMMIT
AS
(SELECT * FROM [email protected])
UNION
(SELECT * FROM CatalogueCanada)
SELECT * FROM CatalogueComplet
WHERE ...
29
Bases de données parallèles
■
■
Exploitation du parallélisme intrasite
Parallélisme de disques et d’unités de traitement
Unité de
traitement
Disque
■
■
Disque
Mémoire vive
Disque
Disque
Disque
Améliorent la fiabilité en dupliquant les données (ex: disques
miroirs)
Augmentent la performance en permettant de traitement en
parallèle des requêtes
30
Parallélisme de disque
■
Disques miroirs:
–
■
A
Les données d’un disque maître sont dupliquées sur un autre
disque
Code détecteur/correcteur d ’erreur
–
–
■
A
Utilise un certain nombre de bits dans les données pour
détecter une corruption et possiblement la corriger
Ex: bit de parité, code de Hamming
Répartition cyclique (striping)
–
–
Améliore la performance en lecture/écriture par l’utilisation
de plusieurs disques en parallèle
Répartit les données sur plusieurs disques, soit par bit (bit-level
striping) ou par bloc (bloc-level striping)
31
Architectures RAID (Redundant Array of Independent Disks )
Raid 0 : Répartition par bloc
■
RAID 0
–
■
RAID 1
–
■
Répartition par bloc
Disque de parité
RAID 5
–
–
–
■
Répartition par bit (ou octet)
Un disque de parité (détection)
Récupération d’une faute d’un
disque
RAID 4
–
–
■
Codes correcteurs (ex: Hamming)
Moins de disque que 1
RAID 3
–
–
–
■
Disques miroirs
Bloc 0
Bloc 4
Bloc 8
...
Bloc 1
Bloc 5
Bloc 9
...
Bloc 2
Bloc 6
Bloc 10
...
Bloc 3
Bloc 7
Bloc 11
...
Raid 1 : Mirroirs
Raid 0+1
RAID 2
–
–
■
Blocs de parité répartis
Permet les écritures parallèles
RAID 6
–
–
Codes correcteurs répartis
A
A
B
B
Bloc 0
Bloc 2
Bloc 4
...
Bloc 1
Bloc 3
Bloc 5
...
Bloc 0
Bloc 2
Bloc 4
...
Bloc 1
Bloc 3
Bloc 5
...
Raid 2 : Codes correcteurs d’erreurs
A1
B1
C1
A2
B2
C2
A3
B3
C3
A4
B4
C4
CCEA1
CCEB1
CCEC1
CCEA2
CCEB2
CCEC2
CCEA3
CCEB3
CCEC3
Raid 3 : Répartition par bit + parité
Bit 0
Bit 4
Bit 8
...
Bit 1
Bit 5
Bit 9
...
Bit 2
Bit 6
Bit 10
...
Bit 3
Bit 7
Bit 11
...
Parité
Raid 4 : Répartition par bloc + parité
Bloc 0
Bloc 4
Bloc 8
...
Bloc 1
Bloc 5
Bloc 9
...
Bloc 2
Bloc 6
Bloc 10
...
Bloc 3
Bloc 7
Bloc 11
...
Parité
Raid 5 : Répartition par bloc + parité répartie
Parité
Bloc 4
Bloc 8
Bloc 12
Bloc 16
Bloc 0
Parité
Bloc 9
Bloc 13
Bloc 17
Bloc 1
Bloc 5
Parité
Bloc 14
Bloc 18
Bloc 2
Bloc 6
Bloc 10
Parité
bloc 19
Bloc 3
Bloc 7
Bloc 11
Bloc 15
Parité
32
Principales architectures RAID
■
RAID 1:
– Duplication complète des données à l’aide de disques miroirs
– Très haut niveau de fiabilité au coût d’un espace disque important
– Met l’emphase sur la fiabilité, pas la performance
■
RAID 0+1:
– Combine la répartition par bloc de RAID 0 avec les disques miroirs
de RAID 1
– Offre fiabilité et performance, mais demande beaucoup d’espace
■
RAID 5:
– Répartition par blocs (sans duplication) avec bits de parité répartis
– Offre la performance et une certaine fiabilité (détection d’erreur),
sans exiger beaucoup d’espace
33
Fragmentation de tables (contexte parallèle)
■
Découpe une grosse table en morceaux plus facilement gérables
■
Très utilisée dans les entrepôts de données
Permet le parallélisme intra-opérations (ex: accélération des balayages,
sélections, jointures, etc.)
■
■
■
Partitionnement par intervalles de valeur:
– Ex: partitionnement de transactions selon l’année
– Accélère les sélections par valeurs et par intervalles de valeurs sur la
clé de partitionnement
Partitionnement par hashage sur la clé
– Ex: hashage de la clé primaire de la table
– Assure une distribution uniforme des lignes dans les partitions
– Accélère uniquement les sélections par valeur sur la clé de
partitionnement
34
Partitionnement par intervalles de valeurs
■ Exemple: partitionnement selon la date de transaction
CREATE TABLE Transaction (
id INTEGER INTEGER NOT NULL,
idClient
INTEGER NOT NULL,
idProduit INTEGER NOT NULL,
jour
INTEGER DATE NOT NULL,
...
)
PARTITION BY RANGE(jour)
( PARTITION P1999ouMoins VALUES LESS THAN TO_DATE(’01/2000’,’MM/YYYY’)
TABLESPACE TS1999ouMoins
PARTITION P2000 VALUES LESS THAN TO_DATE(’01/2001’,’MM/YYYY’)
TABLESPACE TS2000
PARTITION P2001 VALUES LESS THAN TO_DATE(’01/2002’,’MM/YYYY’)
TABLESPACE TS2001 );
-- Acces a la partition des transactions de 2001 à 2002
SELECT * FROM Transaction PARTITION(P2001);
-- Ajout d’une partition
ALTER TABLE Transaction ADD PARTITION (PARTITION P2002 VALUES LESS THAN
TO_DATE(’01/2003’,’MM/YYYY’) TABLESPACE TS2002);
35
Sélection parallèle
Sélection
globale
■
■
■
Sélection
locale
Sélection
locale
Sélection
locale
Fragment 1
Fragment 2
Fragment 3
On sélectionne les lignes simultanément dans chaque fragment
On concatène les lignes obtenues de chaque fragment
Si la sélection se fait par rapport à la clé de partitionnement:
–
On peut ignorer les fragments dont l’intervalle (ou la valeur de hashage)
ne contient pas les valeurs recherchées
36
Jointure parallèle
■
Conditions préalables:
–
–
■
■
Les tables R et S ont été partitionnées selon la même clé
La jointure est faite selon cette clé
On limite la jointure aux paires de lignes dans les fragments
ayant la même valeur pour la clé:
Fragment 1 R
Jointure
locale
Fragment 1 S
Fragment 2 R
Jointure
locale
Fragment 2 S
Fragment 3 R
Jointure
locale
Fragment 3 S
Similaire à la jointure par hashage (HASH JOIN)
37
Autres formes de parallélisme
■
Plusieurs processeurs
■
Plusieurs unités de mémoire
■
Duplication des processus SGBD
–
Processus miroirs pour fiabilité
38
Architecture à mémoire partagée
(Symmetric MultiProcessor – SMP)
Unité de
traitement
Disque
■
■
■
Unité de
traitement
Disque
Unité de
traitement
Disque
Disque
Mémoire vive
Disque
Plusieurs processeurs qui partagent la même mémoire centrale
Mécanisme d’interconnexion très rapide (bus de données)
Processus parallèles communiquent rapidement à travers la mémoire
centrale partagée (goulot d’étranglement)
39
Architecture à disques partagés
Mémoire vive
Mémoire vive
Mémoire vive
Mémoire vive
Unité de
traitement
Unité de
traitement
Unité de
traitement
Unité de
traitement
Disque
■
■
■
■
Disque
Disque
Disque
Disque
Chaque unité de traitement possède sa propre mémoire vive
Les disques sont partagés entre les unités de traitement
Évite le goulot d’étranglement au niveau de la mémoire, mais
complexifie la communication entre les processus
Ex: architecture en grappe (cluster) - À NE PAS CONFONDRE AVEC
LES TABLE CLUSTERS
40

BD parallèles et réparties

Transcription

Documents pareils

fp 350104 Chamonix XXL version Céramique

AU TRAIT-CARRÉ : L`artiste-peintre québécois, JG - Multi-Art.

Titre : AIMER SANS CONDITIONNEL

fp 3721A Petit Godin

fp 368101 Grand Bois

fp 366102 Petit Carvin

363102 "Poêle L`Eco"

LE RIOPFQ ET L`ASSOCIATION EMMANUEL, L`AMOUR QUI