Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Petasky 13oct2014

198 views

Published on

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

Published in: Science
  • Be the first to comment

  • Be the first to like this

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

×