Evaluation des Operations Relationnelles : Algorithmes Additionnels

1. Evaluation des Operations Relationnelles : Algorithmes Additionnels Chapitre 14, 14.1--14.3, 15.5-14.7

2. Sélections: Utilisation d’un Index • Le coût dépend du # de tuples qualifiés et du groupement: • Le coût (généralement petit) pour trouver les entrées de données qualifiées, plus le coût (généralement significatif) pour retrouver les enregistrements. • En supposant une distribution uniforme des noms, environ 10% des tuples sont qualifiés pour une sélection de la forme «  rname < ‘C’» (i.e. 100 pages, 10000 tuples). Avec un index groupé, le coût est moins que 100 I/Os; avec un index non groupé, le coût peut aller jusqu’à 10000 I/Os! • Amélioration importante pour les indexes non groupés: 1. Trouver les entrées de données <k,rid> (rappel rid = <page_id, slot#>). 2. Trier les rid’s des enregistrement de données à extraire selon la composante page_id. 3. Puiser les rids dans l’ordre des page_id’s. Ceci garantit que chaque page emmenée en mémoire permet d’atteindre les tuples qualifiés l’un après l’autre.

3. Approches pour Sélections Générales • Première approche:Trouver le chemin d’accès le plus sélectif, extraire les tuples utilisant ce chemin et appliquer les termes restants qui ne correspondent pas au chemin d’accès: • chemin d’accès le plus sélectif: un index ou un scannage qui, selon une estimation, requiert le moins d’accès au disque. • Les termes qui correspondent à cet index réduisent le nombre de tuples extraits; d’autres termes sont utilisés pour éliminer quelques tuples extraits, mais n’affectent pas le nombre de pages extrait du disque. • Considérons day<8/9/94 AND bid=5 AND sid=3. Un index à arbre B+ sur day peut être utilisé; apres cela, bid=5 et sid=3 doivent être validés pour chaque tuple extrait. De même, un index à hachage sur <bid, sid> pourrait être utilisé; day<8/9/94 doit alors etre validé.

4. Approches pour Sélections Générales (Suite) • Seconde approche(Si nous avons 2 ou plusieurs indexes correspondants à la condition qui utilisent les alternatives (2) ou (3) des entrées de données): • Obtenir l’ensembles de rid’s des enregistrements des données en utilisant chaque index correspondant à la condition. • Ensuite calculer l’intersection de ces ensembles de rid’s. • Extraire les enregistrements du disque et appliquer les termes restants. • Considérons day<8/9/94 AND bid=5 AND sid=3. Si nous avons un index à arbre B+ sur day et un index sur sid utilisant l’alternative (2), nous pouvons extraire les rid’s des enregistrements qui satisfont day<8/9/94 en utilisant le premier index, ensuite les rid’s des enregistrements qui satisfont sid=3 en utilisant le deuxième index, calculer l’intersection, et appliquer le terme bid=5.

5. SELECTDISTINCT R.sid, R.bid FROM Reserves R Projection • Algorithme basé sur le tri: • Scanner R afin de produire des tuples qui contiennent seulement les attributs désirés. • Trier l’ensemble de tuples résultant de la première étape en utilisant la combinaison de tous ses attributs comme clé de tri. • Scanner le résultat de la deuxième étape en comparant les tuples adjacent afin d’éliminer les duplicatas. • Coût: O(MlogM) • Ce coût est essentiellement le fait de la deuxième étape.

6. Projection (Suite) • Une amélioration de l’approche basée sur le tri: • Modifier le passage 0 du tri externe afin d’éliminer les valeurs des colonnes ne figurant pas sur la liste de projection. • En fait les tuples dans les runs sont plus petits que les tuples originaux; et leur taille dépend du nombre et de la taille des valeurs des colonnes éliminées.) • Modifier les passages de fusion afin d’éliminer les duplicatas. • Coût: • Passage 0: lecture de la relation originale (de taille M), écriture du même nombre de tuples. • Passages > 0: peu de tuples écrits à chaque passage.

7. Projection (Suite) • Une approche basée sur le hachage: • Partition: Lire R en utilisant un tampon d’entrée. Pour chaque tuple, éliminer les valeurs des colonnes ne figurant pas sur la liste de projection, applique une fonction de hachage h1 afin de choisir un des B-1 tampons de sortie. • Le résultat sera B-1 partitions (de tuples sans les champs indésirables). La méthode garantit que 2 tuples de différentes partitions sont distincts. • Elimination des duplicatas: lire chaque partition et en construire une table de hachage en mémoire principale en utilisant une fonction de hachage h2 (différente de h1) ayant comme entrée tous les champs du tuple; éliminer les duplicatas en passant. • Appliquer la méthode récursivement si la partition est trop grande. • Coût: • Partition: lire R, écrire chaque tuple de R amputé des champs indésirables • Elimination des duplicatas: lecture de tuples générés par la partition.

8. Projection (Suite) • Les algorithmes basés sur le tri sont standard. • Ils sont supérieurs au hachage • si l’on a beaucoup de duplicatas • lorsque la distribution des valeurs de hachage n’est pas uniforme • Le résultat est trié ! • Si un index sur la relation contient tous les attributs de la liste de sélection dans sa clé de recherche, nous pouvons opérer un scannage de l’index (« index-only scan »). • Cette méthode applique la projection sur les entrées de données sans jamais recourir aux données elles-mêmes. • Si un index à arbre contient tous les attributs des attributs désirés comme préfixe de la clé de recherche, nous pouvons faire mieux encore: • Extraire les entrées de données dans l’ordre (en appliquant la méthode « index-only scan ») en éliminant les champs indésirables; enfin comparer les tuples adjacents pour éliminer les duplicatas.

9. Opérations Ensemblistes • Intersection et produit Cartésien: cas spéciaux du join • Intersection: un join avec égalité sur toutes les colonnes • Produit Cartésien: un join sans condition • Union de R et S: Algorithme basé sur le tri: • Trier les deux relations (en combinant tous les attributs). • Scanner les relations triées simultanément et les fusionner, en éliminant les duplicatas. • Amélioration: produire des runs triés de R et S et les fusionner simultanément. • Différence (R – S): • Pendant la fusion, sortir les tuples de R qui n’apparaissent pas dans S.

10. Opérations Ensemblistes (Suite) • Union de R et S: Algorithme basé sur le hachage: • Partition de R et S en utilisant une fonction de hachage h. • Traiter chaque partition l de S comme suit: • Construire une table de hachage pour la partition l en mémoire en utilisant h2, différent de h1. • Scanner la partition correspondante l de R, et pour chaque tuple de cette partition, chercher le tuple correspondant dans la partition l de S en utilisant h2. Si le tuple est dans la table de hachage, l’éliminer, sinon, l’y inscrire. • Sortir la table de hachage et réinitialiser celle en mémoire pour la prochaine partition de S. • Différence (R – S): • Scanner la partition l de R comme ci-dessus, et pour chaque tuple de cette partition, chercher le tuple correspondant dans la partition l de S en utilisant h2. Si le tuple n’est pas dans la table de hachage, le sortir dans le résultat, sinon, l’éliminer.

11. Operations d’Agrégat • AVG, MIN, COUNT, MIN, MAX • Sans GROUP BY: • En général, un scannage de la relation est requis. • S’il existe un index dont la clé de recherche contient tous les attributs dans les clauses SELECT ou WHERE, on peut utiliser la méthode « index-only scan ».

12. Operations d’Agrégat (Suite) • Avec GROUP BY: • Trier la relation en utilisant les attributs de GROUP BY, ensuite scanner la relation et calculer l’agrégat pour chaque groupe. (Amélioration: combiner le tri et le calcul de l’agrégat.) • S’il existe un index à arbre dont la clé de recherche contient tous les attributs dans les clauses SELECT,WHERE et GROUP BY, on peut utiliser la méthode « index-only scan »; Si les attributs de GROUP BY forment un préfix de la clé de recherche, nous pouvons extraire les entrees de donnees/tuples dans l’ordre dicté par GROUP BY. • Une approche basée sur le hachage existe aussi; elle est similaire aux algorithmes des opérations précédentes.

13. Résumé • Une implémentation soigneusement faite des operateurs de l’algèbre relationnelle est très importante. • En général, plusieurs algorithmes alternatifs existent pour chaque operateur et aucun d’eux n’est universellement supérieur aux autres. • Ainsi donc, toutes les alternative disponibles doivent être considérées pendant l’exécution d’une requête afin de choisir la meilleure alternative pour chaque cas d’espèce.