PetaSky Groupe 1 – Gestion de données 23/10/2012 Les besoins du projet LSST • Pouvoir évaluer aussi bien des requêtes simples que des requêtes complexes • Possibilité d’accéder à des objets en utilisant des indexes ou en procédant à un parcours (scan) complet des grosses tables (>> 1 Pétaoctet) • Le temps total d'exécution varie de quelques secondes à quelques jours selon les requêtes QSERV a été développé parce que il n’existe aucun système, gratuit et libre (open source), capable d’assurer les besoins du projet LSST 23/10/2012 PetaSky G1- gestion de données 2 Données LSST • Les données Table Taille #enregistrements #colonnes (arité) Object 109 TB 38 B 470 Moving Object 5 GB 6M 100 Source 3.6 PB 5T 125 Forced Source 1.1 PB 32 T 7 • Dernière version de données publiées : PT1.1 – Données simulées – 2 relations: Object et source • Object: 227 attributs, ~5 Go • Source: 92 attributs, ~85 Go 23/10/2012 PetaSky G1- gestion de données 3 Type de Requêtes LSST(1/2) 1. Petites (quelques seconds ) Exemple: Récupérer tout type d'information sur un seul objet (identifié par un objectId). SELECT * FROM Object JOIN Source USING (objectId) WHERE objectId = 293848594; 2. Moyennes (environ 1 minute) Exemple: Récupérer n'importe quel type d'information sur un groupe d'objets dans une petite zone spatiale SELECT * FROM Object WHERE qserv_areaSpec_circle(1.0, 35.0, 5.0/60); 3. Coûteuses (environ 1 heure) Exemple: Analyser tous les objets et appliquer un filtre sur un certain nombre d'attributs SELECT COUNT(*), MAX(scisql_fluxToAbMag(rFluxGaussian)) FROM Object WHERE rNumObs >= 5; 23/10/2012 PetaSky G1- gestion de données 4 Type des requêtes LSST(2/2) 4. Très coûteuses (environ 1 jour) Exemple: L'analyse des courbes de lumière à travers une grande zone spatiale SELECT O.objectId, myFunction(S.taiMidPoint, S.psfFlux) FROM Object AS O JOIN Source AS S USING (objectId) WHERE O.varProb > 0.75 GROUP BY O.objectId; 5. Impossibles Exemple: Une simple opération de tri sur tous les objets • 10 Peta => 6 h et 27 min avec 8000 machines (google research) • LSST est équipé de seulement 150 machines SELECT * FROM Object ORDER BY rGaussianFlux DESC • Liste complète des requêtes: http://dev.lsstcorp.org/trac/wiki/dbQueries • Défis LSST : • ½ million de requêtes par jour • ~50 requêtes simples et ~20 requêtes complexes à n’importe quel moment 23/10/2012 PetaSky G1- gestion de données 5 Solution LSST (1/2) • QSERV (0.3.0rc6) repose sur une architecture comportant un serveur central et plusieurs clients User query 23/10/2012 Master Mysql Worker Worker Worker Mysql Mysql Mysql PetaSky G1- gestion de données 6 Solution LSST (2/2) • Nous aurons un accès à qserv-0.3.0rc6 dès que l’installation sera validée par: – Fabrice Jammes et Emmanuel Medernach • Actuellement, un problème d’exécution de requêtes: • contacts LSST : – Douglas Smith et Daniel Wang: SLAC, Stanford 23/10/2012 PetaSky G1- gestion de données 7 Les alternatives à QSERV Solution commentaire Hadoop et Hive Pour les requêtes simples ça prend beaucoup de temps Dryad Les données circulent entre les nœuds lorsqu’ils en ont besoin LINQ C’est difficile d’implémenter une interface de requêtes DATAllengro Matériel couteux dédié pour le déploiement DB2 Ne support que les données XML Greenplum Pas de licence libre GridSQL Pas de scan en parallèle, partitionnement limité au hachage InfiniDB Pas de version stable pour le moment Oracle Pas de licence libre Teradata coût très élevé Vertica Auto-jointure ( Self-join) n’est pas supportée HadoopDB Peut être une alternative à QSERV [Rapport interne LSST] Evaluation of Existing Dtabase(-like) Solutions 23/10/2012 PetaSky G1- gestion de données 8 Préparation de l'environnement • PT 1.1 – Groupe LSST @ IN2P3 – La machine LIRIS-BD-Exp (2.5To de disque, 14Go de RAM) dotée d’un serveur Mysql • Environnement: – Un réseau virtuel avec 3 machines pour simuler un environnement “cluster “ 23/10/2012 PetaSky G1- gestion de données 9 Travail en cours (1/2) • Solution basée sur Hadoop – HIVE (Facebook) • • • • 23/10/2012 2,5 Po de données des utilisateurs de facebook Générer des taches map/reduce à partir de requêtes SQL Utilise HDFS Les relations sont stockées sous forme de couples clévaleur PetaSky G1- gestion de données 10 Travail en cours (2/2) • Hadoop based solutions – HadoopDB (Université de Yale) • • • • • • • Modèle relationnel Même architecture que QSERV Les clients stockent les données avec postgresql Utilise SQL comme interface de requêtes HIVE est utilisé pour génère les taches map/reduce A été testé avec le benchmark TPC-H (3Tb) N’importe quel SGBD (ex, vectorwise, c-store) peut être intégré comme un nœud de stockage • permet un passage à l'échelle jusqu’à 2000 nœuds 23/10/2012 PetaSky G1- gestion de données 11 Quelques pistes • Technique d’indexation dynamique – 5 attributs => 12 indexes – 227 attributs => >> 1 milliard d’indexes pour répondre efficacement à n’importe quel type de requêtes • Technique de stockage de données – Row, column, tree ,… • Techniques de partitionnement et duplication – Très utiles pour paralléliser le traitement des requêtes – Minimisation de la communication entre nœuds 23/10/2012 PetaSky G1- gestion de données 12 Calendrier • Actuellement : – Préparation de l’environnement et test de quelques outils pour la gestion des données LSST – Hive, HadoopDB et QSERV • D’ici le 1/12/2012 – Déploiement des trois solutions sur un vrai cluster • 1er semestre 2013 – Stockage – Indexation dynamique – Partitionnement et duplication de données 23/10/2012 PetaSky G1- gestion de données 13