Optimisation des requêtes dans les systèmes distribués

Ce chapitre traite de l'optimisation des requêtes dans un système de base de données distribué.

Architecture de traitement distribué des requêtes

Dans un système de base de données distribué, le traitement d'une requête comprend une optimisation à la fois au niveau global et au niveau local. La requête entre dans le système de base de données sur le client ou le site de contrôle. Ici, l'utilisateur est validé, la requête est vérifiée, traduite et optimisée au niveau global.

L'architecture peut être représentée comme -

Mappage de requêtes globales dans des requêtes locales

Le processus de mappage des requêtes globales sur les requêtes locales peut être réalisé comme suit -

  • Les tables requises dans une requête globale ont des fragments répartis sur plusieurs sites. Les bases de données locales contiennent des informations uniquement sur les données locales. Le site de contrôle utilise le dictionnaire de données global pour collecter des informations sur la distribution et reconstruit la vue globale à partir des fragments.

  • S'il n'y a pas de réplication, l'optimiseur global exécute des requêtes locales sur les sites où les fragments sont stockés. S'il y a réplication, l'optimiseur global sélectionne le site en fonction du coût de communication, de la charge de travail et de la vitesse du serveur.

  • L'optimiseur global génère un plan d'exécution distribué afin que le moins de transfert de données se produise sur les sites. Le plan indique l'emplacement des fragments, l'ordre dans lequel les étapes de requête doivent être exécutées et les processus impliqués dans le transfert des résultats intermédiaires.

  • Les requêtes locales sont optimisées par les serveurs de base de données locaux. Enfin, les résultats de la requête locale sont fusionnés par une opération d'union dans le cas de fragments horizontaux et une opération de jointure pour les fragments verticaux.

Par exemple, considérons que le schéma de projet suivant est fragmenté horizontalement selon la ville, les villes étant New Delhi, Kolkata et Hyderabad.

PROJET

PId Ville département Statut

Supposons qu'il y ait une requête pour récupérer les détails de tous les projets dont le statut est «En cours».

La requête globale sera & inus;

$$ \ sigma_ {status} = {\ small "en cours"} ^ {(PROJET)} $$

La requête sur le serveur de New Delhi sera -

$$ \ sigma_ {status} = {\ small "en cours"} ^ {({NewD} _- {PROJECT})} $$

La requête sur le serveur de Kolkata sera -

$$ \ sigma_ {status} = {\ small "en cours"} ^ {({Kol} _- {PROJECT})} $$

La requête sur le serveur d'Hyderabad sera -

$$ \ sigma_ {status} = {\ small "en cours"} ^ {({Hyd} _- {PROJECT})} $$

Afin d'obtenir le résultat global, nous devons unir les résultats des trois requêtes comme suit -

$ \ sigma_ {status} = {\ small "en cours"} ^ {({NewD} _- {PROJECT})} \ cup \ sigma_ {status} = {\ small "en cours"} ^ {({kol} _- {PROJET})} \ cup \ sigma_ {status} = {\ small "en cours"} ^ {({Hyd} _- {PROJECT})} $

Optimisation des requêtes distribuées

L'optimisation des requêtes distribuées nécessite l'évaluation d'un grand nombre d'arborescences de requêtes dont chacune produit les résultats requis d'une requête. Cela est principalement dû à la présence d'une grande quantité de données répliquées et fragmentées. Par conséquent, l'objectif est de trouver une solution optimale au lieu de la meilleure solution.

Les principaux problèmes liés à l'optimisation des requêtes distribuées sont:

  • Utilisation optimale des ressources dans le système distribué.
  • Trading de requêtes.
  • Réduction de l'espace solution de la requête.

Utilisation optimale des ressources dans le système distribué

Un système distribué possède un certain nombre de serveurs de base de données dans les différents sites pour effectuer les opérations relatives à une requête. Voici les approches pour une utilisation optimale des ressources -

Operation Shipping- En opération expédition, l'opération est exécutée sur le site où les données sont stockées et non sur le site client. Les résultats sont ensuite transférés sur le site client. Ceci est approprié pour les opérations où les opérandes sont disponibles sur le même site. Exemple: Opérations de sélection et de projet.

Data Shipping- Lors de l'envoi de données, les fragments de données sont transférés vers le serveur de base de données, où les opérations sont exécutées. Ceci est utilisé dans les opérations où les opérandes sont distribués sur différents sites. Ceci est également approprié dans les systèmes où les coûts de communication sont faibles et où les processeurs locaux sont beaucoup plus lents que le serveur client.

Hybrid Shipping- Il s'agit d'une combinaison de données et d'opérations d'expédition. Ici, les fragments de données sont transférés vers les processeurs à grande vitesse, où l'opération s'exécute. Les résultats sont ensuite envoyés au site client.

Trading de requêtes

Dans l'algorithme d'échange de requêtes pour les systèmes de bases de données distribuées, le site de contrôle / client pour une requête distribuée est appelé l'acheteur et les sites sur lesquels les requêtes locales s'exécutent sont appelés vendeurs. L'acheteur formule un certain nombre d'alternatives pour choisir les vendeurs et pour reconstruire les résultats globaux. L'objectif de l'acheteur est d'atteindre le coût optimal.

L'algorithme commence par l'attribution de sous-requêtes par l'acheteur aux sites du vendeur. Le plan optimal est créé à partir de plans de requêtes optimisés locaux proposés par les vendeurs combinés avec le coût de communication pour la reconstruction du résultat final. Une fois le plan optimal global formulé, la requête est exécutée.

Réduction de l'espace solution de la requête

Une solution optimale implique généralement une réduction de l'espace de la solution afin de réduire le coût des requêtes et du transfert de données. Ceci peut être réalisé grâce à un ensemble de règles heuristiques, tout comme l'heuristique dans les systèmes centralisés.

Voici quelques-unes des règles -

  • Effectuer les opérations de sélection et de projection le plus tôt possible. Cela réduit le flux de données sur le réseau de communication.

  • Simplifiez les opérations sur les fragments horizontaux en éliminant les conditions de sélection qui ne sont pas pertinentes pour un site particulier.

  • En cas d'opérations d'adhésion et d'union comprenant des fragments situés sur plusieurs sites, transférez les données fragmentées vers le site où la plupart des données sont présentes et effectuez l'opération là-bas.

  • Utilisez l'opération de semi-jointure pour qualifier les tuples à joindre. Cela réduit la quantité de transfert de données qui à son tour réduit les coûts de communication.

  • Fusionnez les feuilles et sous-arborescences communes dans une arborescence de requêtes distribuée.