Projet BDBenchmark - Forge Clermont Université
publicité
Projet BDBenchmark Auteurs : Bastien Doreau (LIMOS/CNRS), Emmanuel Delage (LIMOS/CNRS) Date : 24 aout 2015 Remerciements : Merci à M. Farouk Toumani, directeur du LIMOS, de nous avoir permis de réaliser ce projet dans les meilleurs conditions. Lors de nos échanges, il a présenté différentes orientations possibles de manière pertinente. Merci à M. Zhang Chao pour nous avoir transmis des données LSST, pour avoir présenté l’intérêt de ses travaux et pour l’inspiration qu’il nous a donné pour la construction de notre infrastructure des bases de données distribuées. Merci à M. Abdelslem Belghoul pour son aisance à présenter ses travaux de recherche d’une façon simple et ses besoins en visualisation pour l’analyse. Cela nous a également permis de préparer l’adaptation de notre interface à d’autres cas de bases de données distribuées. Merci à M. Benoît Eymard, Ingénieur Limagrain, de nous avoir présenté la problématique du Bigdata à Limagrain R&D et de nous avoir conseillé sur les technologies émergentes et dans les spécifications. Merci à Mme Marie Pailloux d’avoir échanger sur le projet BreedWheat, ce qui est de bon augure pour initier de nouvelles collaborations. Introduction : L’objectif du projet est la conception d’une interface de tests de la performance de bases de données distribuées de type « Bigdata ». Cette interface, appelée « BigDataBenchmark » (BDBenchmark) doit être accessible par tous les utilisateurs enregistrés et leur permettre de tester leurs bases de données distribuées. L’interface sera mise en œuvre dans un serveur Web pour être accessible avec le navigateur Web de l’utilisateur. Il s’agit donc d’un portail Web d’accès à des bases de données distribuées. De plus, le portail Web sera adaptatif aux tablettes et smartphones. BDBenchmark permet de s’identifier, de connecter un ensemble de bases de données, d’effectuer des requêtes multithread sur ces bases, d’enregistrer le résultat de ces requêtes sous la forme de scénario, d’analyser plusieurs scénarii par croisement et de visualiser le résultat dans un graphique. Au LIMOS, le serveur de machines virtuelles « avatar » permet à un utilisateur de se construire une infrastructure de bases de données distribuées. Après une étude des technologies existantes, notre choix s’est arrêté sur JAVA (cf : Doc technique) et les outils qui gravitent autour. BDBenchmark accède à « avatar » en SSH (le port 22 est ouvert sur cette machine) à l’aide de JSCH. Pour le moment, il n’est possible que de gérer que des bases de données PostgreSQL car seul le driver JDBC PostgreSQL a été mis en œuvre. L’infrastructure de bases de données de tests est constituée de 3 machines virtuelles (VM ) toutes accessibles indépendamment. Une de ces VM, appelée « VM-Mediateur », peut être utilisée comme médiateur car une de ses bases, appelée « lsst_med », contient des liaisons DBLINK et SQL/MED. Il est possible de reconstruire son propre environnement de tests à l’aide de documentations d’installation systèmes (cf : docsys), d’installation de bases de données PostgreSQL (cf : docbases), d’un algorithme de conversion (cf : algo) et du remplissage de ces bases de données (cf : remplissage). Cette dernière documentation contient également un récapitulatif des différentes bases de données (SQL, JSON, JSONB) ainsi que l’utilisation d’indexes, de table lointaines SQL/MED et de vues DBLINK. Les données correspondent à 4012341 enregistrements d’objets (célestes ?) observables par le futur télescope LSST. Chaque objet peut être constitué d’environ 250 informations toutes numériques. Les tests d’analyse reposent sur l’étude de la performance des accès à ces données, dans l’architecture de bases de données décrite précédemment. Un ensemble de tests d’analyse a été réalisé au moyen des graphiques générés par BDBenchmark. Dans cette synthèse de projet, nous présentons un ensemble de tests d’analyse de la performance basé sur l’infrastructure choisie, et les résultats associés. Finalement, nous décrirons les perspectives d’évolution de l’interface BDBenchmark. Résultats : Test 1 : Description : Le « test1 » est composé d’une sélection de 6 scénarii. Les 3 1er scenarii interrogent les tables t_obj_half1 et t_obj_half2 de la base lsst (data json), les 3 scenarii suivant interrogent les tables t_obj_half1 et t_obj_half2 de la base lsst_b (data jsonb). Chaque scénario est composé de 2 requêtes, formulées au moyen de BDB : Thread 1 sur “DonneesA”: SELECT max(cast(data->>'3' as float)) FROM t_obj_half1 Thread 2 sur “DonneesB”: SELECT max(cast(data->>'3' as float)) FROM t_obj_half2 Analyse : Les requêtes de calcul d’un maximum sont plus rapides en JSONB qu’en JSON (speedup : 7.5). En JSONB, nous constatons un « effet de cache » après la première exécution de la requête (speedup : 2) Test 2 : Description : Le « test2 » est composé d’une sélection de 16 scénarii. - 4 scenarii sur la table t_obj_half1 de la base lsst_b (JSONB) Un index « GIN » (global) a été créé sur cette table. Thread 1 sur “VM-Mediateur”: SELECT cast(data->>'3' as real) FROM t_obj_half1 where data->>'1' ='430222579090485' - 4 scenarii sur la table t_obj_half1_id de la base lsst_b (JSONBid) Thread 1 sur “VM-Mediateur”: SELECT cast(data->>'3' as real) FROM t_obj_half1_id where id=433314955551226 - 4 scenarii sur la table t_obj_half1 de la base lsst (JSON) Un index a été crée sur cette table pour l’élément data->>'1'. Thread 1 sur “VM-Mediateur”: SELECT cast(data->>'3' as real) FROM t_obj_half1 where data->>'1' ='430222579090485' - 4 scenarii sur la table t_obj_half1_id de la base lsst (JSONid) Thread 1 sur “VM-Mediateur”: SELECT cast(data->>'3' as real) FROM t_obj_half1_id where id=433314955551226 Analyse : Nous constatons un « effet de cache » systématique après la première exécution de la requête. Passée la période de « cache », nous pouvons constater que le temps le plus intéressant se retrouve pour le cas JSON avec un index. (temps ~600 ms) Ensuite, viennent les cas JSONBid et JSONid pour des temps respectifs de ~2550 ms et ~3000 ms. Puis vient le cas JSONB avec un temps de ~4700 ms. Test3: Description : Le « test3 » est composé d’une sélection de 12 scénarii. - 4 scenarii sur la table t_obj_half1 de la base lsst (JSON) Un index a été créé sur cette table pour l’élément data->>'1'. Thread 1 sur “VM-Mediateur”: SELECT cast(data->>'3' as real) FROM t_obj_half1 where data->>'1' ='430222579090485' - 4 scenarii sur la table t_obj_half1_id de la base lsst (JSONid) Thread 1 sur “VM-Mediateur”: SELECT cast(data->>'3' as real) FROM t_obj_half1_id where id=433314955551226 - 4 scenarii sur la table t_obj_half1 de la base lsst (JSONBl) T_link_lsstb_h1 est une vue d’une requête DBLINK sur la machine « DonneesA » qui calcule le maximum pour data->>'3'. Idem avec T_link_lsstb_h2 sur la machine « DonneesB ». Thread 1 sur “VM-Mediateur”: SELECT * FROM t_link_lsstb_h1 Thread 2 sur “VM-Mediateur”: SELECT * FROM t_link_lsstb_h2 Analyse: L’utilisation d’un médiateur n’est pas pertinente pour ces requêtes sachant qu’il n’y a pas d’index sur les données A et B. Analyse des tests : Les résultats dépendent de l’architecture matérielle et logicielle. Plusieurs critères sont à prendre en considération lors de l’analyse : - L’état et la configuration de la machine « avatar » : Le temps des requêtes dépend du nombre d’utilisateurs étant donné les ressources de mémoire RAM, de processeurs et d’entrées/sorties (réseau, disques durs, RAM) utilisées au niveau système. - L’état et la configuration de la machine serveur sur lequel est exécuté BDBenchmark pour les mêmes raisons. De plus, l’interface nécessite un certain temps de traitement pour la gestion de requêtes en fonction des performances de la machine. - L’état du réseau entre « avatar » et le serveur BDBenchmark. Un test a été effectué avec une connexion VPN à environ 15 km du LIMOS. Nous avons constaté une variabilité des résultats difficile à anticiper. Par exemple une requête exécutée en environ 600 millisecondes (temps JAVA) à travers le VPN a été exécutée au LIMOS : QUERY PLAN Index Scan using index_for_id_in_json on t_obj_half1 (cost=0.43..8.46 rows=1 width=32) (actual time=0.189..0.198 rows=1 loops=1) Index Cond: ((data ->> '1'::text) = '430222579090485'::text) Planning time: 0.846 ms Execution time: 0.318 ms time : 6 ms nb col : 1.0 nb rows : 4 Nous constatons que le temps d’exécution est divisé par 100 (temps JAVA) dans ce cas. En réalité, le SGBD PostgreSQL exécute la requête en 0.318 millisecondes. L’exécution du traitement de l’interface est donc d’environ 5 millisecondes. Des limitations, propres à une interface web, sont à considérer : - Les requêtes longues ne peuvent excéder 30 minutes à priori en raison du timeout du serveur web. Les requêtes qui induisent une réponse longue sur un grand nombre de données (ex : select *) génèrent une exception java (java.lang.OutOfMemoryError) qui fait tomber le serveur. Perspectives: Améliorations techniques : -Affichage des messages (Informations sur la persistance des données/ Messages d’erreur SSH, SQL, …) -Tri des scénarios avec la librairie Primefaces -Rajouter des champs sur les tables de la base bdbench (Scenario -> ajouter le champ date) -Ajax : bouton d’arrêt de la requête en cours et message « en cours de traitement… » -Répétition d’un scénario ‘N’ fois avec calcul d’un temps moyen -Création d’une page d’administration des utilisateurs de BDBenchmark -Récupérer le temps du SGBD (par Explain Analyse pour PostgreSQL) pour remplacer le temps de la requête en JAVA -Organisation d’un import et export de scénarios en vue d’échanges de résultats entre utilisateurs -Amélioration de la fonction Debug (pouvoir enchainer les commandes shell dans un prompt) -Amélioration de l’ergonomie (taille des colonnes, …) -Intégration du format de fichier SVG pour l’affichage de résultats en 3D vectoriel -Amélioration de la fonction d’import de fichier SQL Adaptation multi-projets : -Intégrer une connexion JDBC Oracle pour le cas d’utilisation d’Abdelslem Belghoul -Tester le cas d’utilisation de Zhang Chao -Etude comparative avec MongoDB, intégrer une connexion JDBC MongoDB pour le cas d’utilisation de Benoît Eymard -Appréhender le cas d’utilisation de Marie Pailloux -Intégrer des données PostGIS pour le cas d’étude d’Emmanuel Delage.
