Evaluation de requêtes Quelques résultats préliminaires 1 Amin Mesmoudi.

Présentation au sujet: "Evaluation de requêtes Quelques résultats préliminaires 1 Amin Mesmoudi."— Transcription de la présentation:

1 Evaluation de requêtes Quelques résultats préliminaires 1 Amin Mesmoudi

2 Les Besoins LSST en stockage et accès aux données Accès – SQL – Possibilité de définir des fonctions ad hoc par l’utilisateur (UDF) – Exemple: areaspec_box, angSep < dist – 500,000 requêtes par jour Objectif: mener des expérimentations avec quelques outils de gestion de données existants 2

3 Phases d'expérimentations 3 PT 1.1 PT 1.2 250 Go 500 Go 1 To 2 To 3 M 6 M 12 M 25 M 50 M 100 M Phase 1 Phase 2 Phase 3

4 Configurations Systèmes utilisés: – Centralisés: Oracle, Postgresql et Mysql Taux de transfert disque: 113 Mo/s – Distribués : Hive (0.11) : map/reduce & HDFS HadoopDB: map/reduce & DBMS Réseau: 1 Go/s 4

5 Hive et HadoopDB 5 Map/re duce HDFS HIVE Map/reduce HDFS HIVE* (modified) RDBMS HadoopDB Hive

6 Jeux de données 6 Table#attributes#recordssize#indexesexpected size expected #attributes expected #records PT 11 Object2275 M5 GB2109 TB47036 B PT 11 Source92165 M85 GB73,6 PB1255 T PT 12 Object2295 M7 GB2109 TB47038 B PT 12 Source107180 M118 GB73,6 PB1255 T PT1.2.*250 go PT1.2.*500 go PT1.2.*1 To PT1.2.*2 To

7 Requêtes Requêtes SQL Standards: (PT 1.1, PT1.2) 7

8 Paramètres à mesurer (1/2) 8 Tuning: Temps de chargement de données (indexation, partitionnement, …) Performances: Temps total d'exécution des requêtes Tolérance aux fautes: Nombre de fautes gérées par l’outil Latence: temps nécessaires pour avoir la première réponse

9 Paramètres à mesurer (2/2) 9 Montée en charge (volume de données): – PT1.1  PT 1.2 – PT 1.2 (250 Go)  PT 1.2 (250 Go)  PT 1.2 (500 Go)  PT 1.2 (1 To)  PT 1.2 (2 To) Evolution Matérielle: – 3 machines  6 machines  12 machines – 25 machines  50 machines

10 Performances – Phase 1 Sans Index – Prétraitement: HadoopDB a besoin de 120 %- 640 % du temps nécessaire pour Hive – Performances: 1.HadoopDB > Hive : Requêtes avec quelques tuples a manipuler 2.Hive > HadoopDB: le plan d’exécution comporte une phase de reduce couteuse 3.Les autres requêtes: Dépondent de l’état des données (partitionnées, triées,,,,) Avec index – Prétraitement: Pas d’index pour Hive HadoopDB: présente 12%-30 % du temps nécessaire pour le chargement des données et une augmentation de 3%-10 % par rapport au chargement des données sans index – Performances: Augmentation pour les requêtes utilisant des attributs qui servent comme indexes Diminution pour les autres requêtes Evolution matérielle: – Augmentation des performances pour les deux outils Latence: – Supportée par les SGBD classiques et pas encore par la nouvelle génération des SGBD 10

11 Performances – Phase 2 - chargement de données Hive: HadoopDB: 11 250Go500Go1To2 To 252h104h308h3017h 502h104h308h3017h 250Go500Go1To2 To 257H1712h4028h55- 505h4010h4021h45-

12 Performances – Phase 2 - requêtes Selection: – Q1: sourceid comme attribut de sélection – Q2:Objectid comme attribut de sélection – Q3:RA et Decl – Q4:scienceccdexposureid Groupe by: – Q5:petite zone (ra et decl) – Q6:large zone Join: – Q7:petite zone – Q8:large zone – Q9:3 tables Order By: – Q10: petite zone – Q11:large zone 12

13 Performances – Phase 2 - sans index Partitionnement par défaut: Selection: – HadoopDB > Hive: différence de performances de 63 % a 530 % Groupe by: – Petite zone: HadoopDB > Hive: différence de performance de 1500% – Large zone: Hive > HadoopDB: différence de performance de 270 % Join: – HadoopDB ne supporte pas la jointure de plusieurs tables – 170 % (petite zone) a 12000 % (large zone) Order By – HadoopDB > Hive avec 200 % de différence Partitionnement avec ObjectId: – Gain en performance pour la requête Q6 13

14 Performances – Phase 2 - Création d’index 5 indexes Hive: HadoopDB: 14 250Go500Go1To2 To 2550 min2h054h339h09 5031min1h283h287h21 250Go500Go1To2 To 251h1h152h- 501h1h151h30-

15 Performances – Phase 2 - avec index Hive: – Refuse d’utiliser les index s’ils les données sélectionnées représentent une taille importante – Augmentation de performance jusqu’a 7000 % – Les indexes peuvent être utilisé que pour la sélection, le group by et l’order by – Le choix de l’index est fait manuellement (pas d’optimiseur disponible) HadoopDB: – Augmentation des performances jusqu’a 900% – Chaque SGBD essaye de trouver la meilleur stratégie d‘évaluation de la requête sans prendre en compte le plan globale d’exécution – Diminution de performances pour quelques requêtes (exp. Q7) 15

16 Merci pour votre attention 16