Structures de données avancées : Fichiers distribués Pr ZEGOUR DJAMEL EDDINE Ecole Supérieure d’Informatique (ESI) zegour.esi.dz email: d_zegour@esi.dz

Structures de données distribuées et scalables

Architecture à mémoire partagée : Shared-Memory Systèmes distribués Architecture à mémoire partagée : Shared-Memory N processeurs et une RAM commune N < 10 RAM : Goulot d’étranglement Un ensemble de machines se partageant les données à stocker et la charge CPU. Architecture à disques partagés : Shared-Disk N Disques communs Chaque processeur peut avoir un disque cache Gestion de la cohérence Les tâches de communication inter-machines : transparentes à l’utilisateur L’ensemble du système = Une seule machine virtuelle. Architecture sans partage : Shared-Nothing Chaque machine= serveur de données Extensibilité et disponibilité Plus de programmation

Mécanisme de calcul d'adresse unique et centralisé Structures de données distribuées classiques Mécanisme de calcul d'adresse unique et centralisé  un point d'accumulation Stockage sur un seul site  Limite de taille Serveurs Clients Répertoire d'accès Limite sur les performances d'accès Pas de Scalabilité Vulnérabilité aux pannes

Partitionnement par intervalle Schémas de distribution classiques Partitionnement par intervalle Partitionnement par hachage Round-Robin Etc.

Assure une haute disponibilité SDDS:Scalable distributed data structures Conçues spécifiquement pour les multi ordinateurs d’une grande taille (Données multimédia, géographiques, texte,… ) Une nouvelle classe de structures de données pour des bases de données modernes Assure la Scalabilité (Grandissant rapidement en gardant les mêmes performances ) Assure une haute disponibilité

Une collection faiblement couplés d'ordinateurs : SDDS: Multi ordinateurs Une collection faiblement couplés d'ordinateurs : Station de travail, PC, CPU Interconnectés par un réseau haut-débit (≥ 100 Mb/s)  : LAN (Local Area Network), WAN(Wide Area Network), … Architecture à partage de rien avec passage de messages : Unicast, Multicast et Broadcast

Bon marchés ( les ordinateurs existent déjà ) SDDS: Multi ordinateurs Bon marchés  ( les ordinateurs existent déjà ) Puissance théorique de ressources en calcul et mémoires Impossible pour un super-ordinateur traditionnel  : HP laboratories (1500 WS) = 50 GO de RAM et quelques TO ( Téra octets) de disque. (1 TO = 1020 octets ) UCBerkeleySodaHall (500 WS) = 64 GO de RAM et plus d’un TO de disque Possibilités de bases de données en RAM distribuée 

SDDS: Multi ordinateurs RAM local RAM distant RAM distant Disque local réseau gigabit Ethernet Temps d'accès 100 nsecs 1 µsecs 100 µsecs 10 msec En proportion 1 mn 10 mn 2 heures 8 jours

Il n'y a pas de répertoire central d'accès Image locale par client SDDS: Axiomes généraux Les données sont stockées sur des serveurs et accédées par des clients autonomes Il n'y a pas de répertoire central d'accès Image locale par client Mécanisme de vérification et de redirection des requêtes Mécanisme de mise à jour distribué des images des clients (IAM : Image Adjustment Message) Mises à jour asynchrones

Contraintes de performance d'accès d'une SDDS SDDS: Contraintes Contraintes de performance d'accès d'une SDDS Nombre de messages sur le réseau par opération(indépendante des paramètres du réseau) Convergence de vue d’un nouveau client et d'un client peu actif Contraintes de scalabilité Prendre en charge n’importe quelle quantité de données Maintenir les performances quand le volume de données stockées varie Contraintes de distribution Une grande quantité de données Traitement parallèle et distribué Contraintes de disponibilité Assurer la continuité du fonctionnement 24 heures / 7 jours

Arbres (ordonnées) : RP*, CTH*, DRT SDDS: Typologie Hachage : LH*, DDH et EH* Arbres (ordonnées) : RP*, CTH*, DRT Multidimensionnelles : k-RP* , k-DRT et IH* Haute-disponibilité : LH*m, LH*s, LH*g, LH*RS , LH*SA

Concepts réseaux

Exemple typique de réseau local Concepts réseaux Exemple typique de réseau local 4 réseaux locaux reliés par 2 routeurs. A, B, C, et D sont les sites du réseau local N1. E et F sont les sites de N2. Un segment Ethernet (N1) permet de relier les sites du même réseau local. Chaque site du réseau local doit avoir une carte réseau avec son contrôleur

Types de messages Point-to-point : envoi d’un message à un autre site Concepts réseaux Types de messages Point-to-point : envoi d’un message à un autre site Multicast : envoi d’un message à un groupe de sites Broadcast : envoi d’un message à tous les sites du réseau

Routeurs Rôle d’un routeur : diffuser les messages non locaux. Concepts réseaux Routeurs Rôle d’un routeur : diffuser les messages non locaux. Pour envoyer un message de A vers H, utiliser le routeur 1. Pour envoyer un message de A vers M, utiliser le routeurs 1 et 2. Un message traversant n routeurs est équivalent à (n+1) messages Multiordinateurs : pas plus de 3 routeurs. Ce qui permet d’adresser des milliers de sites.

Concepts réseaux Propriétés Un message point-to-point traverse a segment de la même manière qu’un message Multicast. La seule différence : plusieurs serveurs sont à l’écoute. Un segment autorise la circulation d’un seul message à un moment donné.

Messages de données Messages de service Protocole de communication Messages de données Messages de service Messages de service: Gestion des tables des adresses physiques, Eclatement

Architecture Client/Serveur Protocole de communication Architecture Client/Serveur Protocole TCP/IP : TCP & UDP Programmation multithread Environnement : Microsoft Windows ou Linux Programmation réseaux : Sockets Programmation système: Synchronisation & Exclusion mutuelle Opérations : recherche, insertion, suppression, mises à jour, requête à intervalles

Serveurs de données (Concurrent) Protocole de communication Serveurs de données (Concurrent) Stockage de données Exécution des requêtes Exclusion mutuelle & Synchronisation Thread de travail : 1. Attendre l’événement signalant l’arrivée d’une requête 2. Prendre une requête de la file des messages entrant 3. Analyser la requête pour identifier le traitement demandé 4. Selon le cas, lancer le traitement local ou rediriger la requête 5. Retourner à l’étape 1

Site coordinateur (itératif) Protocole de communication Site coordinateur (itératif) Maintien des vrais paramètres du fichier Gestion des éclatements Clients (itératif) Interface entre les Application et les Serveurs Réception et traitement des requêtes des applications utilisateur Accès au serveurs de données Création, ouverture et fermeture des fichiers Serveur de noms (itératif) Gestion des noms des fichiers Gestion des accès Création des machines (serveurs)

LH*

LH* : Proposée par Litwin, Neimat, Schneider (ACM-Sigmod 1993) LH* : Présentation LH* : Proposée par Litwin, Neimat, Schneider (ACM-Sigmod 1993) Une SDDS basée sur Linear Hashing (LH LH : proposé par Litwin 1978, (VLDB-78), décrit dans plusieurs livres sur SGBDs. Plusieurs variantes proposées depuis par d'autres chercheurs

Le fichier est composé de cases de capacité b >> 1 LH : Rappel Le fichier est composé de cases de capacité b >> 1 LH = algorithme de hachage extensible (Etendre l'espace d'adressage primaire pour éviter l'accumulation de débordements et la détérioration progressive de performances d'accès Éclatement de cases en remplaçant hi avec h i+1 ; i = 0,1,.. Hachage par division hi (c) = c mod 2i N En moyenne, b/2 clés sont transférées vers une nouvelle case

Un éclatement a lieu quand une case déborde Calcul d’adresse LH : Rappel Un éclatement a lieu quand une case déborde Calcul d’adresse a  hi( c ) si a < n a  hi+1 ( c) Fsi n étant la prochaine case à éclater On n'éclate pas la case qui déborde, mais celle pointée par un pointer n. n évolue : 0 /0,1/ 0,1,2,3/ 0,1,..,7/ 0,..,2i N / 0..

mettre chaque case sur un serveur diffèrent LH* : Idée Idée pour LH* : mettre chaque case sur un serveur diffèrent Ajouter dans la case son niveau Propriété de LH : Une clé c est dans une case m adressée par une fonction hj Ssi hj (c) = m Le niveau de m est soit j = i soit j = i + 1 Niveau : moyen de vérifier que l’adresse d’une clé (obtenu par le client) est la bonne.

serveurs j = 4 j = 4 j = 3 j = 3 j = 4 j = 4 1 2 7 8 9 n = 2 ; i = 3 LH* : Eclatement serveurs j = 4 j = 4 j = 3 j = 3 j = 4 j = 4 1 2 7 8 9 n = 2 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

serveurs j = 4 j = 4 j = 3 j = 3 j = 4 j = 4 1 2 7 8 9 n = 2 ; i = 3 LH* : Eclatement serveurs j = 4 j = 4 j = 3 j = 3 j = 4 j = 4 1 2 7 8 9 n = 2 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

serveurs j = 4 j = 4 j = 3 j = 3 j = 4 j = 4 1 2 7 8 9 n = 2 ; i = 3 LH* : Eclatement serveurs j = 4 j = 4 j = 3 j = 3 j = 4 j = 4 1 2 7 8 9 n = 2 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

serveurs j = 4 j = 4 j = 3 j = 3 j = 4 j = 4 1 2 7 8 9 n = 2 ; i = 3 LH* : Eclatement serveurs j = 4 j = 4 j = 3 j = 3 j = 4 j = 4 1 2 7 8 9 n = 2 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

serveurs j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 LH* : Eclatement serveurs j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 n = 3 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

Détermine quelle case doit être éclaté et quand. LH* : Site coordinateur Détermine quelle case doit être éclaté et quand. Problème Peut tomber en panne Chaque collision coûte un message et un éclatement coûte 2 messages au SC. Solution : utilisation d’un jeton (pour désigner la prochaine case à éclater

Soit d la charge d’une case et b sa capacité ; LH* : Utilisation d’un jeton Quand il y a insertion dans une case qui détient le jeton, celle-ci est éclatée si d > b, puis le jeton passe à la case suivante Soit d la charge d’une case et b sa capacité ; d > b :cas de plusieurs cases en débordement Toute case qui reçoit le jeton pour la première fois s’éclate si sa charge d est supérieure à b Se déplace comme n ( pointeur d ’éclatement)  Éclatement en cascade.

Serveur a recevant la clé c ( a = m ) Le client a' := hj (c) LH* : Adressage Serveur a recevant la clé c ( a = m ) Le client a' := hj (c) si a' = a alors accepte c sinon a'' := hj - 1 (c) si a < a'' < a' alors a' := a'‘ envoies c à la case a' Calcule l'adresse LH de la clé c dans son image, soit m, et Envoie c au serveur m Proposition : L’algorithme appliqué au serveur trouve l’adresse de toute clé C envoyée par un client, et C est renvoyée au plus deux fois

n' := a +1 si n’ ≥ 2i‘ alors n' = 0, i' := i' +1 LH* : Ajustement de l’image du client Soit i' et n’ les paramètres du client i' := j - 1 n' := a +1 si n’ ≥ 2i‘ alors n' = 0, i' := i' +1 Le message IAM consiste à ajuster l’image du client en fonction - du niveau j du serveur trouvé (directement ou après renvoi) - du serveur a adressé la première fois.

Serveurs j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 15 LH* : Exemple d’adressage Serveurs j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 15 n = 3 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

Serveurs 15 j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 LH* : Exemple d’adressage Serveurs 15 j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 n = 3 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

Serveurs 15 j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 LH* : Exemple d’adressage Serveurs 15 j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 a =0, j = 3 n = 3 ; i = 3 n' = 1, i' = 2 n' = 3, i' = 2 Site coordinateur Client Client

serveurs j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 9 LH* : Exemple d’adressage serveurs j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 9 n = 3 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

serveurs j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 9 LH* : Exemple d’adressage serveurs j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 9 n = 3 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

serveurs 9 j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 LH* : Exemple d’adressage serveurs 9 j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 n = 3 ; i = 3 n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur Client Client

serveurs 9 j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 LH* : Exemple d’adressage serveurs 9 j = 4 j = 4 j = 4 j = 3 j = 4 j = 4 j = 4 1 2 7 8 9 10 a = 0, j = 4 n = 3 ; i = 3 n' = 1, i' = 3 n' = 3, i' = 2 Site coordinateur Client Client

(Exemple : recherche d’un ensemble d’éléments) LH* : Requête parallèle Opération envoyée par un client qui s’exécute en parallèle sur une partie du fichier ( ou tout le fichier) (Exemple : recherche d’un ensemble d’éléments) 2 solutions Utilisation des messages Point à point. Utilisation des messages Broadcast / Multicast

a = 0, 1, 2, …, (2i + n - 1) 2 stratégies de terminaison: LH* : Requête parallèle (Solution Brodacast / Multicast ) 2 stratégies de terminaison: La requête Q est envoyée à tous les serveurs LH* Probabilistique : Un time-out est initialisé après réception de chaque article. Seuls les serveurs concernés retournent des réponses au client Déterministique : Chaque serveur répond avec son numéro ( case a) et son niveau ja Le client termine quand il reçoit dans un ordre quelconque a = 0, 1, 2, …, (2i + n - 1) Avec i = Min(ja) et n = Min(a) tel que ja = i. Le client collecte toutes les réponses pour construire la réponse globale de Q. haque

1. Le client envoie la requête Q à tous les serveurs de son image LH* : Requête parallèle (Solution Point à Point ) 2. Chaque serveur qui reçoit Q, envoie le message vers les cases ne figurant pas dans l’image du client ( par propagation ) 1. Le client envoie la requête Q à tous les serveurs de son image (Q = Clé + {S1, S2, …Sn} 5. Même stratégies de terminaison 3. Seuls les serveurs concernés retournent des réponses haque 4. Le client collecte toutes les réponses pour construire la réponse globale de Q.

Envoyer (Q, j’) au serveur a + 2j’-1 FTq LH* : Requête parallèle (Algorithme de propagation) Tq j’ < j j’  j’ + 1 Envoyer (Q, j’) au serveur a + 2j’-1 FTq Appliqué au niveau de chaque serveur a de niveau j haque

LH* : Résultats On peut construire un fichier distribué grandissant à une taille quelconque Toute insertion et toute recherche peuvent être faites au plus en 4 messages (IAM inclus) En général une insertion est faite en un message et une recherche en deux messages

TH*

Accès aux fichiers monocles, ordonnés et dynamiques. Rappel Hachage Digital (TH) Accès aux fichiers monocles, ordonnés et dynamiques. Utilise une fonction de hachage variable (un arbre digital) Caractéristiques principales : l'arbre réside en mémoire pendant l'exploitation du fichier. 6 Octets / case du fichier Un accès au plus pour retrouver un article

Idée : représenter les liens de manière implicite Rappel Hachage Digital Compact(CTH) Idée : représenter les liens de manière implicite Consommation : 3 octets par case du fichier. Algorithmes plus complexe et plus long Economie d’espace mémoire. Intéressante pour un environnement distribué.

Données: a, ce, dx, ef, h, x, y, kx, fe, hx, hy, yya, yyb, yyc CTH : Exemple Données: a, ce, dx, ef, h, x, y, kx, fe, hx, hy, yya, yyb, yyc L'arbre : d 0 h _ 1 4 k 3 y y a 2 5 Nil | Nil Le fichier a ce dx ef fe h x y yya kx hx hy yyb yyc 1 2 3 4 5

Un arbre digital partiel CTH * : Concept Serveur Client - Un arbre digital partiel (trace de tous les éclatements ) -Une case contenant les articles du fichier Un arbre digital partiel   - Mise à jour progressive de l'arbre du client (IAM). Initialisation du système Serveur 0 Case vide ; Intervalle = ]- ∞, + ∞[ Arbre : | 0 Arbre : | 0

L'expansion du fichier se fait à travers les collisions. CTH * : Fonctionnement Serveur Client L'expansion du fichier se fait à travers les collisions. Essaie d’accéder à l’information par son image A chaque collision un nouveau serveur est ajouté.  Algorithme de transformation Clé Adresse Quand une case (serveur) éclate , il y a Extension de l’arbre du serveur Initialisation d’un nouveau serveur Partage des articles entre l’ancien et le nouveau Reçoit les IAM pour améliorer Son image Algorithme d’ajustement de l’image Algorithme d’éclatement

CTH * : Illustration

CTH * : Algorithme de transformation (Client, Clé)  Adresse Appliquer l’algorithme de transformation CTH au niveau du client sur la clé C. La clé C est dans l’intervalle de m ? Traiter la requête de recherche et répondre au client. Appliquer l’algorithme d’ajustement de l’image du client. NON OUI Fin Appliquer l’algorithme de transformation CTH au niveau de m sur la clé C. Rediriger la requête vers le serveur m’. m←m’. m’ Serveur m

CM, la clé maximale du serveur m selon l’arbre du serveur CTH * : Algorithme d’ajustement de l’image Soit CM’ = C0C1...Ck la clé maximale du serveur trouvé (m) dans l’arbre du client CM, la clé maximale du serveur m selon l’arbre du serveur 1)     Trouver dans l’arbre du client la première branche b qui vérifie b +’||...|’ ≥ CM avec b=b1 b2 …bTaille(b) 2)     Remplacer la séquence de l’arbre du client ( bM+1 …m) par la séquence de l’arbre du serveur (CM+1…Ck m…m’) - M étant la taille de préfixe commun entre CM et b - m’ est le serveur qui correspond à CM’ dans l’arbre du serveur

Arbre du client : a _ 0 Nil | 1 Serveur1 : a a _ 1 Nil Nil | 2 CTH * : Algorithme d’ajustement de l’image (Exemple) Arbre du client : a _ 0 Nil | 1 Serveur1 : a a _ 1 Nil Nil | 2   Données client : m=1 et CM’= ‘|’ Données serveur : CM=’aa_’ ; m’=2 ; P = a a _ 1 Nil Nil | 2  1)      b =’aNil’ 2)      M = 1 3)      bM+1 est Nil  a _ 0 a _ 1 Nil Nil | 2

CTH * : Algorithme d’éclatement du serveur 1. Appliquer l'algorithme d'éclatement de CTH ( Deuxième manière ) pour modifier l'arbre du serveur m 2. Partager les clés entre m et m' ; 3. Au niveau du serveur m', initialiser l'arbre avec les digits de CM suivis d'une feuille m' suivie de k-1 nœuds Nils. m : serveur éclaté m' : nouveau serveur à créer CM: clé maximale de m de longueur k. Garder un nœud Nil en plus et éviter de faire un accès au serveur père pour voir s’il y a un nœud Nil qui le précède.

CTH * : Performances A : algorithme d’ajustement de l’image du client

CTH * : Variante1 : CTH* avec arbre central Pas d’arbre au niveau des serveurs Arbre réel au niveau d’un serveur Pas de multicast.

CTH * : Variante2 : CTH* avec Multicast Pas d’arbre au niveau des serveurs Pas d’arbre central

Généralisation de TH pour le distribué CTH * : Synthèse Généralisation de TH pour le distribué Préservation de l’ordre des articles Toutes les opérations sans multicast Résultats remarquables: Forward : 0.38 : Sur 1000 recherches, 380 avec une seule Redirection (forward) en moyenne IAM : Quelques octets ( < 5 ) Chargement des serveurs : 70 %

RP*

RP* : Famille (Range Partitioning) Fichier RP*N : utilisation exclusive du Multicast. Le client ne comporte aucune image sur le fichier distribué. Un fichier RP*C : c’est un fichier RP*N avec une image au niveau de chaque client. Utilisation de Unicast et Multicast Un fichier RP*S : c’est un fichier RP*C + un index distribué au niveau des serveurs indexant toutes les cases. Élimine le multicast.

Un fichier RP*N évolue par éclatement de cases ( comme un B-arbre). RP* N : Structure Chaque case du fichier contient au maximum b enregistrements, et est stockée en mémoire centrale sur un serveur. Un fichier RP*N évolue par éclatement de cases ( comme un B-arbre). A chaque case est associée à un intervalle noté (  , ],  : clé minimale de la case et  : clé maximale. Les cases forment une partition sur l’ensemble des clés.

Toutes les insertions initiales vont à la case 0. RP* N : Evolution du fichier Un fichier RP*N est initialement constitué d’une case unique (case 0), avec  =- et  =+ . Toutes les insertions initiales vont à la case 0. Elle est éclatée lorsqu’elle atteint sa capacité maximale b. L’éclatement consiste à déplacer la moitié des enregistrement s vers un nouveau serveur selon une clé du milieu notée cm.

RP* N : Exemple (b=4) to the of and +  -  a of and a - to the +  1

1 is 1 2 RP* N : Exemple (b=4) of in and a - to the that +  in and a 1 is in and a - to the that +  of is 1 2

1 2 1 2 3 for RP* N : Exemple (b=4) in i and a - to the that +  of is for 1 2 for and a - to the that +  of is in i 1 2 3

- Utiliser un message Unicast si le serveur est déjà référencée. RP* C : Structure de l’image RP*C crée une image du fichier sur chaque client pour réduire l’usage de messages Multicast. Image = une collection des intervalles et des adresses des différentes cases déjà accédées. Ne reflète pas (en général)la structure exacte de la répartition du fichier sur les serveurs. Rôle de l’image: - Utiliser un message Unicast si le serveur est déjà référencée. - Utiliser un message Multicast dans le cas contraire.

i A : adresse d’une case C : Clé maximale dans la case RP* C : Structure de l’image A : adresse d’une case C : Clé maximale dans la case A(i) C(i) …. i A peut être égal à * : adresse inconnue Table ordonnée selon la clé Puis, elle évolue en fonction des IAM (Messages d’ajustement de l’image) Au départ : T ne contient que l’élément (0, ].

RP* C : Accès à l’article (Coté Client ) ( Cas de recherche d’un enregistrement de clé c ( valable pour les mises à jour et insertions ) Désignons par R(c) la requête correspondant à la recherche de la clé c. Le client recherche d’abord l’entrée i dans T ayant la plus petite clé telle que C(i) c. Si A(i) ‘*’ alors il envoie R(c) par Unicast au serveur d'adresse A(i). Sinon R(c) est envoyée à tous les serveurs à l’aide d’un message Multicast.

Un serveur (recevant R(c)) RP* C : Accès a l’article (Coté Serveur ) Un serveur (recevant R(c)) Vérifie d’abord si c appartient à son intervalle. Cas favorable : le serveur exécute R(c), puis envoie une réponse au client. Cette réponse contient éventuellement l’enregistrement de c trouvé, ainsi que l’adresse et l’intervalle du serveur (IAM) Cas défavorable : R(c) est ignorée si elle a été envoyée par Multicast. Sinon, il s’agit d’une erreur d’adressage. En cas d’erreur d’adressage Le serveur redirige alors la requête par Multicast vers les autres serveurs. Le message redirigé contient, en plus de R(c), l’adresse du serveur et son intervalle.

L ’intervalle ( ,  ] est celui du serveur ayant traité la requête RP* C : Accès à l’article Toute réponse à une requête envoyée sans erreur d’adressage contient un IAM noté (  , a,  ) L ’intervalle ( ,  ] est celui du serveur ayant traité la requête a représente son adresse. Une réponse à une requête redirigée comporte deux IAM Serveur qui a effectué la redirection Serveur qui l’a traitée. Dans les deux cas, le client corrige son image à l’aide de chaque IAM, selon un algorithme de mise à jour de l’image.

IAM Table T 0  (-, for, 0) 0 for  *  0 for  * in  *  RP* C : Exemple (Evolution de l’image) 0  IAM (-, for, 0) 0 for  *  0 for  * in  *  (in, of, 2) 0 for  * in  2 of  *  Table T

IAM Table T (of, , 1) 0 for  * in | 2 of | 1 RP* C : Exemple (Evolution de l’image) IAM (of, , 1) 0 for  * in | 2 of | 1 0 for  3 in  2 of  1  (for, in, 3) Table T

Éliminer l’usage du Multicast pour envoyer les requêtes simples RP* S : Concept Objectifs : Éliminer l’usage du Multicast pour envoyer les requêtes simples Accélérer la convergence de l’image du client pour réduire le nombre d’erreur d’adressage. Un client RP*S a la même table qu’un client RP*C ( Sans ‘*’). RP *S ajoute à RP *C un index réparti au niveau de serveurs spécifiques appelés serveurs d’index. Cet index représente une image de la structure globale de la répartition du fichier distribué Il est transparent aux clients.

L’index RP *S = un arbre-B+ distribué. RP* S : Structure de l’index réparti L’index RP *S = un arbre-B+ distribué. Deux types de serveurs : Les serveurs d’index (nœuds internes) - Les serveurs de données (feuilles) Serveur d’index : contient au maximum m (m >>1) couples (A, C) ordonnés. Serveur de données est muni d’un en-tête contenant son intervalle et un pointeur vers le nœud feuille d’index le plus à gauche ( même remarque) Serveur d’index = nœud d’un B-arbre Avec un en-tête contenant son intervalle et un pointeur vers son nœud parent (utilisé pour la redirection en cas d’erreur d’adressage)

- in c 0 for 3 in  c2 of 1 these 4 RP* S : Exemple d’index à deux niveaux - + * a in b c a - in c 0 for 3 in  c2 of 1 these 4 b for and a these the that of It is in i to this a for - a these of a of in a in for a  these 1 2 3 4

RP* S : Evolution a 1. La case 0 est éclatée comme dans RP*N. Il en résulte la création du premier nœud a - +   *  0 Cm1 1 2. Le nœud a est créé avec le triplet (0, Cm1, 1). Cm1 : clé du milieu. a 3. Tout autre éclatement entraîne l'insertion d’un nouveau couple (Cmr,r) dans a - +   *  0 Cm1 1 Cm2 2 …. 4.Quand le nœud a devient plein, il est divisé en 2 - +   *  a Cm b c - a  c  ….. a a +   c  ….. b 5. Le nouveau nœud racine c est créé avec l’intervalle (- ,+ ) et de pointeur père *. C’est le père des nœuds a et b. 6. Etc.

Alors S exécute la requête RP* S : Accès au fichier Coté Client : Recherche dans son image l’adresse du serveur, soit S Coté serveur : Si c  ( ,  ], Alors S exécute la requête Sinon S redirige la requête vers son nœud père P 4. La feuille finale renvoie un IAM au client avec la trace du chemin parcouru par la requête dans l'arbre. 2. Si c ( p,  p] de P, Alors P envoie la requête à la case contenant l'enregistrement de clé c. Sinon P redirige la requête au niveau supérieur 3. Ce processus est répété jusqu'à ce qu'une feuille ou la racine soit atteinte.

Rp*s : schéma déterministe ordonné(fonctionne sans multicast) RP* S : Synthèse Rp*s : schéma déterministe ordonné(fonctionne sans multicast) En terme de messages : Rp*N meilleur que Rp*C meilleur que Rp*S En terme de convergence des images des clients Rp*S meilleur que Rp*C Facteur de chargement : le même pour les 3 méthodes(70% pour les insertions aléatoires Inconvénient : exige beaucoup de message lors des opérations de recherche, insertion, ajustement, etc.