Petasky 13oct2014

172 vues

Publié le

Petasky workshop 13 octobre 2014
"In The Midst" project (Distributed database mediator system)
https://github.com/emedernach/InTheMidst

Publié dans : Sciences
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
172
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
2
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Petasky 13oct2014

  1. 1. PETASKY Etat d’avancement Emmanuel Medernach IN2P3, CNRS 13 octobre 2014 E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 1 / 28
  2. 2. Plan de l’exposé 1 Introduction 2 Système de Médiation Architecture Intégration de données 3 Gestion des Requêtes Spatiales Description Commutativité Jointure spatiale 4 Planification des Requêtes Postgres FDW Plan d’exécution E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 2 / 28
  3. 3. Introduction Petasky: Gestion de Données Astrophysiques I Projet Big Data CNRS (Mastodons) I Multi-disciplinaire (Astronomie, Informatique) I Gestion de données provenant de LSST I ~ 100 Pb d’images I ~ 6 Pb de catalogues I ~ 100 tables I Evolution des données: en ajout seulement Table Taille Lignes Colonnes Object 109 TB 3.8 × 1010 470 Source 3.6 PB 5.0 × 1012 125 I Comment interroger efficacement ces données ? E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 3 / 28
  4. 4. Système de Médiation Architecture Plan de l’exposé 1 Introduction 2 Système de Médiation Architecture Intégration de données 3 Gestion des Requêtes Spatiales Description Commutativité Jointure spatiale 4 Planification des Requêtes Postgres FDW Plan d’exécution E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 4 / 28
  5. 5. Système de Médiation Architecture Partitionnement des tables I Les tables “Object” et “Source” n’existent pas physiquement. I Ces tables sont partitionnées : Object = [ i Objecti 8i6= j, Objecti Objectj = ? Definition (Pool) Un “pool” est une base de données qui contient plusieurs partitions. Les partitions sont réparties sur plusieurs pools. E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 5 / 28
  6. 6. Système de Médiation Architecture Architecture Le rôle du médiateur est de fournir à l’utilisateur une vue unifiée des tables et de réécrire les requêtes en conséquence. Pool Object_001 Source_001 Object_002 Source_002 Pool Object_003 Source_003 Object_004 Source_004 Médiateur Filter SQL SQL SQL Orchestration de bases de données. E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 6 / 28
  7. 7. Système de Médiation Intégration de données Plan de l’exposé 1 Introduction 2 Système de Médiation Architecture Intégration de données 3 Gestion des Requêtes Spatiales Description Commutativité Jointure spatiale 4 Planification des Requêtes Postgres FDW Plan d’exécution E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 7 / 28
  8. 8. Système de Médiation Intégration de données Intégration de données I Qu’est-ce que l’intégration de données (“Data Integration”) ? I Comment combiner différentes sources de données I Fournir une vue unifiée de ces données I Etablir des correspondances entre les tables (locales et distantes) I Le standard SQLMED permet d’interroger des tables à distance comme des tables locales (Postgres Foreign Data Wrapper). I Mais cela ne suffit pas: il faut mettre en place des transformations syntaxiques: I pour gérer les tables virtuelles comme Object ou Source I pour gérer leur jointure I pour réécrire les contraintes spatiales I etc. E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 8 / 28
  9. 9. Système de Médiation Intégration de données Approche “Global-As-View” Object => ( SELECT * FROM Object_000 UNION ALL SELECT * FROM Object_001 UNION ALL SELECT * FROM Object_002 UNION ALL SELECT * FROM Object_003 ) AS Object I Les tables partitionnées (Object, Source) sont remplacées par leurs définitions (UNION des partitions) I Des transformations syntaxiques sont appliquées à la requête obtenue: I Transformations des jointures Object/Source en jointures locales I Déplacement des prédicats sur les partitions I etc. E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 9 / 28
  10. 10. Gestion des Requêtes Spatiales Description Plan de l’exposé 1 Introduction 2 Système de Médiation Architecture Intégration de données 3 Gestion des Requêtes Spatiales Description Commutativité Jointure spatiale 4 Planification des Requêtes Postgres FDW Plan d’exécution E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 10 / 28
  11. 11. Gestion des Requêtes Spatiales Description Requêtes spatiales: exemples I Rectangle sphérique parallèle à ra/decl: ra_PS BETWEEN 1.9 AND 2.0 AND decl_PS BETWEEN 1.5 AND 1.6 I Prédicats sur la distance angulaire: distance(p1, p2) rayon I Recherche dans un cône (“cone search”): p2 et rayon constant I Voisinage: p1 et p2 variables, rayon constant E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 11 / 28
  12. 12. Gestion des Requêtes Spatiales Commutativité Plan de l’exposé 1 Introduction 2 Système de Médiation Architecture Intégration de données 3 Gestion des Requêtes Spatiales Description Commutativité Jointure spatiale 4 Planification des Requêtes Postgres FDW Plan d’exécution E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 12 / 28
  13. 13. Gestion des Requêtes Spatiales Commutativité Commutativité de l’UNION I Si un opérateur Op commute avec l’UNION alors il suffit de distribuer cet opérateur sur les partitions puis de faire l’UNION. Op UNION def = UNION Op I Par exemple la recherche des points dans un rectangle commute avec l’UNION: c’est l’UNION des recherches sur chaque partition. I De même avec les recherches dans un cône. E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 13 / 28
  14. 14. Gestion des Requêtes Spatiales Commutativité Non-Commutativité et conséquences I Et si un opérateur ne commute pas avec l’UNION ? Op UNION def 6= UNION Op I Par exemple, l’opérateur de “jointure spatiale” (spatial join) ne commute pas avec l’UNION (effets de bords): il demande donc un traitement à part. E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 14 / 28
  15. 15. Gestion des Requêtes Spatiales Jointure spatiale Plan de l’exposé 1 Introduction 2 Système de Médiation Architecture Intégration de données 3 Gestion des Requêtes Spatiales Description Commutativité Jointure spatiale 4 Planification des Requêtes Postgres FDW Plan d’exécution E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 15 / 28
  16. 16. Gestion des Requêtes Spatiales Jointure spatiale Jointure spatiale: extension syntaxique SELECT O.objectid as oid, S.sourceid as sid FROM Object O, Source S CROSSMATCH (O, ra_PS, decl_PS) AND (S, ra, decl) WITH RADIUS 0.0003 WHERE O.objectid S.objectid ; I () WHERE distance(p1, p2) rayon I Extension de SQL: CROSSMATCH, permet d’identifier immédiatement une jointure spatiale et d’appliquer la transformation adaptée (transformation globale de la requête). I Problème: Comment implémenter efficacement la jointure spatiale sur N pools ? E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 16 / 28
  17. 17. Gestion des Requêtes Spatiales Jointure spatiale Exemple: Jointure spatiale entre T1 et T2 Table T1 Table T2 Table T1 Table T2 E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 17 / 28
  18. 18. Gestion des Requêtes Spatiales Jointure spatiale Jointure spatiale I Rappatrier dynamiquement la bordure sur le master (mais coût important) I Idée: Stocker une table des bordures sur le master (rayon maximum fixe) I Permet d’éviter les recalculs et de rajouter des index sur cette bordure E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 18 / 28
  19. 19. Planification des Requêtes Postgres FDW Plan de l’exposé 1 Introduction 2 Système de Médiation Architecture Intégration de données 3 Gestion des Requêtes Spatiales Description Commutativité Jointure spatiale 4 Planification des Requêtes Postgres FDW Plan d’exécution E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 19 / 28
  20. 20. Planification des Requêtes Postgres FDW Problèmes avec FDW I Pas d’appels de fonctions à distance I FDW n’exploite pas le parallélisme (les pools) I Inefficace: FDW n’utilise pas les index sur les tables distantes Sur le pool: SELECT * FROM object_000 WHERE q3c_radial_query(ra_PS, decl_PS, 1.3, 3.4, .2) ; ... Time: 130.300 ms Sur le master (via FDW): SELECT * FROM master_object_000 WHERE q3c_radial_query(ra_PS, decl_PS, 1.3, 3.4, .2) ; ... Time: 130843.931 ms 1000x plus lent avec FDW ! E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 20 / 28
  21. 21. Planification des Requêtes Postgres FDW Problèmes avec FDW I Inefficacité des jointures, des produits cartésiens, etc. Sur le pool: SELECT * FROM object_003_xyz AS o1, object_003_xyz AS o2 WHERE o1.objectid o2.objectid AND ... Time: 2738.217 ms Sur le master (via FDW): SELECT * FROM master_object_003_xyz AS o1, master_object_003_xyz AS o2 WHERE o1.objectid o2.objectid AND ... Time: 130843.931 ms 50x plus lent avec FDW ! E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 21 / 28
  22. 22. Planification des Requêtes Postgres FDW FDW: Conclusion I FDW: Mauvaises performances pour les tables distantes I ) Nous avons décidé d’utiliser FDW seulement pour l’accès aux données à distance. I ) Nous allons contourner les problèmes rencontrés avec FDW en construisant notre propre plan d’exécution distribué. E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 22 / 28
  23. 23. Planification des Requêtes Plan d’exécution Plan de l’exposé 1 Introduction 2 Système de Médiation Architecture Intégration de données 3 Gestion des Requêtes Spatiales Description Commutativité Jointure spatiale 4 Planification des Requêtes Postgres FDW Plan d’exécution E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 23 / 28
  24. 24. Planification des Requêtes Plan d’exécution Plan d’exécution distribué I Trouver les sous-requêtes qui peuvent être exécutées séparement. I Stocker les résultats dans une table temporaire sur le pool I Exporter cette table de résultats sur le master à la volée I nécessite de déterminer les types I Remplacer les sous-requêtes par ces tables I Ce qu’il reste à faire: I Il faut renommer les colonnes qui partagent le même nom I Il faut donner un nom aux colonnes anonymes (exemple: appels de fonctions) E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 24 / 28
  25. 25. Planification des Requêtes Plan d’exécution Identifier les sous-requêtes externes Definition (sous-requête externe) Une sous-requête est dite externe si il est possible de l’exécuter séparement. Notre planificateur reconnait si une sous-requête est externe ssi: I Elle n’utilise que des tables provenant d’un seul pool (ou du master) I Elle ne fait pas réference à des attributs en dehors de la sous-requête SELECT * FROM Object O1 WHERE (SELECT count(*) FROM Source S WHERE O1.objectid = S.objectid) 100 ; E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 25 / 28
  26. 26. Planification des Requêtes Plan d’exécution Plan d’exécution I Nous recherchons dans la requête d’origine les requêtes externes maximales. I Chaque sous-requête externe est remplacée par une table de résultats I Nous créons un plan d’exécution à partir de ces sous-requêtes externes. I Ce plan est exécuté en parallèle à partir de sa description (structure de données) E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 26 / 28
  27. 27. Planification des Requêtes Plan d’exécution Résultats (PT12 sur une seule machine avec 4 pools) Requête Temps avec FDW Temps sans FDW Perf_Q3_crossmatch 21350.12 s 8545.08 s crossmatch_query - 6320.7 s Query022_crossmatch - 124.86 s E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 27 / 28
  28. 28. Planification des Requêtes Plan d’exécution Annexe -- Perf_Q3_crossmatch SELECT S1.objectId AS s1, S2.objectId AS s2 FROM Object S1, Object S2 CROSSMATCH (S1, ra_PS, decl_PS) AND (S2, ra_PS, decl_PS) WITH RADIUS .002778 WHERE S1.gFlux_PS 0. AND S1.rFlux_PS 0. AND S1.iFlux_PS 0. AND S1.zFlux_PS 0. AND S1.objectId S2.objectId AND fluxToAbMag(S1.gFlux_PS) - fluxToAbMag(S1.rFlux_PS) 0.7 AND fluxToAbMag(S1.rFlux_PS) - fluxToAbMag(S1.iFlux_PS) 0.4 AND fluxToAbMag(S1.iFlux_PS) - fluxToAbMag(S1.zFlux_PS) 0.4 ; -- crossmatch_query SELECT O.objectid as oid, S.objectid as soid FROM Object O, Source S CROSSMATCH (O, ra_PS, decl_PS) AND (S, ra, decl) WITH RADIUS 0.0003 WHERE O.objectid S.objectid ; -- Query022_crossmatch SELECT o1.objectId AS objId1, o2.objectId AS objId2 FROM Object o1, Object o2 CROSSMATCH (o1, ra_PS, decl_PS) AND (o2, ra_PS, decl_PS) WITH RADIUS 0.005 WHERE o1.ra_PS BETWEEN 0.5 AND 1.2 AND o1.decl_PS BETWEEN 2.8 AND 3.7 AND o1.objectId o2.objectId ; E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 28 / 28

×