CC préliminaire - Forge Clermont Université
publicité
Document de préparation Big data avec PostgreSQL 18/06/2015 Auteurs : Bastien Doreau (LIMOS/CNRS), Emmanuel Delage(LIMOS/CNRS), Relu par : Benoît Eymard (Limagrain) PLAN I) II) III) IV) V) Introduction Interface de benchmark Configuration de test Cahier des charges Perspectives I) Introduction Les SGBDR (Systèmes de Gestion de Bases de Données Relationnelles) traditionnels ne permettent pas de gérer le phénomène du Big data. Les SGBD de type NoSQL sont une solution pour manipuler ce type de données. Nous proposons de réaliser une étude de performances de bases de données PostgreSQL fédérées pour des données NoSQL au moyen d’une interface de gestion de scenarii pour la soumission de requêtes. PostgreSQL est actuellement au quatrième rang des bases de données les plus utilisés tous modèles confondus (http://db-engines.com/en/ranking). Parmi les modèles NoSQL actuels (http://blog.datagraph.org/2010/04/rdf-nosql-diff) PostgreSQL inclut le modèle clé-valeur (avec hstore) et le modèle document (avec JSON et JSONB). Nous souhaitons étudier les performances PostgreSQL sur un jeu de données comparable à celui mise en œuvre par Limagrain avec MongoDB (BSON), dans le but d’initier d’éventuelles collaborations de recherche. Cependant la génération de données type Limagrain n’est pas réalisable en deux mois. C’est pourquoi nous utiliserons une base de données SQL d’analyse pour LSST, le futur télescope implanté au Chili (http://www.lsst.org/lsst/). Cette base sera convertie au format JSON et JSONB. Une étude comparative entre MongoDB et PostgreSQL a été réalisée par EntrepriseDB mais sur un seul serveur : http://fr.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgresoutperforms-mongodb-and-ushers-new-developer-reality. Nous étudierons les performances de PostgreSQL pour des bases de données de documents en mode fédéré (distribué sur un réseau local avec une machine médiateur). Nous orientons donc notre étude sur des requêtes massive en insertion et en lecture en JSONB disponible depuis la version 9.4 de PostgreSQL (actuellement la dernière version). En ce qui concerne les connexions distantes sur Ethernet entre la base de données « médiateur » et les bases de données contenant les données, nous utiliserons SQL/MED et DBLINK. Dans un premier temps nous testerons la lecture d’une requête contenant des documents JSON avec SQL/MED. L’interface de gestion de scenarii doit être conçue de manière simple et adaptable. [Autres études similaires en cours au LIMOS…] II) Interface de benchmark L’interface doit répondre aux critères suivants : Connexion avec PostgreSQL Connexion SSH Portail WEB Adaptatif aux tablettes et smartphones (optionnel) Multiplateforme Utilisation de technologies pérenne L’interface web doit être simple, sûre et adaptable. Après lecture du lien http://blog.jhades.org/the-java-origins-of-angular-js-angular-vs-jsf-vs-gwt/ et au vu des compétences techniques et humaines dont nous disposons, nous retenons une solution basé sur JSF. Spécifications : JSF >=2.2 (inclut jQuery) Java Server Faces est un framework JAVA pour le web orienté composant Genre Langage Environnement de Développement Intégré (EDI) Technologie retenue Java WildFly Description serveur d'applications Java EE Libre Netbeans Management de projet Responsive web JPA ? Maven Bootstrap Tunnel SSH JSch Optionnel Optionnel | Boostrap peut être utilisé dans un composant JSF Note : L’API PrimeFaces est « responsive » mais limité aux grilles. http://blog.primefaces.org/?p=3248 Note : Netbeans (oracle, installé par default sur les postes au limos). Il est possible d’importer un projet d’Eclipse http://docs.oracle.com/cd/E50453_01/doc.80/e50452/create_japps.htm#NBDAG445 Maquette de l’interface graphique : Connexion au médiateur, IP médiateur, nom de la base, nom d’utilisateur, mot de passe, information sur la configuration du serveur Préparation des jeux de données, ensemble 1, ensemble 2… Choix des données Gestion des scenarii, Parametrage (FETCH, SDU, …) Création , suppression, sélection et chargement CRUD, description du scenario insert massif, (update, ) select avec les données choisis et le nombre de répétitions Affichage des resultats, logs et visualisation, sauvegarde des résultats /data/data1 /data/data2 … /scenarii/scenario1/resultat_001 /scenarii/scenario1/resultat_002 /scenarii/scenario1/resultat_003… /scenarii/scenario2… III) Configuration de test [Génération de données d’analyse LSST au format JSON] Environnement de travail : Au LIMOS Le développement s’effectue sur un poste Windows (). A distance (au domicile d’ED) Le développement s’effectue sur un poste Windows. L’IP du domicile d’ED sera sur le VLAN du LIMOS en VPN. Possibilité de tester sur Raspberry Pi 2 (Raspbian) et Tablette Nexus 10 (android) et Linux (Ubuntu) Configuration matériel de test sur serveur « Avatar » : OS : CentOS release 6.3 (Final) Proc : AMD Opteron(TM) Processor 6234 quadri processeurs, 12 coeurs (soit 48 coeurs). Ram : 256 Go. Hyperviseur : Virtualbox version 4.2.4 Creation de 4 VM Ubuntu 14.04 sur avatar (16Go de RAM et 4 cœurs chacune) Taille dynamique max=40,19GB avatar VLAN LIMOS interface web directement sur la machine hôte « avatar » VM données 1 JDBC et SSH VM médiateur DBLINK ou SQL/MED VM données 2 VM données 3 [Tests réseau, switch virtuel https://www.projet-plume.org/fr/fiche/iperf , ifconfig] Travailler sur une machine utilisée par plusieurs utilisateurs… De plus les performances réduites dues à la virtualisation aux niveaux disques Ram Cœurs I) - Cahier des charges Problématique Big data au LIMOS => 1 semaine, Conception de l’interface => 1 semaine, Développement => 6 semaines (chevauchement), Tests de performance => 2 semaines, Analyse des résultats => 1 semaine Rédaction d’une documentation tout au long de l’étude. IV) Perspectives Note : PostgreSQL est largement reconnu pour son comportement stable, proche de Oracle. Mais aussi pour ses possibilités de programmation étendues, directement dans le moteur de la base de données, via PL/pgSQL. Le traitement interne des données peut aussi être couplé à d'autres modules externes compilés dans d'autres langages. glusterFS
