PetaSky

Evaluation de requêtes
Quelques résultats préliminaires
Amin Mesmoudi
1
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
Phases d'expérimentations
2 To
1 To
Phase 3
Phase 2
500 Go
250 Go
PT 1.2
PT 1.1
Phase 1
3M
6M
12 M
25 M
50 M
100 M
3
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
Hive et HadoopDB
HIVE*
(modified)
HIVE
RDBMS
Map/reduce
Map/reduce
HDFS
HadoopDB
Map/reduce
RDBMS
Map/red
uce
Map/red
uce
Map/re
duce
HDFS
Hive
5
Jeux de données
Table
#attributes
#records
size
PT 11 Object
227
5M
5 GB
2
109 TB
470
36 B
PT 11 Source
92
165 M
85 GB
7
3,6 PB
125
5T
PT 12 Object
229
5M
7 GB
2
109 TB
470
38 B
PT 12 Source
107
180 M
118 GB
7
3,6 PB
125
5T
PT1.2.*
250 go
PT1.2.*
500 go
PT1.2.*
1 To
PT1.2.*
2 To
#indexes
expected
size
expected
#attributes
expected
#records
6
Requêtes
• Requêtes SQL Standards: (PT 1.1, PT1.2)
7
Paramètres à mesurer (1/2)
• 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
8
Paramètres à mesurer (2/2)
• 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
9
Performances – Phase 1
• Sans Index
– Prétraitement:
• HadoopDB a besoin de 120 %- 640 % du temps nécessaire pour Hive
– Performances:
1.
2.
3.
•
Avec index
–
Prétraitement:
•
•
–
Augmentation pour les requêtes utilisant des attributs qui servent comme indexes
Diminution pour les autres requêtes
Evolution matérielle:
–
•
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:
•
•
•
HadoopDB > Hive : Requêtes avec quelques tuples a manipuler
Hive > HadoopDB: le plan d’exécution comporte une phase de reduce couteuse
Les autres requêtes: Dépondent de l’état des données (partitionnées, triées, ,,,)
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
Performances – Phase 2 - chargement de
données
• Hive:
250Go
500Go
1To
2 To
25
2h10
4h30
8h30
17h
50
2h10
4h30
8h30
17h
250Go
500Go
1To
2 To
25
7H17
12h40
28h55
-
50
5h40
10h40
21h45
-
• HadoopDB:
11
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
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
Performances – Phase 2 - Création d’index
• 5 indexes
• Hive:
250Go
500Go
1To
2 To
25
50 min
2h05
4h33
9h09
50
31min
1h28
3h28
7h21
• HadoopDB:
250Go
500Go
1To
2 To
25
1h
1h15
2h
-
50
1h
1h15
1h30
-
14
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
Merci pour votre attention
16