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.
Téléchargement
Explore flashcards