Dans cette partie, nous donnons quelques généralités afférentes aux bases de données réparties (distribuées) et aux mécanismes de base de la réplication.
3.2.1 Objectifs et principes des bases de données réparties
Une base de données répartie est une collection de sites connectés par un réseau de communi-cation.Chaque site est une base de donnée centralisée qui stocke une portion de la base de données. Chaque donnée est stockée exactement sur un seul site [BHG87]. La gestion d’une base de don-nées répartie est gérée de manière transparente par un SGBD réparti. Les transactions peuvent être envoyées sur chaque site puis traduites en transactions locales avant d’être routées sur les sites ap-propriés (stockant une portion des données manipulées). Les résultats sont intégrés puis renvoyés aux applications clientes. Pour améliorer les performances, les données peuvent être répliquées sur plusieurs sites. La principale motivation de la réplication des données est l’augmentation de la dis-ponibilité. En stockant les données critiques sur plusieurs sites, la base de données distribuée peut fonctionner même si certains sites tombent en panne. Un second avantage de la réplication consiste à l’amélioration des temps de réponses des requêtes grâce à la parallélisation des traitements et un accès plus facile et rapide des données. Cependant, l’introduction de la réplication introduit un nouveau problème car si une réplique est mise à jour à travers une transaction, toutes les autres répliques devraient l’être pour garantir la cohérence mutuelle, ce qui signifie que toutes les copies sont identiques. Ce faisant, il est évident que plus le nombre de répliques est grand, plus le coût du maintien de la cohérence est important. Par conséquent, il doit exister un compromis entre gestion de la cohérence et les performances (passage à l’échelle, latence, ...). Ce compromis dépend surtout des types d’applications conduisant à plusieurs mécanismes de réplication que nous allons décrire très brièvement dans la prochaine section.
3.2.2 Mécanismes de réplication
La réplication a fait l’objet de plusieurs études dans le contexte des systèmes distribués et aussi dans les bases de données répliquées. La motivation principale est la disponibilité pour les systèmes distribués et la performance (parallélisme) pour les bases de données. Dans [Gan06], l’auteur pré-sente la gestion de la réplication suivant plusieurs dimensions. Pour des soucis de présentation, nous regroupons les dimensions décrites dans [Gan06] en quatre concepts à savoir la distribution ou placement des données, la configuration (rôle) des répliques, la stratégie de la propagation des mises à jour et enfin la stratégie de maintien de la cohérence.
– Placement des données. Les données peuvent être répliquées partiellement ou totalement. La réplication totale stocke entièrement la base de données sur chaque site. La réplication partielle nécessite une partition des données en fragments. Chaque fragment est stocké par la suite sur plusieurs noeuds. L’avantage de la réplication partielle est qu’elle permet de réduire de manière significative les accès concurrents aux données. En outre, le coût de la mise à jour des copies est moins important que dans le cas de la réplication totale compte tenu de la
faible portion des données sollicitée par les opérations de mises à jour.
– Configuration des répliques. Les mises à jour peuvent être effectuées sur une seule réplique (appelée maître) avant d’être propagées vers les autres (esclaves). Une telle configuration est appelée mono-maître (primary copy) car les autres répliques ne sont utilisées que pour les requêtes de lecture seule, ce qui améliore les performances des opérations de lecture seule. L’avantage d’une telle approche est qu’elle facilite la gestion de la cohérence globale du système (cohérence mutuelle) puisque toutes les mises à jour sont effectuées sur une seule copie. Cependant, cet avantage est contradictoire avec le passage à l’échelle et avec la disponibilité qui nécessitent que plusieurs copies soient utilisées en même temps pour faire face à une charge applicative d’écritures très importante et variable. Une approche multi-maître (update anywhere), dans laquelle 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. La configuration mono-maître profite plus aux applications de type OLAP avec lesquelles les données de production (sujettes à des modifications) doivent être séparées des données d’analyse (milliers d’opérations de lecture seule). Par contre les applications OLTP tirent plus de bénéfices de l’approche multi-maître et particulièrement quand le nombre de mises à jour est très important et provient de diverses sources (utilisateurs). Il existe beaucoup de produits commerciaux qui offrent des solutions de réplication mono-maître ou multi-maître. Pour les architectures mono-maître, nous pouvons citer de manière non-exhaustive Micro-soft SQL Server replication, Oracle Streams, Sybase replication Server, MySQL replication, IBM DB2 DataPropagator, GoldenGate TDM platform, et Veritas Volume Replicator. Alors que les exemples de solutions multi-maître incluent Continuent uni/Cluster, Xkoto Gridscale, MySql Cluster, DB2 Integrated Cluster.
– Stratégies de rafraîchissement (propagation). Elles définissent comment la propagation va être effectuée en précisant le contenu à propager, le modèle de communication utilisé, l’ini-tiateur et le moment du déclenchement. Le rafraîchissement est fait grâce à une transaction appelée transaction de rafraîchissement dont le contenu peut être les données modifiées (wri-tesets en anglais) ou le code de la transaction initiale [EGA08, Gan06]. La caractéristique principale d’une transaction de rafraîchissement est qu’elle est déjà exécutée sur au moins une réplique. La propagation de la transaction par la ré-exécution de celle-ci sur toutes les répliques, ne garantit pas toujours le même résultat sur chaque site si des instructions SQL contextuelles comme RANDOM ou LIMIT ou plus simplement SYSDATE sont utilisées dans la requête [EGA08]. La propagation des données modifiées requiert la récupération de celles-ci, ce qui est souvent très coûteux (triggers, log sniffing, comparaison de snapshot, etc.) et donc peut impacter les performances du système. Néanmoins, la propagation des données modifiées évite de rejouer une transaction qui a nécessité beaucoup de calcul avant de produire un résultat et ne dépend pas du contexte. La propagation peut être initiée par le noeud qui a exécuté une première fois les mises à jour, on parle de PUSH (pousser). Elle
peut être aussi initiée par les noeuds recevant les mises à jour, c’est l’approche PULL (tirer). Quant à la communication, elle peut se faire de point à point, ou par communication de groupe (multicast, broadcast), de manière épidémique, etc. Cependant, le modèle de com-munication est fortement tributaire du type de système. Par exemple l’utilisation du multicast dans un réseau P2P réduit le nombre de messages mais n’est pas toujours faisable à cause du caractère dynamique du système.
Enfin, le déclenchement peut se faire dès la réception ou l’exécution d’une nouvelle transac-tion (immédiat), périodiquement, quand une réplique est obsolète, quand un noeud est peu chargé, à la demande, etc. Comme nous allons le montrer dans le prochain chapitre, le mo-ment du déclenchemo-ment joue un rôle capital dans les performances du système (cohérence mutuelle, surcharge du réseau, ...). Le déclenchement à la demande ou quand un noeud est moins chargé permet de réduire la surcharge du réseau en regroupant plusieurs mises à jour mais a l’inconvénient de laisser diverger les copies.
– Maintien de la cohérence. La cohérence peut être gérée de manière stricte (réplication synchrone) ou relâchée (réplication asynchrone) [GHOS96]. Avec la réplication synchrone, toutes les répliques sont mises à jour à l’intérieur de la transaction. Cette approche a l’avan-tage de garder toutes les copies cohérentes à chaque instant, mais nécessite que toutes les répliques soient disponibles et synchronisées au moment de l’exécution de la transaction (ROWA pour Read-One/ Write-All). Une amélioration de cette approche est de synchroniser uniquement les répliques disponibles au moment de l’exécution d’une transaction (ROWAA pour Read-One/ Write-All-Available). Pour des systèmes à large échelle, de telles approches entraîneraient des retards dans la validation des transactions puisque la communication n’est pas toujours stable. Par conséquent et comme il a été démontré dans [GHOS96], cette solu-tion ne passe pas généralement à l’échelle.
La réplication asynchrone est plus souple car une transaction est d’abord validée sur une seule réplique avant d’être propagée sur les autres répliques dans une autre transaction. L’in-convénient de cette approche est que les copies peuvent diverger. Cette divergence a pour impact de retourner aux utilisateurs des résultats faux (par exemple l’achat d’une place de cinéma qui n’existe pas) ou de faire varier les invariants (les règles de gestion) du système (par exemple créditer un compte qui n’est pas encore créé).
Cependant, il est possible de laisser volontairement les copies diverger dans l’optique d’amé-liorer les performances du système. En effet, il est possible d’effectuer des transactions de lectures sur des copies pas nécessairement fraîches pour accélérer l’exécution des transac-tions de lecture [GNPV07, LG06, LGV04, RBSS02]. Néanmoins, l’obsolescence des copies doit être contrôlée en fonction des exigences des applications [GNPV07]. L’obsolescence peut être définie de différentes manières [LGV04]. Dans cette thèse, nous considérons une seule mesure à savoir le nombre de transactions de mise à jour manquantes. Précisément, l’obsolescence d’une réplique Ri sur un site sj est égale au nombre de transactions de mise à jour modifiant Ri sur un site quelconque mais non encore propagée sur sj. L’obsolescence tolérée d’une transaction de lecture est donc, pour chaque objet de la base lue par la tran-saction, le nombre de transactions qui ne sont pas encore exécutées sur le site traitant la
transaction. L’obsolescence tolérée reflète le niveau de fraîcheur requis par une transaction de lecture pour s’exécuter sur un site. Par exemple, si une transaction de lecture requiert des données parfaitement fraîches, alors l’obsolescence tolérée est zéro. Pour des raisons de co-hérence, les transactions de mise à jour ainsi que celles de rafraîchissement doivent lire des données parfaitement fraîches.
Par ailleurs, on peut classer la réplication asynchrone en deux familles : réplication optimiste et réplication pessimiste. Avec la réplication pessimiste, les transactions sont ordonnées a prioriavant d’être envoyées sur les répliques en respectant leurs contraintes conflictuelles. L’ordonnancement a priori ne permet pas un contrôle d’accès concurrent très fin, car deux transactions peuvent apparaître conflictuelles sans pour autant l’être réellement. La réplica-tion asynchrone optimiste autorise l’exécuréplica-tion de plusieurs transacréplica-tions simultanément sur plusieurs sites. Au moment de la validation globale (maintien de la cohérence mutuelle), on vérifie les conflits et les résoud. La résolution peut se faire par abandon de certaines transac-tions ou par ré-exécution des transactransac-tions. Si les données sont bien partitionnées, les conflits sont moins fréquents et donc l’utilisation de la réplication optimiste devient bénéfique car le débit transactionnel est fortement augmenté.