Projet BDBenchmark - Forge Clermont Université

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.