Petasky 13oct2014

PETASKYEtat d’avancement

Emmanuel Medernach

IN2P3, CNRS

13 octobre 2014

E.Medernach (IN2P3, CNRS) Etat d’avancement PETASKY 13 oct 2014 1 / 28

Plan de l’exposé

1 Introduction

2 Système de MédiationArchitectureIntégration de données

3 Gestion des Requêtes SpatialesDescriptionCommutativitéJointure spatiale

4 Planification des RequêtesPostgres FDWPlan d’exécution


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’imagesI ~ 6 Pb de cataloguesI ~ 100 tablesI Evolution des données: en ajout seulement

Table Taille Lignes Colonnes

Object 109 TB 3.8× 1010 470Source 3.6 PB 5.0× 1012 125

I Comment interroger efficacement ces données ?


Système de Médiation Architecture

Plan de l’exposé

1 Introduction






Partitionnement des tables

I Les tables “Object” et “Source” n’existent pas physiquement.I Ces tables sont partitionnées :

Object =⋃i

Objecti

∀i 6= 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.



Architecture

Le rôle du médiateur est de fournir à l’utilisateur une vue unifiéedes tables et de réécrire les requêtes en conséquence.

PoolObject_001 Source_001

Object_002 Source_002

PoolObject_003 Source_003

Object_004 Source_004

Médiateur

Filter

SQL

SQL

SQL

Orchestration de bases de données.


Système de Médiation Intégration de données

Plan de l’exposé

1 Introduction






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éesI Fournir une vue unifiée de ces donnéesI Etablir des correspondances entre les tables (locales et distantes)

I Le standard SQLMED permet d’interroger des tables à distancecomme des tables locales (Postgres Foreign Data Wrapper).

I Mais cela ne suffit pas: il faut mettre en place des transformationssyntaxiques:

I pour gérer les tables virtuelles comme Object ou SourceI pour gérer leur jointureI pour réécrire les contraintes spatialesI etc.



Approche “Global-As-View”

Object =>( SELECT * FROM Object_000

UNION ALL SELECT * FROM Object_001UNION ALL SELECT * FROM Object_002UNION ALL SELECT * FROM Object_003 )AS Object

I Les tables partitionnées (Object, Source) sont remplacées par leursdéfinitions (UNION des partitions)

I Des transformations syntaxiques sont appliquées à la requête obtenue:I Transformations des jointures Object/Source en jointures localesI Déplacement des prédicats sur les partitionsI etc.


Gestion des Requêtes Spatiales Description

Plan de l’exposé

1 Introduction





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 constantI Voisinage: p1 et p2 variables, rayon constant


Gestion des Requêtes Spatiales Commutativité

Plan de l’exposé

1 Introduction






Commutativité de l’UNION

I Si un opérateur Op commute avec l’UNION alors il suffit de distribuercet 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 avecl’UNION: c’est l’UNION des recherches sur chaque partition.

I De même avec les recherches dans un cône.



Non-Commutativité et conséquences

I Et si un opérateur ne commute pas avec l’UNION ?

Op ◦ UNIONdef6= UNION ◦ Op

I Par exemple, l’opérateur de “jointure spatiale” ("spatial join") necommute pas avec l’UNION (effets de bords): il demande donc untraitement à part.


Gestion des Requêtes Spatiales Jointure spatiale

Plan de l’exposé

1 Introduction






Jointure spatiale: extension syntaxique

SELECT O.objectid as oid,S.sourceid as sid

FROM Object O, Source SCROSSMATCH (O, ra_PS, decl_PS)

AND (S, ra, decl)WITH RADIUS 0.0003WHERE O.objectid <> S.objectid ;

I ⇐⇒ WHERE distance(p1, p2) ≤ rayonI Extension de SQL: CROSSMATCH, permet d’identifier

immédiatement une jointure spatiale et d’appliquer la transformationadaptée (transformation globale de la requête).

I Problème: Comment implémenter efficacement la jointurespatiale sur N pools ?



Exemple: Jointure spatiale entre T1 et T2

Table T1 Table T2

Table T1 Table T2



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


Planification des Requêtes Postgres FDW

Plan de l’exposé

1 Introduction






Problèmes avec FDW

I Pas d’appels de fonctions à distanceI 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_000WHERE 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_000WHERE q3c_radial_query(ra_PS, decl_PS, 1.3, 3.4, .2) ;...Time: 130843.931 ms

1000x plus lent avec 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 o2WHERE o1.objectid <> o2.objectidAND ...

Time: 2738.217 ms

Sur le master (via FDW):SELECT *FROM master_object_003_xyz AS o1,

master_object_003_xyz AS o2WHERE o1.objectid <> o2.objectidAND ...

Time: 130843.931 ms

50x plus lent avec FDW !



FDW: Conclusion

I FDW: Mauvaises performances pour les tables distantesI ⇒ 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é.


Planification des Requêtes Plan d’exécution

Plan de l’exposé

1 Introduction






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 poolI Exporter cette table de résultats sur le master à la volée

I nécessite de déterminer les typesI Remplacer les sous-requêtes par ces tablesI Ce qu’il reste à faire:

I Il faut renommer les colonnes qui partagent le même nomI Il faut donner un nom aux colonnes anonymes (exemple: appels de

fonctions)



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écutersé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 O1WHERE (SELECT count(*) FROM Source S

WHERE O1.objectid = S.objectid) > 100 ;



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 dedonnées)



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 scrossmatch_query - 6320.7 sQuery022_crossmatch - 124.86 s



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 .002778WHERE S1.gFlux_PS > 0.AND S1.rFlux_PS > 0.AND S1.iFlux_PS > 0.AND S1.zFlux_PS > 0.AND S1.objectId <> S2.objectIdAND fluxToAbMag(S1.gFlux_PS)

- fluxToAbMag(S1.rFlux_PS) < 0.7AND fluxToAbMag(S1.rFlux_PS)

- fluxToAbMag(S1.iFlux_PS) > 0.4AND fluxToAbMag(S1.iFlux_PS)

- fluxToAbMag(S1.zFlux_PS) > 0.4 ;

-- crossmatch_query

SELECT O.objectid as oid, S.objectid as soidFROM Object O, Source SCROSSMATCH (O, ra_PS, decl_PS)

AND (S, ra, decl)WITH RADIUS 0.0003WHERE 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.005WHERE o1.ra_PS BETWEEN 0.5 AND 1.2AND o1.decl_PS BETWEEN 2.8 AND 3.7AND o1.objectId <> o2.objectId ;


Petasky 13oct2014

Science

Transcript of Petasky 13oct2014