Bases de données distribuées - Partie 1 PDF

Valentin MORIN – Tech Lead Java - Lyreco Bases de données distribuées  Qui je suis Mon parcours scolaire Qui je suis ? Mon xp pro Pourquoi je suis là ? 2  Présentation de vous Qui vous êtes (nom, prénom, âge,...

Valentin MORIN – Tech Lead Java - Lyreco Bases de données distribuées  Qui je suis Mon parcours scolaire Qui je suis ? Mon xp pro Pourquoi je suis là ? 2  Présentation de vous Qui vous êtes (nom, prénom, âge, passions) ? D’où vous venez ? Pourquoi vous êtes là (objectif pro / de vie) ? C’est quoi votre film préféré ? 3 Introduction  Introduction Une entreprise, selon son besoin, peut choisir entre l’utilisation de bases de données centralisées ou distribuées : 5  Introduction Historiquement, un système de BDD est centralisé : 1 serveur Un SGBD Une base de donnée Client = interface graphique ou application Serveur = Gestion des requêtes Gestion des transactions Gestion des pannes… 6  Introduction Problème : si le serveur est down, plus rien ne fonctionne. On parle de Single Point of Failure. Evidemment, c’est un gros risque pour une entreprise et le bon fonctionnement de son système. 7  Introduction Même si pas de plantage, on rencontre : L’augmentation du volume de données L’augmentation du volume de traitements L’augmentation du volume de transactions Solution : multiplier les sources de données, et les faire communiquer par réseau ! Et spoiler on appelle ça… une base de données distribuées ☺ 8  Introduction Base de données distribuée - définition Une base de données distribuée est un ensemble de données stockées sur plusieurs machines, souvent géographiquement dispersées, mais accessibles comme si elles étaient hébergées sur un seul système. Cela peut inclure des systèmes qui répartissent les données ou qui répliquent les mêmes données sur plusieurs nœuds. Exemple : MongoDB permet de stocker les données dans des clusters répartis sur plusieurs serveurs ou datacenters, tout en apparaissant comme une seule base de données pour l’utilisateur. 9  Introduction Système distribué vs système centralisé Dans un système centralisé, toutes les données résident sur une seule machine. La capacité de gestion des données est limitée par la puissance et l’espace de stockage de cette machine. Exemples de systèmes centralisés : MySQL, PostgreSQL. Dans un système distribué, les données peuvent être fragmentées ou répliquées entre plusieurs machines. Ces machines travaillent ensemble pour répondre aux requêtes, répartissant la charge et augmentant la fiabilité du système. 10  Introduction Quelques définitions : ✓ Une base de données distribuée est un ensemble de bases de données localisées et gérées par des site différents mais logiquement inter-reliées et apparaissant à l'utilisateur comme une base unique. ✓ Un client d’un système de gestion de base de données distribuée est une application qui accède aux informations distribuées par les interfaces du système. ✓ Un SGBD (système de gestion de bases de données distribuées) est l’application qui permet la gestion de la base de données distribuée et en rend la distribution transparente aux utilisateurs. 11  Introduction Quelques exemples de bases de données distribuées : ✓ MongoDB : NoSQL orienté documents, conçu pour le sharding et la réplication. ✓ Cassandra : NoSQL orienté colonnes, utilisé pour des systèmes massivement distribués. ✓ Google Spanner : Base SQL globale avec consistance forte, résistant aux partitions et distribuant les données à grande échelle. 12 1 - Avantages des Bases de Données Distribuées  Les grands avantages Continuité de service : en cas de panne d’un serveur, un autre peut prendre la relève. Haute performance : les requêtes sont distribuées sur les différents serveurs. La transparence des données : les développeurs et les utilisateurs n’ont pas a se préoccuper de la localisation des données qu’ils utilisent. 14  Les grands avantages La scalabilité horizontale Scalabilité horizontale (Scaling out) = augmenter la capacité d’un système en ajoutant machines ou serveurs au réseau. Dans le cadre BDDD : Système distribué = conçus pour ajouter des nœuds à un cluster. Pas besoin de toucher à la puissance d’un serveur. Exemple : En MongoDB, on petx ajouter des nœuds au cluster sans interruption, et les données seront automatiquement répliquées ou shardées pour équilibrer la charge. 15  Les grands avantages Disponibilité accrue Dans un système distribué, plusieurs copies des données sont stockées sur des nœuds différents. Si un nœud devient inaccessible, d’autres nœuds peuvent continuer à répondre aux requêtes. Cela rend le système plus résistant aux pannes matérielles ou réseaux. -> Suppression du SPOF ! Exemple : MongoDB utilise un ensemble de répliques (replica set), avec un nœud primaire qui gère les écritures et plusieurs secondaires pour la redondance. 16  Les grands avantages Disponibilité accrue Dans un système distribué, plusieurs copies des données sont stockées sur des nœuds différents. Si un nœud devient inaccessible, d’autres nœuds peuvent continuer à répondre aux requêtes. Cela rend le système plus résistant aux pannes matérielles ou réseaux. -> Suppression du SPOF ! Exemple : MongoDB utilise un ensemble de répliques (replica set), avec un nœud primaire qui gère les écritures et plusieurs secondaires pour la redondance (= duplication). 17  Les grands avantages Localisation des données Données plus près des utilisateurs = réduction de la latence. Par exemple, dans une application mondiale : - données pour les utilisateurs européens dans un datacenter en Europe - données pour les utilisateurs asiatiques dans un datacenter en Asie. Exemple : MongoDB Atlas (version cloud) te permet de configurer des clusters multi-régions pour garantir une faible latence dans les différentes zones géographiques. 18  Les grands avantages Résiliance aux défaillances Les bases de données distribuées peuvent tolérer des pannes matérielles ou des partitions réseau tout en maintenant une certaine disponibilité. Résilience essentielle dans les environnements de production à grande échelle (site ecom, jeux vidéos, …). Système équivalent et utilisé pour la gestion des serveurs cloud. Exemple : un serveur plante -> le load balancer vous envoie sur un autre serveur qui lui est fonctionnel. 19 1 - Transparence des Bases de Données Distribuées  Transparence des Bases de Données Distribuées Afin que l’exploitation des données soit facile pour les utilisateurs c’est le système qui s’occupe de la récupération des informations. On parle alors de TRANSPARENCE ! Transparence de données (indépendance) Transparence du réseau Transparence de réplication (redondance) Transparence de fragmentation 21  Transparence des Bases de Données Distribuées Transparence des données (indépendance) La définition des données dans une base de données se fait à deux niveaux (structure logique et structure physique), ce qui permet de définir une : Indépendance de données logiques les applications de l’utilisateur ne sont pas autorisées à modifier la structure logique des données (le schéma) Indépendance de données physiques les détails de la structure de stockage des données seront cachés aux applications de l’utilisateur 22  Transparence des Bases de Données Distribuées Transparence de réplication (redondance) /!\ La réplication n’est pas valable que pour les bases distribuées. Il est préférable de faire des copies sur plusieurs sites pour des raisons de performance, de disponibilité des données et de sécurité (copier sur le même serveur ça sert à rien) La force de la BDD distribuée c’est de toujours avoir certaines data disponibles, de part le split. 23  Transparence des Bases de Données Distribuées Transparence de fragmentation Fragmenter une table de la base de données et placer chaque fragment sur un site différent (raisons de performance). La fragmentation permet aussi de réduire les inconvénients de la réplication quantité de data dupliquée La fragmentation doit être faite d’une manière transparente à l’utilisateur. Il utilise la table originale comme si elle n’est pas fragmentée. 24 2 – Zoom sur la fragmentation  Zoom sur la fragmentation Fragmentation = processus de décomposition d’une base de données logique en un ensemble de "sous" bases de données. Cette décomposition doit se faire sans perte d'information. Le processus de fragmentation peut se faire sous différentes stratégies: Horizontale Verticale Hybride (horizontale ET verticale) 26  Zoom sur la fragmentation Deux types de fragmentation : Verticale Partitionnement en plusieurs sous-tables qui sont définies sur un sous-ensemble d’attributs (de colonnes) de la table originale Horizontale Partitionnement en plusieurs sous tables contenant chacune un sous ensemble de lignes de la table originale 27  Zoom sur la fragmentation Distribution relationnelle : Le cas le plus simple est de distribuer des « fragments » d’une même relation sur plusieurs sites, et pas de distribuer les relations. Exemple : on a la table user contenant les users dont l’id est pair sur une base avec leurs adresses liée dans une table adresse, et les users dont l’id est impair sur une autre base avec leurs adresses liée dans une table adresse. On va alors avoir besoin d’agir par deux moyens : Fragmentation Allocation 28 3 – Problèmes et Challenges des Bases Distribuées  Consistance vs Disponibilié Théorème de CAP Le théorème CAP stipule qu'un système distribué ne peut garantir simultanément ces trois propriétés : Consistance (Consistency) toutes les répliques ont les mêmes données Disponibilité (Availability) le système répond à toutes les requêtes même en cas de pannes Tolérance aux partitions (Partition Tolerance) le système fonctionne malgré des interruptions de communication entre les nœuds. 30  Consistance vs Disponibilié Théorème de CAP Base de données distribuée pour une application dans le cloud : une partition réseau survient = une partie des serveurs pourrait ne plus être capable de synchroniser ses données avec le reste des serveurs. Selon la manière dont le système est conçu, il pourrait : 1. Prioriser la consistance : Bloquer les opérations d'écriture pour éviter des incohérences. 2. Prioriser la disponibilité : Permettre des écritures et des lectures même si les nœuds ne peuvent pas immédiatement se synchroniser, au risque d'incohérences temporaires. Partition réseau = scénario d'échec typique dans les systèmes distribués. Il faut pouvoir gérer en fonction des exigences de l'application (consistance stricte ou disponibilité continue). 31  Consistance vs Disponibilié Théorème de CAP 32  Problèmes et Challenges des Bases Distribuées Réplication Dans une base de données distribuée, la réplication assure la redondance et la disponibilité des données. Il existe deux types principaux : Réplication maître-esclave (primary-secondary) : un nœud primaire gère toutes les écritures, tandis que les nœuds secondaires répliquent ces écritures pour être disponibles en lecture ou en secours (ex : replicaset MongoDB) Réplication peer-to-peer : Chaque nœud peut gérer des écritures, ce qui nécessite des mécanismes complexes de résolution de conflits (ex : Torrent est système peer to peer). 33  Problèmes et Challenges des Bases Distribuées Partionnement Partitionnement (ou sharding) = diviser les données en fragments (shards) qui sont stockés sur différents nœuds. Chaque shard contient un sous-ensemble de données. Cette technique permet de répartir la charge sur plusieurs machines. Exemple : MongoDB shard les collections de données sur plusieurs serveurs en utilisant une clé de partitionnement, par exemple un identifiant utilisateur, ce qui permet d’échelonner horizontalement. 34 4 – MongoDB : Exemple de Base de Données Distribuée  Introduction rapide à MongoDB MongoDB est une base NoSQL orientée documents, où les données sont stockées sous forme de documents JSON/BSON. MongoDB est conçu pour être distribué nativement avec des fonctionnalités de réplication et de sharding intégrées. 36  Introduction rapide à MongoDB Caractéristiques clés des bases de données NoSQL « Une base de données NoSQL (Not Only SQL) est un type de base de données qui offre une alternative aux bases de données relationnelles traditionnelles, en étant plus flexible et adaptée à des cas d'usage spécifiques, notamment ceux impliquant de grandes quantités de données non structurées, distribuées ou dynamiques. » Modèles de données flexibles : Documents : Des objets structurés (ex : JSON) comme dans MongoDB. Colonnes : Des structures basées sur des colonnes comme dans Cassandra. Clés-Valeurs : Des paires simples de clés et de valeurs, comme Redis. Graphes : Des réseaux de relations entre données, comme Neo4j. 37  Introduction rapide à MongoDB Caractéristiques clés des bases de données NoSQL Scalabilité horizontale : Les bases NoSQL sont conçues pour s'étendre horizontalement en ajoutant des serveurs supplémentaires, plutôt que d'augmenter la puissance d'un seul serveur. Cela permet de gérer de grands volumes de données et un nombre élevé de requêtes. Absence de schéma rigide : Les données dans une base NoSQL ne nécessitent pas de schéma prédéfini, ce qui les rend idéales pour des données non structurées ou semi- structurées. Chaque entrée (ou document) peut avoir des champs différents, facilitant l'ajout de nouveaux types de données sans migration de schéma. 38  Introduction rapide à MongoDB Utilisation des bases de données NoSQL Gérer de grandes quantités de données distribuées. Pour des applications nécessitant une haute disponibilité, même en cas de pannes de certains serveurs. Pour des données non structurées ou semi-structurées (comme des logs, des données de réseaux sociaux, ou des objets JSON). Pour des applications nécessitant une scalabilité horizontale, comme des systèmes de recommandation, des réseaux sociaux, des analyses en temps réel, ou des applications web à grande échelle. 39  Introduction rapide à MongoDB Bases NoSQL populaires MongoDB : Base de données orientée documents.Pour des applications nécessitant une haute disponibilité, même en cas de pannes de certains serveurs. Cassandra : Base orientée colonnes, idéale pour des applications à grande échelle. Redis : Base clé-valeur en mémoire, rapide et efficace pour la mise en cache. Neo4j : Base de données graphe, optimisée pour des données fortement connectées. 40  Introduction rapide à MongoDB Réplication dans MongoDB MongoDB utilise des replica sets pour assurer la redondance et la tolérance aux pannes. Un replica set consiste en : Un nœud primaire (écriture) Plusieurs nœuds secondaires (réplication en lecture et backup) Si le nœud primaire échoue, un des nœuds secondaires peut être automatiquement promu pour assurer la continuité du service. 41  Introduction rapide à MongoDB Sharding dans MongoDB MongoDB permet de distribuer les données sur plusieurs nœuds via le sharding. Chaque shard contient une partie des données, et une clé de partitionnement est utilisée pour déterminer quelle donnée va dans quel shard. Exemple : Si on veut stocker des utilisateurs par pays, on peut choisir le pays comme clé de partitionnement pour que chaque shard contienne les utilisateurs d’une région différente. 42 5 – Conclusion Comparaison avec un Système Centralisé  Comparaison avec un Système Centralisé Performances Dans un système centralisé, l’augmentation du volume de données ou des requêtes peut provoquer des goulots d’étranglement. Les systèmes distribués, en revanche, répartissent cette charge sur plusieurs nœuds. 44  Comparaison avec un Système Centralisé Disponibilité Les systèmes centralisés sont vulnérables aux pannes, alors qu’un système distribué (comme MongoDB avec replica sets) peut tolérer la défaillance d’un ou plusieurs nœuds sans compromettre l’accès aux données. 45  Conclusion Les bases de données distribuées offrent des avantages significatifs en termes de scalabilité, disponibilité et résilience, bien qu’elles posent des défis en matière de consistance et de gestion des pannes. Applications modernes : De nombreuses applications modernes, telles que les réseaux sociaux, les plateformes de streaming ou les systèmes IoT, nécessitent une base de données distribuée pour gérer efficacement des volumes de données massifs et des utilisateurs répartis à l’échelle mondiale. 46 Valentin MORIN – Tech Lead Java - Lyreco Bases de données distribuées – Partie 2 La fragmentation en détails 1- Rappel des types de fragmentation Fragmentation horizontale : Division des données en lignes (ou tuples) basées sur des valeurs de certains attributs. Fragmentation verticale : Division en colonnes, regroupant des attributs fréquemment utilisés ensemble. Fragmentation hybride : Combinaison des deux approches, permettant une distribution optimale pour des cas d'usage spécifiques. Fragmentation Horizontale – rappel en image Ce type de fragmentation permet de découper une relation en sous-relations contenants des sous-ensembles des tuples de la relation mère. Fragmentation Verticale – rappel en image La fragmentation verticale permet de découper une relation R en plusieurs relations. Chaque fragment contient un sous- ensemble d’attributs ainsi que la clé primaire de R. Pourquoi fragmenter ? Optimisation de la performance : Chaque fragment est stocké là où il est le plus pertinent, réduisant les temps de latence. Réduction du volume des données transférées : Les requêtes sont envoyées aux fragments pertinents, réduisant les échanges réseau. Augmentation de la disponibilité : En cas de panne, seuls certains fragments pourraient être indisponibles, mais pas l’ensemble des données. 2- Comment fragmenter ? La fragmentation horizontale est souvent réalisée en utilisant des prédicats qui définissent des règles pour chaque fragment. Un prédicat est une condition logique appliquée aux données (par exemple, age < 30). Les Prédicats Prédicats simples : Ils filtrent les données en fonction d’une seule condition sur un attribut. Par exemple, dans une table de clients, un prédicat simple pourrait être country = 'France'. Minterm prédicats : Ils sont constitués d’une combinaison de plusieurs prédicats simples. Par exemple, age < 30 AND country = 'France'. Les minterms permettent de créer des fragments précis qui combinent plusieurs conditions pour une sélection affinée. Exemple de fragmentation horizontale Imaginons une table de clients avec les colonnes : ID, Name, Age, et Country. Voici comment on pourrait la fragmenter : Fragment 1 : Tous les clients âgés de moins de 30 ans (Age < 30) Fragment 2 : Tous les clients en France (Country = 'France’) Fragment 3 (Minterm) : Tous les clients en France et âgés de moins de 30 ans (Age < 30 AND Country = 'France’) Ces fragments peuvent ensuite être distribués sur différents nœuds selon leur fréquence d’accès, leur localisation géographique, ou d'autres critères. 3- Complétude et Minimalité Complétude : Un ensemble de prédicats est complet s'il couvre toutes les données de la table, de sorte que chaque tuple (ligne) corresponde à au moins un fragment. Cela garantit qu'aucune donnée n'est laissée en dehors du système distribué. Minimalité : Un ensemble de prédicats est minimal si aucun prédicat n'est redondant. Cela signifie que chaque fragment est unique et n'intercepte pas un autre fragment, réduisant la duplication inutile et optimisant la répartition des données. Générer des prédicats Complets et Minimaux Étape 1 : Identifier les Attributs de Fragmentation Clés Choisissez les attributs les plus discriminants dans le contexte de l’utilisation des données (par exemple, Pays, Département, ou Âge). Assurez-vous que ces attributs sont assez granulaires pour créer des fragments utiles sans être trop spécifiques (par exemple, Département peut être utile pour une entreprise globale, mais Numéro de Bureau pourrait être trop précis). Générer des prédicats Complets et Minimaux Étape 2 : Créer des Prédicats Simples Exemple : Si l'attribut de fragmentation est Pays, un ensemble de prédicats simples pourrait être : Définissez des conditions simples sur chaque Pays = 'France' attribut clé, comme Pays = 'France' ou Âge < Pays = 'États-Unis' Pays = 'Allemagne' 30. Pour chaque attribut, générez plusieurs valeurs significatives pour l’analyse (par exemple, plusieurs tranches d’âge ou régions Ces prédicats simples permettent d’obtenir des géographiques). fragments de base, mais l'ensemble n'est pas encore complet.  Étape 3 : Assurer la Complétude Vérifiez que chaque prédicat couvre une partie unique de l’ensemble des données et que la Générer des combinaison des prédicats inclut toutes les valeurs possibles. prédicats Par exemple, pour une fragmentation par âge, vous pouvez définir : Complets et o Âge < 18 18 = 30 L’ensemble couvre toutes les possibilités de valeurs pour l’attribut Âge, garantissant ainsi la complétude des fragments. Générer des prédicats Complets et Minimaux Étape 4 : Éliminer les Prédicats Redondants pour Assurer la Minimalité Supprimez les prédicats redondants ou ceux qui se chevauchent inutilement. Exemple : Si vous avez les prédicats Pays = 'France' OR Pays = 'France' AND Département = 'Informatique', le premier prédicat est redondant dans le contexte d’une fragmentation orientée département. Outil de simplification : Utilisez les minterms pour structurer des combinaisons précises et éviter les chevauchements. Exemple de minterms pour un ensemble complet : ▪ Pays = 'France' AND Âge < 30 ▪ Pays = 'France' AND Âge >= 30 ▪ Pays = 'États-Unis' AND Âge < 30 ▪ Pays = 'États-Unis' AND Âge >= 30 Chaque combinaison est unique et couvre toutes les possibilités, donc l’ensemble est minimal. Générer des prédicats Complets et Minimaux Étape 1 : Identifier les Attributs de Fragmentation Clés Étape 2 : Créer des Prédicats Simples Étape 3 : Assurer la Complétude Étape 4 : Éliminer les Prédicats Redondants pour Assurer la Minimalité 4- Exemple pratique : Génération d’un Ensemble Minimal et Complet de Prédicats Supposons une table Employés avec les attributs Pays et Département. Nous voulons une fragmentation qui soit complète et minimale. Attributs de Fragmentation Pays : France, États-Unis Département : Informatique, Ventes Prédicats simples : Pour Pays: Pays = 'France’ && Pays = 'États-Unis' Pour Département: Département = 'Informatique’ && Département = 'Ventes' Combinaisons en minterm Pays = 'France' AND Département = 'Informatique' Pays = 'France' AND Département = 'Ventes' Pays = 'États-Unis' AND Département = 'Informatique' Pays = 'États-Unis' AND Département = 'Ventes' Vérification de : L’ensemble couvre toutes les combinaisons possibles La complétude : pour Pays et Département, garantissant ainsi qu’aucun employé n’est exclu. Aucun prédicat ne peut être supprimé sans réduire la La minimalité : couverture de la fragmentation. Chacun est unique et non redondant. 5- Recommandation d’optimisation de fragmentation Choix des attributs de fragmentation : Limitez le nombre d’attributs pour simplifier la création de fragments, sauf si les besoins analytiques nécessitent une segmentation plus complexe. Utilisation des minterms : Créez des fragments bien définis en combinant des prédicats simples. Cela permet de garder les fragments précis et pertinents. Tests de complétude et de minimalité : Toujours vérifier que tous les cas possibles sont couverts (complétude) et que chaque fragment est unique et non redondant (minimalité). Quelques exemples de chaque fragmentation Horizontale / Verticale / Hybride Horizontale Imaginons une table Clients avec les colonnes suivantes : ID, Nom, Âge, Pays, Ville. Prédicats Simples Pour la fragmentation horizontale, on pourrait utiliser des prédicats simples comme suit : Fragment 1 : Clients en France (Pays = 'France') Fragment 2 : Clients aux États-Unis (Pays = 'USA’) Minterms Si on combine des prédicats simples, on obtient des minterms : Fragment 3 (Minterm) : Clients en France ET dans la tranche d’âge 18-25 (Pays = 'France' ET Âge < 25) Chaque fragment pourrait être assigné à un nœud spécifique du réseau distribué pour optimiser l'accès local aux données. Horizontale Imaginons une table Clients avec les colonnes suivantes : ID, Nom, Âge, Pays, Ville. Prédicats Simples Pour la fragmentation horizontale, on pourrait utiliser des prédicats simples comme suit : Fragment 1 : Clients en France (Pays = 'France’) ET PAS dans la tranche d’âge 18-25 (Pays = ‘France’ ET Age > 25) Fragment 2 : Clients aux États-Unis (Pays = 'USA’) Minterms Si on combine des prédicats simples, on obtient des minterms : Fragment 3 (Minterm) : Clients en France ET dans la tranche d’âge 18-25 (Pays = 'France' ET Âge < 25) Chaque fragment pourrait être assigné à un nœud spécifique du réseau distribué pour optimiser l'accès local aux données. Verticale Supposons que notre table Clients possède les colonnes ID, Nom, Adresse, Téléphone, HistoriqueAchats, PointsFidélité. Fragmentation Verticale : On pourrait diviser cette table selon les besoins en accès aux données : Fragment 1 : ID, Nom, Adresse (pour des informations de base). Fragment 2 : ID, Téléphone, PointsFidélité (pour les opérations de fidélité). Fragment 3 : ID, HistoriqueAchats (pour les analyses marketing). Cette fragmentation permettrait de limiter l'accès uniquement aux données nécessaires, économisant ainsi de la bande passante et améliorant la performance. Hybride Prenons une application e-commerce mondiale qui a besoin de stocker des informations clients en fonction de leur localisation et de leur historique d'achats. Application de la Fragmentation Hybride Fragmentation Horizontale par Pays : Les clients sont d'abord segmentés par pays pour minimiser la latence de localisation. Fragmentation Verticale pour les Attributs : Ensuite, pour chaque fragment de pays, les données sont fragmentées verticalement : o Fragment de Base : Informations personnelles de base (nom, adresse, téléphone). o Fragment d'Achats : Historique d'achats et points de fidélité. Hybride Prenons une application e-commerce mondiale qui a besoin de stocker des informations clients en fonction de leur localisation et de leur historique d'achats. Application de la Fragmentation Hybride Fragmentation Horizontale par Pays : Les clients sont d'abord segmentés par pays pour minimiser la latence de localisation. Fragmentation Verticale pour les Attributs : Ensuite, pour chaque fragment de pays, les données sont fragmentées verticalement : o Fragment de Base : Informations personnelles de base (nom, adresse, téléphone). o Fragment d'Achats : Historique d'achats et points de fidélité. L’allocation des ressources 1- Introduction aux coûts Dans un système distribué, l’allocation des ressources pour un fragment implique plusieurs types de coûts : Stockage : coût de l’espace disque occupé. Traitement des requêtes : coût de l’utilisation CPU pour les traitements locaux. Transfert de données : coût du réseau pour envoyer des fragments entre les nœuds. Réplication : coût de réplication pour assurer la résilience et la disponibilité. L’objectif est de minimiser ces coûts tout en garantissant un accès rapide et une haute disponibilité des fragments. 2- Calcul du coût de stockage Le coût de stockage d’un fragment dépend de sa taille, de la quantité de données qu’il contient, et du coût de stockage par unité dans le système distribué. Exemple : Si un fragment F1 a une taille de 10 Go et le coût de stockage est de 0,10 € par Go, alors :  Le coût de stockage d’un fragment dépend de sa taille, de la quantité de données qu’il contient, et du coût de stockage par unité dans le système distribué. 2- Calcul du Optimisation : coût de Pour minimiser le coût de stockage, il est stockage recommandé de limiter la taille des fragments en évitant les duplications inutiles et en choisissant des fragments ayant une taille adaptée aux traitements requis. 3- Calcul du coût des requêtes Le coût de traitement est souvent mesuré en fonction du nombre de requêtes, de la complexité des requêtes, et du coût de traitement par unité CPU. Formule : Exemple : Supposons que F1 reçoit 1 000 requêtes par jour, que la complexité moyenne de chaque requête (en termes de cycles CPU) est évaluée à 2 unités, et que le coût de traitement est de 0,001 € par unité CPU : 3- Calcul du coût des requêtes Le coût de traitement est souvent mesuré en fonction du nombre de requêtes, de la complexité des requêtes, et du coût de traitement par unité CPU. Optimisation : Pour optimiser ce coût, il est judicieux de placer les fragments proches des nœuds ayant le plus besoin d’y accéder, réduisant ainsi le nombre de requêtes inter-nœuds coûteuses. 4- Calcul du coût de transfert des données Le transfert des données entre les nœuds (par exemple, pour la synchronisation ou la mise à jour) est un coût important, surtout lorsque les fragments sont volumineux ou que les nœuds sont répartis géographiquement. Formule : Exemple : Si F1 doit être synchronisé quotidiennement avec un autre nœud, et qu’il envoie 5 Go par jour avec un coût de 0,02 € par Go transféré : 4- Calcul du coût de transfert des données Le transfert des données entre les nœuds (par exemple, pour la synchronisation ou la mise à jour) est un coût important, surtout lorsque les fragments sont volumineux ou que les nœuds sont répartis géographiquement. Optimisation : Pour réduire ce coût, il peut être utile de minimiser les transferts de données en choisissant des fenêtres de synchronisation plus longues ou en limitant les transferts aux seules données modifiées. 5- Calcul du coût de réplication La réplication vise à garantir la disponibilité des fragments même en cas de panne. Le coût de réplication dépend de la fréquence des copies et du coût de stockage et de transfert par réplique. Formule : Exemple : Si F1 est répliqué sur trois nœuds (deux copies supplémentaires), avec un coût de stockage de 1 € et un coût de transfert de 0,10 € par jour pour chaque copie : 5- Calcul du coût de réplication La réplication vise à garantir la disponibilité des fragments même en cas de panne. Le coût de réplication dépend de la fréquence des copies et du coût de stockage et de transfert par réplique. Optimisation : La réplication peut être optimisée en réduisant le nombre de répliques dans les régions où la redondance est moins critique et en utilisant des algorithmes de réplication adaptative qui réduisent le transfert inutile. 6- Calcul du coût total d’un fragment En combinant tous ces coûts, le coût total d’allocation d’un fragment F est : Exemple final - pour F1, avec : Le coût total par jour est :  7- Minimisation des coûts Pour optimiser le coût d’allocation de chaque fragment, il est recommandé de : Rationaliser la réplication : Limiter la redondance excessive tout en maintenant la résilience. Minimiser les transferts de données : Placer les fragments stratégiquement pour éviter les transferts inutiles. Réduire les coûts de traitement : Assigner les fragments proches des utilisateurs ou applications les plus fréquentes. Ces calculs et stratégies permettent d’optimiser l’allocation des ressources dans les systèmes distribués tout en maximisant les performances et la disponibilité des fragments.  Valentin MORIN [email protected] Merci