Amin Mesmoudi. Les Besoins LSST en stockage et accès aux données (1/2) Stockage: 2 TableTaille#enregistrements#colonnes (arité) Object109 TB38 B470 Moving.

Présentation au sujet: "Amin Mesmoudi. Les Besoins LSST en stockage et accès aux données (1/2) Stockage: 2 TableTaille#enregistrements#colonnes (arité) Object109 TB38 B470 Moving."— Transcription de la présentation:

1 Amin Mesmoudi

2 Les Besoins LSST en stockage et accès aux données (1/2) Stockage: 2 TableTaille#enregistrements#colonnes (arité) Object109 TB38 B470 Moving Object5 GB6 M100 Source3.6 PB5 T125 Forced Source1.1 PB32 T7 Difference Image Source 71 TB200 B65 CCD Exposure0.6 TB17 B45

3 Les Besoins LSST en stockage et accès aux données (2/2) Accès Requêtes déclaratives (SQL) Possibilité de définir des fonctions ad hoc par l’utilisateur (UDF) Exemple: areaspec_box, angSep < dist 500,000 requêtes par jour 3 SELECT objectId, taiMidPoint, fluxToAbMag(psfMag) FROM Source JOIN Object USING(objectId) JOIN Filter USING(filterId) WHERE areaSpec_box(:raMin, :declMin, :raMax, :declMax) AND filterName = 'u' AND variability BETWEEN :varMin AND :varMax ORDER BY objectId, taiMidPoint ASC

4 Objectifs généraux PO Proposer une architecture distribuée pour stocker quelques dizaines de PO de données Open Source Shared-Nothing secondes heures Pouvoir évaluer aussi bien des requêtes simples (quelques secondes de calcul) que des requêtes complexes (des heures de calcul) (>> 1 PO Possibilité d’accéder à des objets en utilisant des indexes ou en procédant à un parcours (scan) complet des grosses tables (>> 1 PO)

5 Approche (1/2) Mise en place d'un environnement d’expérimentation avec 100 machines virtuelles. 350 Go d’espace disque 8 Go de RAM Systèmes de gestion de données Centralisés: Mysql, PostgresQL et DBMS-X Distribués (à la Map/Reduce): Hive et HadoopDB Caractérisation des requêtes selon la difficulté des traitements Extraction d’un jeu de 13 requêtes compatibles avec les systèmes existants

6 Approche (2/2) Développement d'un générateur de données 4 To de données pour évaluer les possibilités des systèmes existants (centralisés et distribués) Identification/sélection de quelques métriques : passage a l’échelle (#machines, volume de données), latence et tolerance aux fautes Expérimentation en considérant quelques indicateurs et les techniques d’optimisation disponibles ( ex., compression de données, distribution de calculs, indexation, utilisation des caches )

7 Enseignement tiré Les outils existants ne répondent que partiellement aux exigences de requêtage LSST Plusieurs techniques d'optimisation (indexation, partitionnement, utilisation de tampons,...) devraient être revisitées Pour plus d’informations : http://com.isima.fr/Petasky/hive-vs-hadoopdb Amin Mesmoudi, Mohand-Saïd Hacid and Farouk Toumani. Benchmarking SQL on MapReduce systems using large astronomy databases. Distributed and Parallel Databases (DAPD). January 2015. http://link.springer.com/article/10.1007/s10619-014-7172-8 http://link.springer.com/article/10.1007/s10619-014-7172-8

8 Quelques Réflexions Le modèle Relationnel et les données LSST ? 50 % des valeurs des tables sont NULL L’ajout d’un nouvel attribut pour certains tuples implique l’ajout de plusieurs valeurs null Un partitionnement basé sur une seule valeur (hachage) est-il suffisant pour équilibrer les charges des machines ? Concernant le modèle Map/Reduce ? Diviser le traitement en deux étapes Pas de vue globale dans la 1ère étape Pas d’accès locale en 2ème étape Pour les requêtes avec plusieurs opérateurs : Accès aux données (scan complet, index) Ordre d’évaluation des différents opérateurs (Projection, Sélection, Jointure, UDF, …) Si les données sont répliquées, quel réplica utiliser pour minimiser le coût du traitement des requêtes ? Plans d’exécution: Plusieurs plans physiques possibles, comment choisir le plan optimal ? Comment éviter les plans très couteux ? Comment estimer le coût d’évaluation d’un plan donné ? Phase 1: pousser les traitements vers les données Phase 2: pousser les données vers les traitements

9 Proposition Un graphe pour garantir l’unicité des valeurs dans la base de données ? On pourrait élaguer les nœuds inutiles, c-à-d les valeurs qui ne participeront pas à la construction des résultats finaux Exploration avec les arcs entrant et les arcs sortants Plusieurs combinaisons peuvent être utilisées SourceObjectID S1O1 S2O1 S3O2 ObjectIDRAdecl O14015 O24025 S1 S3 S2 O1 O2 OID 40 RA 15 Decl 25 dist 0,5

10 Stockage (1/2) SPO, OPS,… B+Tree pour chaque combinaison – recherche de triplet: log(n) RDF3X, …. x1 l1 z1 n1 k1 a b c d e y1 z2 x2 y2 a b c x1ay1 x1bz1 x1cl1 x2ay2 x2bz2 x2cl1 y1dk1 y1en1 SPO k1dY1 l1cx1 l1cx2 n1ey1 ax1 y2ax2 z1bx1 z2bx2 OPS

11 Stockage (2/2) ?x?y ?z a b Scan SPO ? SPO-Lattice a b c a a b b d e f d e f hj g c

12 Compression x1ay1 x1bz1 x1cl1 x2ay2 x2bz2 x2cl1 y1dk1 y1en1 x1ay1 x1bz1 x1cl1 x2ay2 x2bz2 x2cl1 y1dk1 y1en1 x11y1 1z11 l11x2 1y21 l1 a b c y11k1 1n1 d e a b c d e S P O Fragmentation Compression

13 Evaluation Parallèle des requêtes x1 l1 z1 n1 k1 a b c d e y1 Worker 1 z2 x2 y2 a b c Worker 2 x3 l2 z3 n2 k2 a b c d e y2 x4 a b c n3 k3 d e y3 l3 z4

14 BSP (Bulk Synchronous Parallel) BSP (Bulk Synchronous Parallel) Ne pas attendre quand on peut continuer les traitements M1 M2 Mn Super Step 1Super Step 2Super Step nSynch

15 Requête ?x cst ?y ?z Cst12 ?t ?k Cst3 a b c d e f j h g Backward Star Queries Forward Star Queries ?x Cst ?y ?z a b c ?k ?y cst12 ?t ?k d e f ?t cst3 h ?k cst3 g j SQ f 1 SQ f 2 SQ f 4 SQ f 3 SQ f 5 ?t ?k cst3 h g ?y ?t e ?y cst12 d ?y ?z ?k f j ?x cst ?y ?z a b c ?x SQb 1 SQb 2 SQb 3 SQb 4 SQb 7 SQb 5 SQb 6

16 Plan d’exécution ?x cst ?y ?z Cst12 ?t ?k Cst3 a b c d e f j h g ?x Cst ?y ?z a b c SQ f 1 ?t ?k cst3 h g SQb 1 ?y ?t e SQb 2 ?y b ?x SQb 5 ?y cst12 ?t ?k d e f SQ f 2 ?z ?k j SQ f 3 Back_instan_cst (SQb1 i ) Back_instan_cst (SQb2) For_instan_cst (SQf2) back_instan_cst (SQb5) back_instan_cst (SQf1) for_verificat (SQf1)

17 MERCI