https://air.imag.fr/api.php?action=feedcontributions&user=Malek-Hadi.Mammar&feedformat=atomair - User contributions [en]2024-03-29T13:44:46ZUser contributionsMediaWiki 1.35.13https://air.imag.fr/index.php?title=ECOM_RICM5_Groupe5_2015&diff=30202ECOM RICM5 Groupe5 20152016-07-05T22:08:55Z<p>Malek-Hadi.Mammar: /* Documents */</p>
<hr />
<div>Bienvenue sur la fiche de suivi du projet ''Restauration personnalisée en ligne'' .<br />
<br />
Un projet de site de E-commerce dans lequel nous allons nous initier à la programmation J2EE.<br />
<br />
Nous sommes le groupe 5 de la promotion RICM5 - 2015/2016. <br />
<br />
== Présentation du projet ==<br />
<br />
Le site porte sur un service de restauration personnalisée. <br />
Deux modes de fonctionnement vous sont possibles : <br />
<br />
* des formules sont proposées par des artisans restaurateurs, sur lesquelles il vous est possible d’imposer des contraintes (la cuisson,...) selon vos affinités gustative, si l’artisan le propose.<br />
<br />
* des thèmes culinaires sont proposés par des artisans restaurateurs qui se charge de répondre à votre demande de plat dans un temps imparti. Il est à noter que l’artisan peut librement accepter ou refuser le traitement de votre demande dans la mesure des stocks disponibles. Dans le cas d’un refus une proposition peut vous être faite par l’artisan.<br />
<br />
==L'équipe==<br />
<br />
* [[User:Robin.Eudes|Robin Eudes]] : '''''Chef de projet'''''<br />
* [[User:Malek-Hadi.Mammar|Malek Mammar]] : '''''Scrum Master'''''<br />
* [[User:Zhengmeng.Zhang|Zhang Zhengmeng]] : '''''Développeur'''''<br />
<br />
== Documents ==<br />
* [http://air.imag.fr/index.php/Benchmark_ECOM_2015_GRP5 Document Évaluation Système - Benchmark]<br />
* [http://air.imag.fr/index.php/File:DCS_gp5.pdf Document Conception Système]<br />
* [http://air.imag.fr/index.php/SCS_ECOM_2015_GRP5 Schéma SCS]<br />
* [http://air.imag.fr/index.php/SONAR_ECOM_2015_GRP5 Audit SONAR (CI)]<br />
* [http://air.imag.fr/index.php/SRS_ECOM_2015_GRP5 Document SRS]<br />
* [http://air.imag.fr/index.php/File:Chartegraphique.pdf Charte Graphique]<br />
* [http://air.imag.fr/index.php/File:Spécifications_ecom_grp5.pdf Spécifications - Trace de travail (Sprint 1)], Conception "générale" du projet (livrable 08/09)<br />
* [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform Questionnaire] (étude des besoins)<br />
* [http://air.imag.fr/index.php/File:ECOM-GRP5-Conception.pdf Trace de travail (Sprint 2)], Conception IHM (livrable 06/10)<br />
<br />
== Liens ==<br />
* [https://github.com/EudesRobin/ecom Dépôt Github] (dépôt actuellement privé).<br />
* [https://waffle.io/EudesRobin/ecom Board Waffle.io - ECOM GRP5] (le dépot Github étant privé, cette board requiert la même authentification)<br />
<br />
== Etude du marché ==<br />
Suite à la diffusion de notre [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform questionnaire], nous avons obtenu 26 réponses à l'heure actuelle. Bien que cet échantillon de réponse soit limité, nous l'avons jugé suffisamment représentatif pour baser nos principaux axes de travail en adéquation avec les réponses reçues. <br />
<br />
=== Utilisateurs cibles ===<br />
<br />
[[File:Users_cible.png]]<br />
<br />
Nous ciblons principalement les étudiants, ou les jeunes salariés.<br />
<br />
=== Besoins utilisateurs ===<br />
<br />
[[File:Users_need1.png]]<br />
[[File:Uses_need2.png]]<br />
[[File:Uses_need3.png]]<br />
<br />
Le moyen principal de paiement serait la carte bancaire, cependant il serait souhaitable que notre système accepte différents modules de paiements tel que [https://www.paypal.com/fr/home Paypal], [http://www.izly.fr/ Izly]. La base d'utilisateur est par ailleurs favorable à un système de fidélité, récompensant le client d'une commande offerte après une certaine quantité d'achats à définir. Le site doit également donner accès à un système de notation sur les formules ou plats proposés par les restaurateurs, l'avis des autres clients étant un critère de choix important.<br />
<br />
=== Etude de la concurrence ===<br />
<br />
La concurrence est nombreuse, et souvent spécialisée dans un domaine culinaire. En voici quelques exemples :<br />
<br />
* [https://www.foodpanda.com/ Foodpanda] : Le site nous proposera d'abord de choisir un restaurant, puis le menu que l'ont souhaite commander, avant de finaliser la commande (paiement). Cependant, on peut également effectuer une recherche par type de cuisine,et donc trouver les restaurants servant ce type de plats, pour revenir dans le premier schéma évoqué (choix restaurant -> choix plat -> paiement). La recherche par type de cuisine est pas mise en avant. Le site reste malgré tout assez clair, bien que chargé. Une application mobile est proposée par ailleurs (Android/iOS/Windows Phone).<br />
<br />
* [https://www.sushishop.fr/ SushiShop] : Thème "sombre" pour le site, on a un accès direct aux "boxes" (menus sushis), ou à la carte détaillée. Le menu donnant accès à la carte nous offre un "diaporama" des plats servis, très agréable visuellement. Le panier sera affiché dans un menu sur la droite uniquement une fois que nous avons sélectionné un plat. Un espace de connexion vers son compte est disponible en haut à droite. Logo discret sur le coin supérieur gauche.<br />
<br />
=== Plateformes d'utilisation ===<br />
<br />
[[File:Uses_plat.png]]<br />
<br />
La mise en forme de notre site devra être capable de supporter différents supports, PC et mobiles principalement (responsive design).<br />
<br />
== Définition des services rendus ==<br />
=== Exigences ===<br />
==== Exigences fonctionnelles ====<br />
* Tâches prioritaires<br />
** Gestion d'une session sécurisée<br />
** Acteur client : Effectuer une commande<br />
** Acteur client : Gérer son panier<br />
** Acteur artisan : Gérer son catalogue<br />
<br />
* Tâches secondaires<br />
** Acteur client : Effectuer un appel d'offre<br />
** Acteur artisan : Répondre à un appel d'offre<br />
<br />
==== Exigences non fonctionnelles ====<br />
* [https://fr.wikipedia.org/wiki/Propri%C3%A9t%C3%A9s_ACID Propriétés ACID] sur les transactions (en particulier le paiement)<br />
* Utilisabilité , selon [http://www.ergolab.net/articles/criteres-ergonomiques-1.php Les critères ergonomiques de Bastien & Scapin]<br />
* Gestion fine de l'utilisation de HTTPS<br />
* Résistance du système à la montée en charge (Temps de service constant)<br />
* Réduire au minimum le parcours de paiement<br />
* Portabilité (responsive design) PC, mobiles.<br />
<br />
== Conception du système ==<br />
=== Arbres des tâches ===<br />
====Tâches prioritaires====<br />
<br />
[[File:Arbre_taches_client_faire_une_commande.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_gerer_catalogue.png]]<br />
<br />
====Tâches secondaires====<br />
<br />
[[File:Arbre_taches_client_faire_un_appel_d_offre.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_repondre_appel_d_offre.png]]<br />
<br />
=== Diagramme de contexte ===<br />
[[File:Diagramme_de_contexte_ecom5.png]]<br />
<br />
=== Base de données ===<br />
[[File:UML_-_DataBase.png]]<br />
<br />
Vous remarquerez, qu'il n'y a pas de table "Panier" ou "Historique", car nous considérons que ces données sont à sauvegarder en session.<br />
<br />
=== IHM abstraites ===<br />
==== Faire une commande (client) ====<br />
Priorité : forte<br />
<br />
<br />
La tâche "Faire une commande" pour l'acteur Client se décomposer en ces 2 IHM abstraites : '''Consulter la carte''' et '''Consulter son panier''' .<br />
<br />
[[File:Client_-_consulter_carte_-_IHM_abstraite.png]]<br />
<br />
[[File:IHM_abstraite_-_consulter_panier_(client).png]]<br />
<br />
==== Gérer son catalogue (artisan) ====<br />
Priorité : forte<br />
<br />
<br />
[[File:IHM_abstraite_-_Gestion_catalogue_artisan.png]]<br />
<br />
=== Maquettes du site ===<br />
<br />
==== Maquette Accueil du site ====<br />
[[File:Maquette_carte.png]]<br />
<br />
==== Maquette page Formule ====<br />
[[File:Maquette_formule_(1).png]]<br />
<br />
== Planification du projet - SCRUM ==<br />
<br />
SCRUM est la méthode de travail préconisée, bien que non adaptée à la nature exploratoire du projet. Nous tacherons néanmoins de planifier au mieux.<br />
<br />
Sprint planning<br />
---------------<br />
<br />
==== Sprint 1 : 15/09/2015 - 28/09/2015 ====<br />
* Choix d'un sujet de commerce en ligne<br />
* Prise en main des outils de développement J2EE<br />
* Réalisation d'un questionnaire <br />
** ciblage du marché<br />
** étude de marché sur la concurrence<br />
** identification des besoins utilisateur<br />
<br />
==== Sprint 2 : 29/09/2015 - 12/10/2015 ====<br />
* Réalisation d'un arbre des tâches<br />
* Conception d'une architecture générale<br />
* Publication des documents de conception IHM sur air.imag.fr<br />
* Analyse des résultats du questionnaire<br />
<br />
==== Sprint 3 : 13/10/2015 - 26/10/2015 ====<br />
* Mise en forme des arbres des tâches, IHM abstraites.<br />
* Analyse de la concurrence<br />
* Réalisation de la maquette<br />
* Conception Architecture système<br />
* Préparation de la soutenance "Conception" GL/IHM/Système<br />
<br />
==== Sprint 4 : 27/10/2015 - 09/11/2015 ====<br />
* Mise en place client d'administration lourd<br />
* Session bean Client,Artisan,Product : première version<br />
* Recherches concernant la mise en place d'une API REST<br />
* Recherches concernant la gestion de l'authentification via l'API REST<br />
* Mise en place d'une page d'index pour la webapp utilisant bootstrap, angularJS<br />
* Modification de quelques Entity bean (champs inutiles, etc )<br />
<br />
==== Sprint 5 : 10/11/2015 - 23/11/2015 ====<br />
* Session beans Formule, Orders première version<br />
* Autre sessions beans : version 2 , révision des prototypes, ajout de fonctionnalités<br />
* API REST sans authentification v1 opérationnelle pour Product, Artisan, Client ( incomplète , cependant )<br />
* Modification de certaines propriétés des entity pour empêcher des incohérences/dysfonctionnements<br />
* Ajout fonctions pour modifier un champ unique de Product (icon_url,description,isAvailable,price,title)<br />
<br />
==== Sprint 6 : 24/11/2015 - 07/12/2015 ====<br />
* Finalisation Authentification API + diverses fonctionnalités<br />
* Finalisation des divers Session beans (client,artisan,formule,product,orders)<br />
* Ajout newsletter hebdomadaire , mensuelle<br />
* Possibilité d'envoie de mail massif au client (hors newsletter)<br />
* Envoie de mail à la création/suppression compte<br />
* Envoie de mail à la création d'une commande et modification de son état<br />
* Utilisation d'une URL avec UUID pour activation du compte créé<br />
* Suppression des comptes non activés après une semaine<br />
* IHM ClientSide (utilisation du site web...) avancement<br />
* Panier @Statefull + utilisation sur interface web<br />
* Ajout fonctionnalités dans le client d'administration<br />
* Possibilité de modifier le contenu des newsletters<br />
* Bug fix divers<br />
* Mise à jour wiki<br />
* Pagination des résultats sur la page d’accueil (liste des formules)<br />
<br />
==== Sprint 7 : 08/12/2015 - 16/12/2015 ====<br />
* Bug Fix API<br />
* Suppression token user lors du logout<br />
* Modification routes AngularJS<br />
* Cleaning Code ([http://www.sonarqube.org/ Audit SONAR] du code)<br />
* Mise à jour Javadoc<br />
* Mise à jour Wiki<br />
* Benchmark JMeter<br />
* Bug Fix Création Formule (ajouts des produits)<br />
* Rédaction Document Conception Système, Document Évaluation Système<br />
* Mise à jour Charte Graphique<br />
* Préparation démonstration - soutenance<br />
* Debug API<br />
* corrections mineures dans le système ( pseudo unique dans la BDD )<br />
<br />
== Centralisation documents produits ==<br />
=== Divers ===<br />
* [http://air.imag.fr/index.php/File:Spécifications_ecom_grp5.pdf Trace de travail (Sprint 1)], Conception "générale" du projet (livrable 08/09)<br />
* [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform Questionnaire] (étude des besoins)<br />
* [http://air.imag.fr/index.php/File:ECOM-GRP5-Conception.pdf Trace de travail (Sprint 2)], Conception IHM (livrable 06/10)<br />
<br />
'''''Note :''' Les documents de type "Trace de travail" ne sont que des snapshots de notre travail au jour J, et ne sont donc pas nécessairement en accord avec la version actuelle de notre projet, présentée ci dessus.''<br />
<br />
=== Dépôt Github ===<br />
[https://github.com/EudesRobin/ecom GitHub - ECOM GRP5] (dépôt actuellement privé).<br />
<br />
'''''Note''' : Merci de nous communiquer un identifiant de compte à ajouter, si vous souhaitez observer nos développements.''<br />
<br />
=== Board Waffle.io ===<br />
[https://waffle.io/EudesRobin/ecom Board Waffle.io - ECOM GRP5] (le dépot Github étant privé, cette board requiert la même authentification)<br />
<br />
=== SRS ===<br />
[http://air.imag.fr/index.php/SRS_ECOM_2015_GRP5 Document SRS]<br />
<br />
=== Charte Graphique ===<br />
[http://air.imag.fr/index.php/File:Chartegraphique.pdf Charte Graphique]<br />
<br />
=== Métrique (Cloc) ===<br />
<br />
-------------------------------------------------------------------------------<br />
Language files blank comment code<br />
-------------------------------------------------------------------------------<br />
Java 58 1073 850 5513<br />
Javascript 4 86 19 583<br />
HTML 9 48 17 575<br />
Maven 5 40 33 288<br />
Bourne Shell 5 0 0 41<br />
DOS Batch 3 0 0 40<br />
JSON 2 0 0 32<br />
XML 4 0 25 29<br />
CSS 1 6 1 23<br />
-------------------------------------------------------------------------------<br />
SUM: 91 1253 945 7124<br />
-------------------------------------------------------------------------------<br />
<br />
[http://air.imag.fr/index.php/File:Stats_cloc.txt Mesure Cloc du projet (détails)]<br />
<br />
=== Document Évaluation Système - Benchmark ===<br />
[http://air.imag.fr/index.php/Benchmark_ECOM_2015_GRP5 Document Évaluation Système - Benchmark]<br />
<br />
=== Audit SONAR (CI) ===<br />
[http://air.imag.fr/index.php/SONAR_ECOM_2015_GRP5 Audit SONAR (CI)]<br />
<br />
=== Schéma Conception Système ===<br />
[http://air.imag.fr/index.php/SCS_ECOM_2015_GRP5 Schéma SCS]<br />
<br />
=== Document Conception Système ===<br />
[http://air.imag.fr/index.php/File:DCS_gp5.pdf Document Conception Système]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=ECOM_RICM5_Groupe5_2015&diff=30201ECOM RICM5 Groupe5 20152016-07-05T22:07:11Z<p>Malek-Hadi.Mammar: /* Documents */</p>
<hr />
<div>Bienvenue sur la fiche de suivi du projet ''Restauration personnalisée en ligne'' .<br />
<br />
Un projet de site de E-commerce dans lequel nous allons nous initier à la programmation J2EE.<br />
<br />
Nous sommes le groupe 5 de la promotion RICM5 - 2015/2016. <br />
<br />
== Présentation du projet ==<br />
<br />
Le site porte sur un service de restauration personnalisée. <br />
Deux modes de fonctionnement vous sont possibles : <br />
<br />
* des formules sont proposées par des artisans restaurateurs, sur lesquelles il vous est possible d’imposer des contraintes (la cuisson,...) selon vos affinités gustative, si l’artisan le propose.<br />
<br />
* des thèmes culinaires sont proposés par des artisans restaurateurs qui se charge de répondre à votre demande de plat dans un temps imparti. Il est à noter que l’artisan peut librement accepter ou refuser le traitement de votre demande dans la mesure des stocks disponibles. Dans le cas d’un refus une proposition peut vous être faite par l’artisan.<br />
<br />
==L'équipe==<br />
<br />
* [[User:Robin.Eudes|Robin Eudes]] : '''''Chef de projet'''''<br />
* [[User:Malek-Hadi.Mammar|Malek Mammar]] : '''''Scrum Master'''''<br />
* [[User:Zhengmeng.Zhang|Zhang Zhengmeng]] : '''''Développeur'''''<br />
<br />
== Documents ==<br />
* [http://air.imag.fr/index.php/Benchmark_ECOM_2015_GRP5 Document Évaluation Système - Benchmark]<br />
* [http://air.imag.fr/index.php/File:DCS_gp5.pdf Document Conception Système]<br />
* [http://air.imag.fr/index.php/SCS_ECOM_2015_GRP5 Schéma SCS]<br />
* [http://air.imag.fr/index.php/SONAR_ECOM_2015_GRP5 Audit SONAR (CI)]<br />
* [http://air.imag.fr/index.php/SRS_ECOM_2015_GRP5 Document SRS]<br />
* [http://air.imag.fr/index.php/File:Chartegraphique.pdf Charte Graphique]<br />
* [http://air.imag.fr/index.php/File:Spécifications_ecom_grp5.pdf Spécifications - Trace de travail (Sprint 1)], Conception "générale" du projet (livrable 08/09)<br />
* [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform Questionnaire] (étude des besoins)<br />
* [http://air.imag.fr/index.php/File:ECOM-GRP5-Conception.pdf Trace de travail (Sprint 2)], Conception IHM (livrable 06/10)<br />
* [https://github.com/EudesRobin/ecom Dépôt Github] (dépôt actuellement privé).<br />
* [https://waffle.io/EudesRobin/ecom Board Waffle.io - ECOM GRP5] (le dépot Github étant privé, cette board requiert la même authentification)<br />
<br />
== Etude du marché ==<br />
Suite à la diffusion de notre [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform questionnaire], nous avons obtenu 26 réponses à l'heure actuelle. Bien que cet échantillon de réponse soit limité, nous l'avons jugé suffisamment représentatif pour baser nos principaux axes de travail en adéquation avec les réponses reçues. <br />
<br />
=== Utilisateurs cibles ===<br />
<br />
[[File:Users_cible.png]]<br />
<br />
Nous ciblons principalement les étudiants, ou les jeunes salariés.<br />
<br />
=== Besoins utilisateurs ===<br />
<br />
[[File:Users_need1.png]]<br />
[[File:Uses_need2.png]]<br />
[[File:Uses_need3.png]]<br />
<br />
Le moyen principal de paiement serait la carte bancaire, cependant il serait souhaitable que notre système accepte différents modules de paiements tel que [https://www.paypal.com/fr/home Paypal], [http://www.izly.fr/ Izly]. La base d'utilisateur est par ailleurs favorable à un système de fidélité, récompensant le client d'une commande offerte après une certaine quantité d'achats à définir. Le site doit également donner accès à un système de notation sur les formules ou plats proposés par les restaurateurs, l'avis des autres clients étant un critère de choix important.<br />
<br />
=== Etude de la concurrence ===<br />
<br />
La concurrence est nombreuse, et souvent spécialisée dans un domaine culinaire. En voici quelques exemples :<br />
<br />
* [https://www.foodpanda.com/ Foodpanda] : Le site nous proposera d'abord de choisir un restaurant, puis le menu que l'ont souhaite commander, avant de finaliser la commande (paiement). Cependant, on peut également effectuer une recherche par type de cuisine,et donc trouver les restaurants servant ce type de plats, pour revenir dans le premier schéma évoqué (choix restaurant -> choix plat -> paiement). La recherche par type de cuisine est pas mise en avant. Le site reste malgré tout assez clair, bien que chargé. Une application mobile est proposée par ailleurs (Android/iOS/Windows Phone).<br />
<br />
* [https://www.sushishop.fr/ SushiShop] : Thème "sombre" pour le site, on a un accès direct aux "boxes" (menus sushis), ou à la carte détaillée. Le menu donnant accès à la carte nous offre un "diaporama" des plats servis, très agréable visuellement. Le panier sera affiché dans un menu sur la droite uniquement une fois que nous avons sélectionné un plat. Un espace de connexion vers son compte est disponible en haut à droite. Logo discret sur le coin supérieur gauche.<br />
<br />
=== Plateformes d'utilisation ===<br />
<br />
[[File:Uses_plat.png]]<br />
<br />
La mise en forme de notre site devra être capable de supporter différents supports, PC et mobiles principalement (responsive design).<br />
<br />
== Définition des services rendus ==<br />
=== Exigences ===<br />
==== Exigences fonctionnelles ====<br />
* Tâches prioritaires<br />
** Gestion d'une session sécurisée<br />
** Acteur client : Effectuer une commande<br />
** Acteur client : Gérer son panier<br />
** Acteur artisan : Gérer son catalogue<br />
<br />
* Tâches secondaires<br />
** Acteur client : Effectuer un appel d'offre<br />
** Acteur artisan : Répondre à un appel d'offre<br />
<br />
==== Exigences non fonctionnelles ====<br />
* [https://fr.wikipedia.org/wiki/Propri%C3%A9t%C3%A9s_ACID Propriétés ACID] sur les transactions (en particulier le paiement)<br />
* Utilisabilité , selon [http://www.ergolab.net/articles/criteres-ergonomiques-1.php Les critères ergonomiques de Bastien & Scapin]<br />
* Gestion fine de l'utilisation de HTTPS<br />
* Résistance du système à la montée en charge (Temps de service constant)<br />
* Réduire au minimum le parcours de paiement<br />
* Portabilité (responsive design) PC, mobiles.<br />
<br />
== Conception du système ==<br />
=== Arbres des tâches ===<br />
====Tâches prioritaires====<br />
<br />
[[File:Arbre_taches_client_faire_une_commande.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_gerer_catalogue.png]]<br />
<br />
====Tâches secondaires====<br />
<br />
[[File:Arbre_taches_client_faire_un_appel_d_offre.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_repondre_appel_d_offre.png]]<br />
<br />
=== Diagramme de contexte ===<br />
[[File:Diagramme_de_contexte_ecom5.png]]<br />
<br />
=== Base de données ===<br />
[[File:UML_-_DataBase.png]]<br />
<br />
Vous remarquerez, qu'il n'y a pas de table "Panier" ou "Historique", car nous considérons que ces données sont à sauvegarder en session.<br />
<br />
=== IHM abstraites ===<br />
==== Faire une commande (client) ====<br />
Priorité : forte<br />
<br />
<br />
La tâche "Faire une commande" pour l'acteur Client se décomposer en ces 2 IHM abstraites : '''Consulter la carte''' et '''Consulter son panier''' .<br />
<br />
[[File:Client_-_consulter_carte_-_IHM_abstraite.png]]<br />
<br />
[[File:IHM_abstraite_-_consulter_panier_(client).png]]<br />
<br />
==== Gérer son catalogue (artisan) ====<br />
Priorité : forte<br />
<br />
<br />
[[File:IHM_abstraite_-_Gestion_catalogue_artisan.png]]<br />
<br />
=== Maquettes du site ===<br />
<br />
==== Maquette Accueil du site ====<br />
[[File:Maquette_carte.png]]<br />
<br />
==== Maquette page Formule ====<br />
[[File:Maquette_formule_(1).png]]<br />
<br />
== Planification du projet - SCRUM ==<br />
<br />
SCRUM est la méthode de travail préconisée, bien que non adaptée à la nature exploratoire du projet. Nous tacherons néanmoins de planifier au mieux.<br />
<br />
Sprint planning<br />
---------------<br />
<br />
==== Sprint 1 : 15/09/2015 - 28/09/2015 ====<br />
* Choix d'un sujet de commerce en ligne<br />
* Prise en main des outils de développement J2EE<br />
* Réalisation d'un questionnaire <br />
** ciblage du marché<br />
** étude de marché sur la concurrence<br />
** identification des besoins utilisateur<br />
<br />
==== Sprint 2 : 29/09/2015 - 12/10/2015 ====<br />
* Réalisation d'un arbre des tâches<br />
* Conception d'une architecture générale<br />
* Publication des documents de conception IHM sur air.imag.fr<br />
* Analyse des résultats du questionnaire<br />
<br />
==== Sprint 3 : 13/10/2015 - 26/10/2015 ====<br />
* Mise en forme des arbres des tâches, IHM abstraites.<br />
* Analyse de la concurrence<br />
* Réalisation de la maquette<br />
* Conception Architecture système<br />
* Préparation de la soutenance "Conception" GL/IHM/Système<br />
<br />
==== Sprint 4 : 27/10/2015 - 09/11/2015 ====<br />
* Mise en place client d'administration lourd<br />
* Session bean Client,Artisan,Product : première version<br />
* Recherches concernant la mise en place d'une API REST<br />
* Recherches concernant la gestion de l'authentification via l'API REST<br />
* Mise en place d'une page d'index pour la webapp utilisant bootstrap, angularJS<br />
* Modification de quelques Entity bean (champs inutiles, etc )<br />
<br />
==== Sprint 5 : 10/11/2015 - 23/11/2015 ====<br />
* Session beans Formule, Orders première version<br />
* Autre sessions beans : version 2 , révision des prototypes, ajout de fonctionnalités<br />
* API REST sans authentification v1 opérationnelle pour Product, Artisan, Client ( incomplète , cependant )<br />
* Modification de certaines propriétés des entity pour empêcher des incohérences/dysfonctionnements<br />
* Ajout fonctions pour modifier un champ unique de Product (icon_url,description,isAvailable,price,title)<br />
<br />
==== Sprint 6 : 24/11/2015 - 07/12/2015 ====<br />
* Finalisation Authentification API + diverses fonctionnalités<br />
* Finalisation des divers Session beans (client,artisan,formule,product,orders)<br />
* Ajout newsletter hebdomadaire , mensuelle<br />
* Possibilité d'envoie de mail massif au client (hors newsletter)<br />
* Envoie de mail à la création/suppression compte<br />
* Envoie de mail à la création d'une commande et modification de son état<br />
* Utilisation d'une URL avec UUID pour activation du compte créé<br />
* Suppression des comptes non activés après une semaine<br />
* IHM ClientSide (utilisation du site web...) avancement<br />
* Panier @Statefull + utilisation sur interface web<br />
* Ajout fonctionnalités dans le client d'administration<br />
* Possibilité de modifier le contenu des newsletters<br />
* Bug fix divers<br />
* Mise à jour wiki<br />
* Pagination des résultats sur la page d’accueil (liste des formules)<br />
<br />
==== Sprint 7 : 08/12/2015 - 16/12/2015 ====<br />
* Bug Fix API<br />
* Suppression token user lors du logout<br />
* Modification routes AngularJS<br />
* Cleaning Code ([http://www.sonarqube.org/ Audit SONAR] du code)<br />
* Mise à jour Javadoc<br />
* Mise à jour Wiki<br />
* Benchmark JMeter<br />
* Bug Fix Création Formule (ajouts des produits)<br />
* Rédaction Document Conception Système, Document Évaluation Système<br />
* Mise à jour Charte Graphique<br />
* Préparation démonstration - soutenance<br />
* Debug API<br />
* corrections mineures dans le système ( pseudo unique dans la BDD )<br />
<br />
== Centralisation documents produits ==<br />
=== Divers ===<br />
* [http://air.imag.fr/index.php/File:Spécifications_ecom_grp5.pdf Trace de travail (Sprint 1)], Conception "générale" du projet (livrable 08/09)<br />
* [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform Questionnaire] (étude des besoins)<br />
* [http://air.imag.fr/index.php/File:ECOM-GRP5-Conception.pdf Trace de travail (Sprint 2)], Conception IHM (livrable 06/10)<br />
<br />
'''''Note :''' Les documents de type "Trace de travail" ne sont que des snapshots de notre travail au jour J, et ne sont donc pas nécessairement en accord avec la version actuelle de notre projet, présentée ci dessus.''<br />
<br />
=== Dépôt Github ===<br />
[https://github.com/EudesRobin/ecom GitHub - ECOM GRP5] (dépôt actuellement privé).<br />
<br />
'''''Note''' : Merci de nous communiquer un identifiant de compte à ajouter, si vous souhaitez observer nos développements.''<br />
<br />
=== Board Waffle.io ===<br />
[https://waffle.io/EudesRobin/ecom Board Waffle.io - ECOM GRP5] (le dépot Github étant privé, cette board requiert la même authentification)<br />
<br />
=== SRS ===<br />
[http://air.imag.fr/index.php/SRS_ECOM_2015_GRP5 Document SRS]<br />
<br />
=== Charte Graphique ===<br />
[http://air.imag.fr/index.php/File:Chartegraphique.pdf Charte Graphique]<br />
<br />
=== Métrique (Cloc) ===<br />
<br />
-------------------------------------------------------------------------------<br />
Language files blank comment code<br />
-------------------------------------------------------------------------------<br />
Java 58 1073 850 5513<br />
Javascript 4 86 19 583<br />
HTML 9 48 17 575<br />
Maven 5 40 33 288<br />
Bourne Shell 5 0 0 41<br />
DOS Batch 3 0 0 40<br />
JSON 2 0 0 32<br />
XML 4 0 25 29<br />
CSS 1 6 1 23<br />
-------------------------------------------------------------------------------<br />
SUM: 91 1253 945 7124<br />
-------------------------------------------------------------------------------<br />
<br />
[http://air.imag.fr/index.php/File:Stats_cloc.txt Mesure Cloc du projet (détails)]<br />
<br />
=== Document Évaluation Système - Benchmark ===<br />
[http://air.imag.fr/index.php/Benchmark_ECOM_2015_GRP5 Document Évaluation Système - Benchmark]<br />
<br />
=== Audit SONAR (CI) ===<br />
[http://air.imag.fr/index.php/SONAR_ECOM_2015_GRP5 Audit SONAR (CI)]<br />
<br />
=== Schéma Conception Système ===<br />
[http://air.imag.fr/index.php/SCS_ECOM_2015_GRP5 Schéma SCS]<br />
<br />
=== Document Conception Système ===<br />
[http://air.imag.fr/index.php/File:DCS_gp5.pdf Document Conception Système]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=ECOM_RICM5_Groupe5_2015&diff=30200ECOM RICM5 Groupe5 20152016-07-05T22:01:50Z<p>Malek-Hadi.Mammar: /* Documents */</p>
<hr />
<div>Bienvenue sur la fiche de suivi du projet ''Restauration personnalisée en ligne'' .<br />
<br />
Un projet de site de E-commerce dans lequel nous allons nous initier à la programmation J2EE.<br />
<br />
Nous sommes le groupe 5 de la promotion RICM5 - 2015/2016. <br />
<br />
== Présentation du projet ==<br />
<br />
Le site porte sur un service de restauration personnalisée. <br />
Deux modes de fonctionnement vous sont possibles : <br />
<br />
* des formules sont proposées par des artisans restaurateurs, sur lesquelles il vous est possible d’imposer des contraintes (la cuisson,...) selon vos affinités gustative, si l’artisan le propose.<br />
<br />
* des thèmes culinaires sont proposés par des artisans restaurateurs qui se charge de répondre à votre demande de plat dans un temps imparti. Il est à noter que l’artisan peut librement accepter ou refuser le traitement de votre demande dans la mesure des stocks disponibles. Dans le cas d’un refus une proposition peut vous être faite par l’artisan.<br />
<br />
==L'équipe==<br />
<br />
* [[User:Robin.Eudes|Robin Eudes]] : '''''Chef de projet'''''<br />
* [[User:Malek-Hadi.Mammar|Malek Mammar]] : '''''Scrum Master'''''<br />
* [[User:Zhengmeng.Zhang|Zhang Zhengmeng]] : '''''Développeur'''''<br />
<br />
== Documents ==<br />
* [http://air.imag.fr/index.php/Benchmark_ECOM_2015_GRP5 Document Évaluation Système - Benchmark]<br />
* [http://air.imag.fr/index.php/File:DCS_gp5.pdf Document Conception Système]<br />
* [http://air.imag.fr/index.php/SCS_ECOM_2015_GRP5 Schéma SCS]<br />
* [http://air.imag.fr/index.php/SONAR_ECOM_2015_GRP5 Audit SONAR (CI)]<br />
<br />
== Etude du marché ==<br />
Suite à la diffusion de notre [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform questionnaire], nous avons obtenu 26 réponses à l'heure actuelle. Bien que cet échantillon de réponse soit limité, nous l'avons jugé suffisamment représentatif pour baser nos principaux axes de travail en adéquation avec les réponses reçues. <br />
<br />
=== Utilisateurs cibles ===<br />
<br />
[[File:Users_cible.png]]<br />
<br />
Nous ciblons principalement les étudiants, ou les jeunes salariés.<br />
<br />
=== Besoins utilisateurs ===<br />
<br />
[[File:Users_need1.png]]<br />
[[File:Uses_need2.png]]<br />
[[File:Uses_need3.png]]<br />
<br />
Le moyen principal de paiement serait la carte bancaire, cependant il serait souhaitable que notre système accepte différents modules de paiements tel que [https://www.paypal.com/fr/home Paypal], [http://www.izly.fr/ Izly]. La base d'utilisateur est par ailleurs favorable à un système de fidélité, récompensant le client d'une commande offerte après une certaine quantité d'achats à définir. Le site doit également donner accès à un système de notation sur les formules ou plats proposés par les restaurateurs, l'avis des autres clients étant un critère de choix important.<br />
<br />
=== Etude de la concurrence ===<br />
<br />
La concurrence est nombreuse, et souvent spécialisée dans un domaine culinaire. En voici quelques exemples :<br />
<br />
* [https://www.foodpanda.com/ Foodpanda] : Le site nous proposera d'abord de choisir un restaurant, puis le menu que l'ont souhaite commander, avant de finaliser la commande (paiement). Cependant, on peut également effectuer une recherche par type de cuisine,et donc trouver les restaurants servant ce type de plats, pour revenir dans le premier schéma évoqué (choix restaurant -> choix plat -> paiement). La recherche par type de cuisine est pas mise en avant. Le site reste malgré tout assez clair, bien que chargé. Une application mobile est proposée par ailleurs (Android/iOS/Windows Phone).<br />
<br />
* [https://www.sushishop.fr/ SushiShop] : Thème "sombre" pour le site, on a un accès direct aux "boxes" (menus sushis), ou à la carte détaillée. Le menu donnant accès à la carte nous offre un "diaporama" des plats servis, très agréable visuellement. Le panier sera affiché dans un menu sur la droite uniquement une fois que nous avons sélectionné un plat. Un espace de connexion vers son compte est disponible en haut à droite. Logo discret sur le coin supérieur gauche.<br />
<br />
=== Plateformes d'utilisation ===<br />
<br />
[[File:Uses_plat.png]]<br />
<br />
La mise en forme de notre site devra être capable de supporter différents supports, PC et mobiles principalement (responsive design).<br />
<br />
== Définition des services rendus ==<br />
=== Exigences ===<br />
==== Exigences fonctionnelles ====<br />
* Tâches prioritaires<br />
** Gestion d'une session sécurisée<br />
** Acteur client : Effectuer une commande<br />
** Acteur client : Gérer son panier<br />
** Acteur artisan : Gérer son catalogue<br />
<br />
* Tâches secondaires<br />
** Acteur client : Effectuer un appel d'offre<br />
** Acteur artisan : Répondre à un appel d'offre<br />
<br />
==== Exigences non fonctionnelles ====<br />
* [https://fr.wikipedia.org/wiki/Propri%C3%A9t%C3%A9s_ACID Propriétés ACID] sur les transactions (en particulier le paiement)<br />
* Utilisabilité , selon [http://www.ergolab.net/articles/criteres-ergonomiques-1.php Les critères ergonomiques de Bastien & Scapin]<br />
* Gestion fine de l'utilisation de HTTPS<br />
* Résistance du système à la montée en charge (Temps de service constant)<br />
* Réduire au minimum le parcours de paiement<br />
* Portabilité (responsive design) PC, mobiles.<br />
<br />
== Conception du système ==<br />
=== Arbres des tâches ===<br />
====Tâches prioritaires====<br />
<br />
[[File:Arbre_taches_client_faire_une_commande.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_gerer_catalogue.png]]<br />
<br />
====Tâches secondaires====<br />
<br />
[[File:Arbre_taches_client_faire_un_appel_d_offre.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_repondre_appel_d_offre.png]]<br />
<br />
=== Diagramme de contexte ===<br />
[[File:Diagramme_de_contexte_ecom5.png]]<br />
<br />
=== Base de données ===<br />
[[File:UML_-_DataBase.png]]<br />
<br />
Vous remarquerez, qu'il n'y a pas de table "Panier" ou "Historique", car nous considérons que ces données sont à sauvegarder en session.<br />
<br />
=== IHM abstraites ===<br />
==== Faire une commande (client) ====<br />
Priorité : forte<br />
<br />
<br />
La tâche "Faire une commande" pour l'acteur Client se décomposer en ces 2 IHM abstraites : '''Consulter la carte''' et '''Consulter son panier''' .<br />
<br />
[[File:Client_-_consulter_carte_-_IHM_abstraite.png]]<br />
<br />
[[File:IHM_abstraite_-_consulter_panier_(client).png]]<br />
<br />
==== Gérer son catalogue (artisan) ====<br />
Priorité : forte<br />
<br />
<br />
[[File:IHM_abstraite_-_Gestion_catalogue_artisan.png]]<br />
<br />
=== Maquettes du site ===<br />
<br />
==== Maquette Accueil du site ====<br />
[[File:Maquette_carte.png]]<br />
<br />
==== Maquette page Formule ====<br />
[[File:Maquette_formule_(1).png]]<br />
<br />
== Planification du projet - SCRUM ==<br />
<br />
SCRUM est la méthode de travail préconisée, bien que non adaptée à la nature exploratoire du projet. Nous tacherons néanmoins de planifier au mieux.<br />
<br />
Sprint planning<br />
---------------<br />
<br />
==== Sprint 1 : 15/09/2015 - 28/09/2015 ====<br />
* Choix d'un sujet de commerce en ligne<br />
* Prise en main des outils de développement J2EE<br />
* Réalisation d'un questionnaire <br />
** ciblage du marché<br />
** étude de marché sur la concurrence<br />
** identification des besoins utilisateur<br />
<br />
==== Sprint 2 : 29/09/2015 - 12/10/2015 ====<br />
* Réalisation d'un arbre des tâches<br />
* Conception d'une architecture générale<br />
* Publication des documents de conception IHM sur air.imag.fr<br />
* Analyse des résultats du questionnaire<br />
<br />
==== Sprint 3 : 13/10/2015 - 26/10/2015 ====<br />
* Mise en forme des arbres des tâches, IHM abstraites.<br />
* Analyse de la concurrence<br />
* Réalisation de la maquette<br />
* Conception Architecture système<br />
* Préparation de la soutenance "Conception" GL/IHM/Système<br />
<br />
==== Sprint 4 : 27/10/2015 - 09/11/2015 ====<br />
* Mise en place client d'administration lourd<br />
* Session bean Client,Artisan,Product : première version<br />
* Recherches concernant la mise en place d'une API REST<br />
* Recherches concernant la gestion de l'authentification via l'API REST<br />
* Mise en place d'une page d'index pour la webapp utilisant bootstrap, angularJS<br />
* Modification de quelques Entity bean (champs inutiles, etc )<br />
<br />
==== Sprint 5 : 10/11/2015 - 23/11/2015 ====<br />
* Session beans Formule, Orders première version<br />
* Autre sessions beans : version 2 , révision des prototypes, ajout de fonctionnalités<br />
* API REST sans authentification v1 opérationnelle pour Product, Artisan, Client ( incomplète , cependant )<br />
* Modification de certaines propriétés des entity pour empêcher des incohérences/dysfonctionnements<br />
* Ajout fonctions pour modifier un champ unique de Product (icon_url,description,isAvailable,price,title)<br />
<br />
==== Sprint 6 : 24/11/2015 - 07/12/2015 ====<br />
* Finalisation Authentification API + diverses fonctionnalités<br />
* Finalisation des divers Session beans (client,artisan,formule,product,orders)<br />
* Ajout newsletter hebdomadaire , mensuelle<br />
* Possibilité d'envoie de mail massif au client (hors newsletter)<br />
* Envoie de mail à la création/suppression compte<br />
* Envoie de mail à la création d'une commande et modification de son état<br />
* Utilisation d'une URL avec UUID pour activation du compte créé<br />
* Suppression des comptes non activés après une semaine<br />
* IHM ClientSide (utilisation du site web...) avancement<br />
* Panier @Statefull + utilisation sur interface web<br />
* Ajout fonctionnalités dans le client d'administration<br />
* Possibilité de modifier le contenu des newsletters<br />
* Bug fix divers<br />
* Mise à jour wiki<br />
* Pagination des résultats sur la page d’accueil (liste des formules)<br />
<br />
==== Sprint 7 : 08/12/2015 - 16/12/2015 ====<br />
* Bug Fix API<br />
* Suppression token user lors du logout<br />
* Modification routes AngularJS<br />
* Cleaning Code ([http://www.sonarqube.org/ Audit SONAR] du code)<br />
* Mise à jour Javadoc<br />
* Mise à jour Wiki<br />
* Benchmark JMeter<br />
* Bug Fix Création Formule (ajouts des produits)<br />
* Rédaction Document Conception Système, Document Évaluation Système<br />
* Mise à jour Charte Graphique<br />
* Préparation démonstration - soutenance<br />
* Debug API<br />
* corrections mineures dans le système ( pseudo unique dans la BDD )<br />
<br />
== Centralisation documents produits ==<br />
=== Divers ===<br />
* [http://air.imag.fr/index.php/File:Spécifications_ecom_grp5.pdf Trace de travail (Sprint 1)], Conception "générale" du projet (livrable 08/09)<br />
* [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform Questionnaire] (étude des besoins)<br />
* [http://air.imag.fr/index.php/File:ECOM-GRP5-Conception.pdf Trace de travail (Sprint 2)], Conception IHM (livrable 06/10)<br />
<br />
'''''Note :''' Les documents de type "Trace de travail" ne sont que des snapshots de notre travail au jour J, et ne sont donc pas nécessairement en accord avec la version actuelle de notre projet, présentée ci dessus.''<br />
<br />
=== Dépôt Github ===<br />
[https://github.com/EudesRobin/ecom GitHub - ECOM GRP5] (dépôt actuellement privé).<br />
<br />
'''''Note''' : Merci de nous communiquer un identifiant de compte à ajouter, si vous souhaitez observer nos développements.''<br />
<br />
=== Board Waffle.io ===<br />
[https://waffle.io/EudesRobin/ecom Board Waffle.io - ECOM GRP5] (le dépot Github étant privé, cette board requiert la même authentification)<br />
<br />
=== SRS ===<br />
[http://air.imag.fr/index.php/SRS_ECOM_2015_GRP5 Document SRS]<br />
<br />
=== Charte Graphique ===<br />
[http://air.imag.fr/index.php/File:Chartegraphique.pdf Charte Graphique]<br />
<br />
=== Métrique (Cloc) ===<br />
<br />
-------------------------------------------------------------------------------<br />
Language files blank comment code<br />
-------------------------------------------------------------------------------<br />
Java 58 1073 850 5513<br />
Javascript 4 86 19 583<br />
HTML 9 48 17 575<br />
Maven 5 40 33 288<br />
Bourne Shell 5 0 0 41<br />
DOS Batch 3 0 0 40<br />
JSON 2 0 0 32<br />
XML 4 0 25 29<br />
CSS 1 6 1 23<br />
-------------------------------------------------------------------------------<br />
SUM: 91 1253 945 7124<br />
-------------------------------------------------------------------------------<br />
<br />
[http://air.imag.fr/index.php/File:Stats_cloc.txt Mesure Cloc du projet (détails)]<br />
<br />
=== Document Évaluation Système - Benchmark ===<br />
[http://air.imag.fr/index.php/Benchmark_ECOM_2015_GRP5 Document Évaluation Système - Benchmark]<br />
<br />
=== Audit SONAR (CI) ===<br />
[http://air.imag.fr/index.php/SONAR_ECOM_2015_GRP5 Audit SONAR (CI)]<br />
<br />
=== Schéma Conception Système ===<br />
[http://air.imag.fr/index.php/SCS_ECOM_2015_GRP5 Schéma SCS]<br />
<br />
=== Document Conception Système ===<br />
[http://air.imag.fr/index.php/File:DCS_gp5.pdf Document Conception Système]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=ECOM_RICM5_Groupe5_2015&diff=30199ECOM RICM5 Groupe5 20152016-07-05T22:01:15Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>Bienvenue sur la fiche de suivi du projet ''Restauration personnalisée en ligne'' .<br />
<br />
Un projet de site de E-commerce dans lequel nous allons nous initier à la programmation J2EE.<br />
<br />
Nous sommes le groupe 5 de la promotion RICM5 - 2015/2016. <br />
<br />
== Présentation du projet ==<br />
<br />
Le site porte sur un service de restauration personnalisée. <br />
Deux modes de fonctionnement vous sont possibles : <br />
<br />
* des formules sont proposées par des artisans restaurateurs, sur lesquelles il vous est possible d’imposer des contraintes (la cuisson,...) selon vos affinités gustative, si l’artisan le propose.<br />
<br />
* des thèmes culinaires sont proposés par des artisans restaurateurs qui se charge de répondre à votre demande de plat dans un temps imparti. Il est à noter que l’artisan peut librement accepter ou refuser le traitement de votre demande dans la mesure des stocks disponibles. Dans le cas d’un refus une proposition peut vous être faite par l’artisan.<br />
<br />
==L'équipe==<br />
<br />
* [[User:Robin.Eudes|Robin Eudes]] : '''''Chef de projet'''''<br />
* [[User:Malek-Hadi.Mammar|Malek Mammar]] : '''''Scrum Master'''''<br />
* [[User:Zhengmeng.Zhang|Zhang Zhengmeng]] : '''''Développeur'''''<br />
<br />
== Documents ==<br />
[http://air.imag.fr/index.php/Benchmark_ECOM_2015_GRP5 Document Évaluation Système - Benchmark]<br />
[http://air.imag.fr/index.php/File:DCS_gp5.pdf Document Conception Système]<br />
[http://air.imag.fr/index.php/SCS_ECOM_2015_GRP5 Schéma SCS]<br />
[http://air.imag.fr/index.php/SONAR_ECOM_2015_GRP5 Audit SONAR (CI)]<br />
<br />
== Etude du marché ==<br />
Suite à la diffusion de notre [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform questionnaire], nous avons obtenu 26 réponses à l'heure actuelle. Bien que cet échantillon de réponse soit limité, nous l'avons jugé suffisamment représentatif pour baser nos principaux axes de travail en adéquation avec les réponses reçues. <br />
<br />
=== Utilisateurs cibles ===<br />
<br />
[[File:Users_cible.png]]<br />
<br />
Nous ciblons principalement les étudiants, ou les jeunes salariés.<br />
<br />
=== Besoins utilisateurs ===<br />
<br />
[[File:Users_need1.png]]<br />
[[File:Uses_need2.png]]<br />
[[File:Uses_need3.png]]<br />
<br />
Le moyen principal de paiement serait la carte bancaire, cependant il serait souhaitable que notre système accepte différents modules de paiements tel que [https://www.paypal.com/fr/home Paypal], [http://www.izly.fr/ Izly]. La base d'utilisateur est par ailleurs favorable à un système de fidélité, récompensant le client d'une commande offerte après une certaine quantité d'achats à définir. Le site doit également donner accès à un système de notation sur les formules ou plats proposés par les restaurateurs, l'avis des autres clients étant un critère de choix important.<br />
<br />
=== Etude de la concurrence ===<br />
<br />
La concurrence est nombreuse, et souvent spécialisée dans un domaine culinaire. En voici quelques exemples :<br />
<br />
* [https://www.foodpanda.com/ Foodpanda] : Le site nous proposera d'abord de choisir un restaurant, puis le menu que l'ont souhaite commander, avant de finaliser la commande (paiement). Cependant, on peut également effectuer une recherche par type de cuisine,et donc trouver les restaurants servant ce type de plats, pour revenir dans le premier schéma évoqué (choix restaurant -> choix plat -> paiement). La recherche par type de cuisine est pas mise en avant. Le site reste malgré tout assez clair, bien que chargé. Une application mobile est proposée par ailleurs (Android/iOS/Windows Phone).<br />
<br />
* [https://www.sushishop.fr/ SushiShop] : Thème "sombre" pour le site, on a un accès direct aux "boxes" (menus sushis), ou à la carte détaillée. Le menu donnant accès à la carte nous offre un "diaporama" des plats servis, très agréable visuellement. Le panier sera affiché dans un menu sur la droite uniquement une fois que nous avons sélectionné un plat. Un espace de connexion vers son compte est disponible en haut à droite. Logo discret sur le coin supérieur gauche.<br />
<br />
=== Plateformes d'utilisation ===<br />
<br />
[[File:Uses_plat.png]]<br />
<br />
La mise en forme de notre site devra être capable de supporter différents supports, PC et mobiles principalement (responsive design).<br />
<br />
== Définition des services rendus ==<br />
=== Exigences ===<br />
==== Exigences fonctionnelles ====<br />
* Tâches prioritaires<br />
** Gestion d'une session sécurisée<br />
** Acteur client : Effectuer une commande<br />
** Acteur client : Gérer son panier<br />
** Acteur artisan : Gérer son catalogue<br />
<br />
* Tâches secondaires<br />
** Acteur client : Effectuer un appel d'offre<br />
** Acteur artisan : Répondre à un appel d'offre<br />
<br />
==== Exigences non fonctionnelles ====<br />
* [https://fr.wikipedia.org/wiki/Propri%C3%A9t%C3%A9s_ACID Propriétés ACID] sur les transactions (en particulier le paiement)<br />
* Utilisabilité , selon [http://www.ergolab.net/articles/criteres-ergonomiques-1.php Les critères ergonomiques de Bastien & Scapin]<br />
* Gestion fine de l'utilisation de HTTPS<br />
* Résistance du système à la montée en charge (Temps de service constant)<br />
* Réduire au minimum le parcours de paiement<br />
* Portabilité (responsive design) PC, mobiles.<br />
<br />
== Conception du système ==<br />
=== Arbres des tâches ===<br />
====Tâches prioritaires====<br />
<br />
[[File:Arbre_taches_client_faire_une_commande.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_gerer_catalogue.png]]<br />
<br />
====Tâches secondaires====<br />
<br />
[[File:Arbre_taches_client_faire_un_appel_d_offre.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_repondre_appel_d_offre.png]]<br />
<br />
=== Diagramme de contexte ===<br />
[[File:Diagramme_de_contexte_ecom5.png]]<br />
<br />
=== Base de données ===<br />
[[File:UML_-_DataBase.png]]<br />
<br />
Vous remarquerez, qu'il n'y a pas de table "Panier" ou "Historique", car nous considérons que ces données sont à sauvegarder en session.<br />
<br />
=== IHM abstraites ===<br />
==== Faire une commande (client) ====<br />
Priorité : forte<br />
<br />
<br />
La tâche "Faire une commande" pour l'acteur Client se décomposer en ces 2 IHM abstraites : '''Consulter la carte''' et '''Consulter son panier''' .<br />
<br />
[[File:Client_-_consulter_carte_-_IHM_abstraite.png]]<br />
<br />
[[File:IHM_abstraite_-_consulter_panier_(client).png]]<br />
<br />
==== Gérer son catalogue (artisan) ====<br />
Priorité : forte<br />
<br />
<br />
[[File:IHM_abstraite_-_Gestion_catalogue_artisan.png]]<br />
<br />
=== Maquettes du site ===<br />
<br />
==== Maquette Accueil du site ====<br />
[[File:Maquette_carte.png]]<br />
<br />
==== Maquette page Formule ====<br />
[[File:Maquette_formule_(1).png]]<br />
<br />
== Planification du projet - SCRUM ==<br />
<br />
SCRUM est la méthode de travail préconisée, bien que non adaptée à la nature exploratoire du projet. Nous tacherons néanmoins de planifier au mieux.<br />
<br />
Sprint planning<br />
---------------<br />
<br />
==== Sprint 1 : 15/09/2015 - 28/09/2015 ====<br />
* Choix d'un sujet de commerce en ligne<br />
* Prise en main des outils de développement J2EE<br />
* Réalisation d'un questionnaire <br />
** ciblage du marché<br />
** étude de marché sur la concurrence<br />
** identification des besoins utilisateur<br />
<br />
==== Sprint 2 : 29/09/2015 - 12/10/2015 ====<br />
* Réalisation d'un arbre des tâches<br />
* Conception d'une architecture générale<br />
* Publication des documents de conception IHM sur air.imag.fr<br />
* Analyse des résultats du questionnaire<br />
<br />
==== Sprint 3 : 13/10/2015 - 26/10/2015 ====<br />
* Mise en forme des arbres des tâches, IHM abstraites.<br />
* Analyse de la concurrence<br />
* Réalisation de la maquette<br />
* Conception Architecture système<br />
* Préparation de la soutenance "Conception" GL/IHM/Système<br />
<br />
==== Sprint 4 : 27/10/2015 - 09/11/2015 ====<br />
* Mise en place client d'administration lourd<br />
* Session bean Client,Artisan,Product : première version<br />
* Recherches concernant la mise en place d'une API REST<br />
* Recherches concernant la gestion de l'authentification via l'API REST<br />
* Mise en place d'une page d'index pour la webapp utilisant bootstrap, angularJS<br />
* Modification de quelques Entity bean (champs inutiles, etc )<br />
<br />
==== Sprint 5 : 10/11/2015 - 23/11/2015 ====<br />
* Session beans Formule, Orders première version<br />
* Autre sessions beans : version 2 , révision des prototypes, ajout de fonctionnalités<br />
* API REST sans authentification v1 opérationnelle pour Product, Artisan, Client ( incomplète , cependant )<br />
* Modification de certaines propriétés des entity pour empêcher des incohérences/dysfonctionnements<br />
* Ajout fonctions pour modifier un champ unique de Product (icon_url,description,isAvailable,price,title)<br />
<br />
==== Sprint 6 : 24/11/2015 - 07/12/2015 ====<br />
* Finalisation Authentification API + diverses fonctionnalités<br />
* Finalisation des divers Session beans (client,artisan,formule,product,orders)<br />
* Ajout newsletter hebdomadaire , mensuelle<br />
* Possibilité d'envoie de mail massif au client (hors newsletter)<br />
* Envoie de mail à la création/suppression compte<br />
* Envoie de mail à la création d'une commande et modification de son état<br />
* Utilisation d'une URL avec UUID pour activation du compte créé<br />
* Suppression des comptes non activés après une semaine<br />
* IHM ClientSide (utilisation du site web...) avancement<br />
* Panier @Statefull + utilisation sur interface web<br />
* Ajout fonctionnalités dans le client d'administration<br />
* Possibilité de modifier le contenu des newsletters<br />
* Bug fix divers<br />
* Mise à jour wiki<br />
* Pagination des résultats sur la page d’accueil (liste des formules)<br />
<br />
==== Sprint 7 : 08/12/2015 - 16/12/2015 ====<br />
* Bug Fix API<br />
* Suppression token user lors du logout<br />
* Modification routes AngularJS<br />
* Cleaning Code ([http://www.sonarqube.org/ Audit SONAR] du code)<br />
* Mise à jour Javadoc<br />
* Mise à jour Wiki<br />
* Benchmark JMeter<br />
* Bug Fix Création Formule (ajouts des produits)<br />
* Rédaction Document Conception Système, Document Évaluation Système<br />
* Mise à jour Charte Graphique<br />
* Préparation démonstration - soutenance<br />
* Debug API<br />
* corrections mineures dans le système ( pseudo unique dans la BDD )<br />
<br />
== Centralisation documents produits ==<br />
=== Divers ===<br />
* [http://air.imag.fr/index.php/File:Spécifications_ecom_grp5.pdf Trace de travail (Sprint 1)], Conception "générale" du projet (livrable 08/09)<br />
* [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform Questionnaire] (étude des besoins)<br />
* [http://air.imag.fr/index.php/File:ECOM-GRP5-Conception.pdf Trace de travail (Sprint 2)], Conception IHM (livrable 06/10)<br />
<br />
'''''Note :''' Les documents de type "Trace de travail" ne sont que des snapshots de notre travail au jour J, et ne sont donc pas nécessairement en accord avec la version actuelle de notre projet, présentée ci dessus.''<br />
<br />
=== Dépôt Github ===<br />
[https://github.com/EudesRobin/ecom GitHub - ECOM GRP5] (dépôt actuellement privé).<br />
<br />
'''''Note''' : Merci de nous communiquer un identifiant de compte à ajouter, si vous souhaitez observer nos développements.''<br />
<br />
=== Board Waffle.io ===<br />
[https://waffle.io/EudesRobin/ecom Board Waffle.io - ECOM GRP5] (le dépot Github étant privé, cette board requiert la même authentification)<br />
<br />
=== SRS ===<br />
[http://air.imag.fr/index.php/SRS_ECOM_2015_GRP5 Document SRS]<br />
<br />
=== Charte Graphique ===<br />
[http://air.imag.fr/index.php/File:Chartegraphique.pdf Charte Graphique]<br />
<br />
=== Métrique (Cloc) ===<br />
<br />
-------------------------------------------------------------------------------<br />
Language files blank comment code<br />
-------------------------------------------------------------------------------<br />
Java 58 1073 850 5513<br />
Javascript 4 86 19 583<br />
HTML 9 48 17 575<br />
Maven 5 40 33 288<br />
Bourne Shell 5 0 0 41<br />
DOS Batch 3 0 0 40<br />
JSON 2 0 0 32<br />
XML 4 0 25 29<br />
CSS 1 6 1 23<br />
-------------------------------------------------------------------------------<br />
SUM: 91 1253 945 7124<br />
-------------------------------------------------------------------------------<br />
<br />
[http://air.imag.fr/index.php/File:Stats_cloc.txt Mesure Cloc du projet (détails)]<br />
<br />
=== Document Évaluation Système - Benchmark ===<br />
[http://air.imag.fr/index.php/Benchmark_ECOM_2015_GRP5 Document Évaluation Système - Benchmark]<br />
<br />
=== Audit SONAR (CI) ===<br />
[http://air.imag.fr/index.php/SONAR_ECOM_2015_GRP5 Audit SONAR (CI)]<br />
<br />
=== Schéma Conception Système ===<br />
[http://air.imag.fr/index.php/SCS_ECOM_2015_GRP5 Schéma SCS]<br />
<br />
=== Document Conception Système ===<br />
[http://air.imag.fr/index.php/File:DCS_gp5.pdf Document Conception Système]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Projets-2015-2016-IaaS_Docker&diff=27203Projets-2015-2016-IaaS Docker2016-02-17T23:32:44Z<p>Malek-Hadi.Mammar: /* Build and run */</p>
<hr />
<div>= Project presentation =<br />
== Introduction ==<br />
<br />
The objective of this project is to allow a user group (member) to pool their laptops or desktop in order to calculate big data of few users. To do so, the solution should work with Docker to virtualize user machines and control the use of resources of each machine.<br />
<br />
Project under GPLv3 licence : https://www.gnu.org/licenses/gpl-3.0.fr.html<br />
<br />
== The team ==<br />
'''RICM5 students''' <br />
<br />
* EUDES Robin<br />
* DAMOTTE Alan<br />
* BARTHELEMY Romain<br />
* MAMMAR Malek<br />
* GUO Kai<br />
<br />
'''DUT Students'''<br />
<br />
* BONNARD Loïc<br />
* CAPERAN Théo<br />
<br />
'''Supervisors'''<br />
Pierre-Yves Gibello (Linagora), Vincent Zurczak (Linagora), Didier Donsez <br />
<br />
== Deliverables ==<br />
[https://github.com/EudesRobin/iaas-collaboratif Github repository]<br />
<br />
[https://waffle.io/EudesRobin/iaas-collaboratif Waffle.io]<br />
<br />
= Planning =<br />
<br />
[[File:gantt_iaas.png|center|thumb|1000px|Preliminary Gantt chart]]<br />
<br />
=== Week 1: January 25th - January 31th ===<br />
* Getting familiar with Docker (for some of the group members)<br />
* Fix Docker's DNS issue using public network (wifi-campus/eduroam)<br />
* Contacting our supervisors<br />
* First thoughts on this project, what we could do<br />
* Redaction of specifications, creation of architecture diagrams<br />
* Create scripts that start/stop containers automatically (some modifications still need to be done)<br />
<br />
=== Week 2: February 1st - February 7th ===<br />
* Manage and limit space disk usage of each container, limit resources allocation at containers' launch.<br />
** CPU and memory allocation: ok<br />
** Docker doesn't seem to implement easy way to limit container's disk usage: implementing a watchdog (script) which will check container's disk usage and stop those that exceed a limit<br />
* Think about restricted access to Docker containers: for the moment, providers are admin and can easily access to containers<br />
* See how instances can easily give their network information to coordinator <br />
* Get familiar with Shinken and study the possibilities<br />
* Speficication of technologies used<br />
* End of specification redaction + feedback from tutors<br />
* Start to work on Meteor-AngularJS tutorials<br />
* Configure a personal VM for the frontend & setup meteor-angular on it<br />
<br />
=== Week 3: February 8th - February 14th ===<br />
* '''Objective for this week:''' get a prototype that contains a basic front-end which make it possible to launch remote Docker instance.<br />
* Container deployment: <br />
** Deploy all containers on the same network: that allows us to connect to the instances from the coordinator<br />
** Create user on host: will be used to connect ourselves in ssh from coordinator instance to host and launch deployment scripts<br />
** Create script that totally automatize user creation, images creation and build, coordinator's and shinken's containers launch<br />
* At the end of the week, the prototype is working: we can launch an instance an a provider machine from the front-end. We still need to establish and test the connection between a client and his instance. We have a good cornerstone of our project yet.<br />
<br />
<br />
=== Week 4: February 15th - February 21th ===<br />
* Try to establish connection between a client and his container<br />
* Continue client/provider's web page development on front-end<br />
<br />
=What is Docker?=<br />
Docker allows you to package an application with all of its dependencies into a standardized unit for software development. <br />
Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in. <br />
<br />
'''Lightweight:'''<br />
Containers running on a single machine all share the same operating system kernel so they start instantly and make more efficient use of RAM. Images are constructed from layered filesystems so they can share common files, making disk usage and image downloads much more efficient.<br />
<br />
'''Open:'''<br />
Docker containers are based on open standards allowing containers to run on all major Linux distributions and Microsoft operating systems with support for every infrastructure.<br />
<br />
'''Secure:'''<br />
Containers isolate applications from each other and the underlying infrastructure while providing an added layer of protection for the application.<br />
<br />
==How is this different from virtual machines?==<br />
[[File:VM_vsContainer.png|200px|thumb|Virtual machines]][[File:Container_vsVM.png|200px|thumb|Docker containers]]<br />
<br />
Containers have similar resource isolation and allocation benefits as virtual machines but a different architectural approach allows them to be much more portable and efficient. <br />
<br />
'''Virtual Machines:'''<br />
Each virtual machine includes the application, the necessary binaries and libraries and an entire guest operating system - all of which may be tens of GBs in size.<br />
<br />
'''Containers:'''<br />
Containers include the application and all of its dependencies, but share the kernel with other containers. They run as an isolated process in userspace on the host operating system. They’re also not tied to any specific infrastructure – Docker containers run on any computer, on any infrastructure and in any cloud.<br />
<br />
==How does this help you build better software?==<br />
When your app is in Docker containers, you don’t have to worry about setting up and maintaining different environments or different tooling for each language. Focus on creating new features, fixing issues and shipping software.<br />
<br />
'''Accelerate Developer Onboarding:'''<br />
Stop wasting hours trying to setup developer environments, spin up new instances and make copies of production code to run locally. With Docker, you can easily take copies of your live environment and run on any new endpoint running Docker.<br />
<br />
'''Empower Developer Creativity:'''<br />
The isolation capabilities of Docker containers free developers from the worries of using “approved” language stacks and tooling. Developers can use the best language and tools for their application service without worrying about causing conflict issues.<br />
<br />
'''Eliminate Environment Inconsistencies:'''<br />
By packaging up the application with its configs and dependencies together and shipping as a container, the application will always work as designed locally, on another machine, in test or production. No more worries about having to install the same configs into a different environment.<br />
<br />
==Easily Share and Collaborate on Applications==<br />
<br />
Docker creates a common framework for developers and sysadmins to work together on distributed applications<br />
<br />
'''Distribute and share content:'''<br />
Store, distribute and manage your Docker images in your Docker Hub with your team. Image updates, changes and history are automatically shared across your organization.<br />
<br />
'''Simply share your application with others:'''<br />
Ship one or many containers to others or downstream service teams without worrying about different environment dependencies creating issues with your application. Other teams can easily link to or test against your app without having to learn or worry about how it works.<br />
<br />
==Ship More Software Faster==<br />
<br />
Docker allows you to dynamically change your application like never before from adding new capabilities, scaling out services to quickly changing problem areas.<br />
<br />
'''Ship 7X More:'''<br />
Docker users on average ship software 7X more after deploying Docker in their environment. More frequent updates provide more value to your customers faster.<br />
<br />
'''Quickly Scale:'''<br />
Docker containers spin up and down in seconds making it easy to scale an application service at any time to satisfy peak customer demand, then just as easily spin down those containers to only use the resources you need when you need it<br />
<br />
'''Easily Remediate Issues:'''<br />
Docker make it easy to identify issues and isolate the problem container, quickly roll back to make the necessary changes then push the updated container into production. The isolation between containers make these changes less disruptive than traditional software models.<br />
<br />
<br />
= System Architecture =<br />
== Containers allocation ==<br />
[[File:Infrastructure_globale.png|center|thumb|1000px|Global infrastructure]]<br />
<br />
== SSH connections to allocated containers ==<br />
[[File:Infra_generale_network.png|center|thumb|1000px|Network global infrastructure]] <br />
<br />
[[File:Legend_infra.png|center|thumb|1000px|Caption]]<br />
<br />
== Coordinator and Frontend details ==<br />
<br />
[[File:Coordinator.png]][[File:Frontend.png]]<br />
<br />
= Containers automatic deployment =<br />
<br />
The aim of this part is to automatize the containers deployment on provider side. This includes launching coordinator instance and monitoring instance (shinken). The coordinator instance will allow us to launch new containers and establish the link between clients et their containers.<br />
<br />
[[File:Provider_functioning.png|center|thumb|1000px|Provider functioning]]<br />
<br />
== Build and run ==<br />
<br />
'''First step: user creation'''<br />
<br />
Since we can only interact with the coordinator instance from the front-end, we need a way to launch new container. It's not possible to do so from a container, and that task need to be done from the host. That's why the first step is to create a new user on provider machine we will use to launch new containers or stop them. The moment it is done, we deploy necessary scripts in this user's home. Those scripts are necessary to launch and stop new containers. It is simpler for us to do so than transferring those files from the coordinator to the host when the connection is established.<br />
<br />
'''Second step: images creation'''<br />
<br />
Then, the second step consists in building coordinator and monitoring (shinken) images. To do so we use Dockerfile that allow us to build a container containing all we need. The coordinator instance just contains a ssh web-server. That container exposes it's port 22 and will be used as a jump host to connect the front-end/clients to the other instances.<br />
<br />
'''Third step: coordinator and monitoring instance deployment'''<br />
<br />
Finally, when the images are successfully built, we can run these containers on Docker deamon. We are now able to connect the front-end to the coordinator instance and deploy instances.<br />
<br />
== Resources management ==<br />
<br />
Docker already provides some functionalities which allow us to restrict CPU and memory usage. However, we needed to implement some functionalities ourselves like space disk usage and bandwidth restriction.<br />
<br />
'''CPU:''' To restrict CPU usage, we just need to know the hyper-threading coefficient and remember which CPU is already used. There is a Docker option we can use while launching container that allow us to choose which CPU the container will use to run. <br />
The example below shows how this works with 4 CPU (and hyper-threading coefficient is 2).<br />
<br />
[[File:CPUShare.png|center|thumb|1000px|CPU share]]<br />
<br />
<br />
'''Memory:''' While launching a container, we set memory soft limit as the value required by the client and the hard limit is set has the maximum memory provided. In doing so, a container can use more memory that his soft limit. But if several containers are running on the same host, Docker will ensure that each container doesn't consume more memory than his soft limit.<br />
<br />
<br />
'''Disk:''' Docker doesn't seem to provide a functionality to restrict disk usage. And yet, it's really important for us to make sure that a client will not use to much space disk of the provider. To do so, we implemented a watchdog that check every 30 seconds the disk usage of each container and stop them if they reach the limit defined by the provider. We also use that watchdog to inspect and save container's information that will be used on the front-end to display container's state and space disk usage. Thanks to that, clients will know if they are about to reach the limit.<br />
<br />
<br />
'''Bandwidth:''' Since all the containers run on the same Docker network, we are able to use Wondershaper to set a limit for bandwidth usage. Then, Docker takes care to divide equitably the available bandwidth to each container.<br />
<br />
= Useful links =<br />
<br />
* [https://gist.github.com/jexchan/2351996 Multiple SSH keys for github]<br />
* [https://help.github.com/articles/changing-a-remote-s-url/ Switch https to ssh - remote url github]<br />
* [https://docs.docker.com/ Docker official website]<br />
* [http://2.bp.blogspot.com/-ZGXYBT4l9II/U5BFJwe_jWI/AAAAAAAAGB4/-Le5-NavlGg/s1600/docker-cycle.png Docker cycle]<br />
* [https://www.wanadev.fr/tuto-debuter-et-comprendre-docker/ Understand how Docker works]<br />
* [http://www.occitech.fr/blog/2014/10/tuto-docker-hello-world/ Docker tutorial - Hello world (understand basic commands)]<br />
* [https://robinwinslow.uk/2014/08/27/fix-docker-networking/ Fix Docker's DNS issue with public network]<br />
* [https://wiki.gentoo.org/wiki/SSH_jump_host SSH Jump Host]<br />
* [http://www.angular-meteor.com/ Angular Meteor official website]<br />
* [https://www.mongodb.org/ MongoDB, the database used]<br />
* [https://github.com/aldeed/meteor-collection2 Collection2 - A Meteor package that allows you to attach a schema to a Mongo.Collection]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Projets-2015-2016-IaaS_Docker&diff=27202Projets-2015-2016-IaaS Docker2016-02-17T23:31:25Z<p>Malek-Hadi.Mammar: /* Build and run */</p>
<hr />
<div>= Project presentation =<br />
== Introduction ==<br />
<br />
The objective of this project is to allow a user group (member) to pool their laptops or desktop in order to calculate big data of few users. To do so, the solution should work with Docker to virtualize user machines and control the use of resources of each machine.<br />
<br />
Project under GPLv3 licence : https://www.gnu.org/licenses/gpl-3.0.fr.html<br />
<br />
== The team ==<br />
'''RICM5 students''' <br />
<br />
* EUDES Robin<br />
* DAMOTTE Alan<br />
* BARTHELEMY Romain<br />
* MAMMAR Malek<br />
* GUO Kai<br />
<br />
'''DUT Students'''<br />
<br />
* BONNARD Loïc<br />
* CAPERAN Théo<br />
<br />
'''Supervisors'''<br />
Pierre-Yves Gibello (Linagora), Vincent Zurczak (Linagora), Didier Donsez <br />
<br />
== Deliverables ==<br />
[https://github.com/EudesRobin/iaas-collaboratif Github repository]<br />
<br />
[https://waffle.io/EudesRobin/iaas-collaboratif Waffle.io]<br />
<br />
= Planning =<br />
<br />
[[File:gantt_iaas.png|center|thumb|1000px|Preliminary Gantt chart]]<br />
<br />
=== Week 1: January 25th - January 31th ===<br />
* Getting familiar with Docker (for some of the group members)<br />
* Fix Docker's DNS issue using public network (wifi-campus/eduroam)<br />
* Contacting our supervisors<br />
* First thoughts on this project, what we could do<br />
* Redaction of specifications, creation of architecture diagrams<br />
* Create scripts that start/stop containers automatically (some modifications still need to be done)<br />
<br />
=== Week 2: February 1st - February 7th ===<br />
* Manage and limit space disk usage of each container, limit resources allocation at containers' launch.<br />
** CPU and memory allocation: ok<br />
** Docker doesn't seem to implement easy way to limit container's disk usage: implementing a watchdog (script) which will check container's disk usage and stop those that exceed a limit<br />
* Think about restricted access to Docker containers: for the moment, providers are admin and can easily access to containers<br />
* See how instances can easily give their network information to coordinator <br />
* Get familiar with Shinken and study the possibilities<br />
* Speficication of technologies used<br />
* End of specification redaction + feedback from tutors<br />
* Start to work on Meteor-AngularJS tutorials<br />
* Configure a personal VM for the frontend & setup meteor-angular on it<br />
<br />
=== Week 3: February 8th - February 14th ===<br />
* '''Objective for this week:''' get a prototype that contains a basic front-end which make it possible to launch remote Docker instance.<br />
* Container deployment: <br />
** Deploy all containers on the same network: that allows us to connect to the instances from the coordinator<br />
** Create user on host: will be used to connect ourselves in ssh from coordinator instance to host and launch deployment scripts<br />
** Create script that totally automatize user creation, images creation and build, coordinator's and shinken's containers launch<br />
* At the end of the week, the prototype is working: we can launch an instance an a provider machine from the front-end. We still need to establish and test the connection between a client and his instance. We have a good cornerstone of our project yet.<br />
<br />
<br />
=== Week 4: February 15th - February 21th ===<br />
* Try to establish connection between a client and his container<br />
* Continue client/provider's web page development on front-end<br />
<br />
=What is Docker?=<br />
Docker allows you to package an application with all of its dependencies into a standardized unit for software development. <br />
Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in. <br />
<br />
'''Lightweight:'''<br />
Containers running on a single machine all share the same operating system kernel so they start instantly and make more efficient use of RAM. Images are constructed from layered filesystems so they can share common files, making disk usage and image downloads much more efficient.<br />
<br />
'''Open:'''<br />
Docker containers are based on open standards allowing containers to run on all major Linux distributions and Microsoft operating systems with support for every infrastructure.<br />
<br />
'''Secure:'''<br />
Containers isolate applications from each other and the underlying infrastructure while providing an added layer of protection for the application.<br />
<br />
==How is this different from virtual machines?==<br />
[[File:VM_vsContainer.png|200px|thumb|Virtual machines]][[File:Container_vsVM.png|200px|thumb|Docker containers]]<br />
<br />
Containers have similar resource isolation and allocation benefits as virtual machines but a different architectural approach allows them to be much more portable and efficient. <br />
<br />
'''Virtual Machines:'''<br />
Each virtual machine includes the application, the necessary binaries and libraries and an entire guest operating system - all of which may be tens of GBs in size.<br />
<br />
'''Containers:'''<br />
Containers include the application and all of its dependencies, but share the kernel with other containers. They run as an isolated process in userspace on the host operating system. They’re also not tied to any specific infrastructure – Docker containers run on any computer, on any infrastructure and in any cloud.<br />
<br />
==How does this help you build better software?==<br />
When your app is in Docker containers, you don’t have to worry about setting up and maintaining different environments or different tooling for each language. Focus on creating new features, fixing issues and shipping software.<br />
<br />
'''Accelerate Developer Onboarding:'''<br />
Stop wasting hours trying to setup developer environments, spin up new instances and make copies of production code to run locally. With Docker, you can easily take copies of your live environment and run on any new endpoint running Docker.<br />
<br />
'''Empower Developer Creativity:'''<br />
The isolation capabilities of Docker containers free developers from the worries of using “approved” language stacks and tooling. Developers can use the best language and tools for their application service without worrying about causing conflict issues.<br />
<br />
'''Eliminate Environment Inconsistencies:'''<br />
By packaging up the application with its configs and dependencies together and shipping as a container, the application will always work as designed locally, on another machine, in test or production. No more worries about having to install the same configs into a different environment.<br />
<br />
==Easily Share and Collaborate on Applications==<br />
<br />
Docker creates a common framework for developers and sysadmins to work together on distributed applications<br />
<br />
'''Distribute and share content:'''<br />
Store, distribute and manage your Docker images in your Docker Hub with your team. Image updates, changes and history are automatically shared across your organization.<br />
<br />
'''Simply share your application with others:'''<br />
Ship one or many containers to others or downstream service teams without worrying about different environment dependencies creating issues with your application. Other teams can easily link to or test against your app without having to learn or worry about how it works.<br />
<br />
==Ship More Software Faster==<br />
<br />
Docker allows you to dynamically change your application like never before from adding new capabilities, scaling out services to quickly changing problem areas.<br />
<br />
'''Ship 7X More:'''<br />
Docker users on average ship software 7X more after deploying Docker in their environment. More frequent updates provide more value to your customers faster.<br />
<br />
'''Quickly Scale:'''<br />
Docker containers spin up and down in seconds making it easy to scale an application service at any time to satisfy peak customer demand, then just as easily spin down those containers to only use the resources you need when you need it<br />
<br />
'''Easily Remediate Issues:'''<br />
Docker make it easy to identify issues and isolate the problem container, quickly roll back to make the necessary changes then push the updated container into production. The isolation between containers make these changes less disruptive than traditional software models.<br />
<br />
<br />
= System Architecture =<br />
== Containers allocation ==<br />
[[File:Infrastructure_globale.png|center|thumb|1000px|Global infrastructure]]<br />
<br />
== SSH connections to allocated containers ==<br />
[[File:Infra_generale_network.png|center|thumb|1000px|Network global infrastructure]] <br />
<br />
[[File:Legend_infra.png|center|thumb|1000px|Caption]]<br />
<br />
== Coordinator and Frontend details ==<br />
<br />
[[File:Coordinator.png]][[File:Frontend.png]]<br />
<br />
= Containers automatic deployment =<br />
<br />
The aim of this part is to automatize the containers deployment on provider side. This includes launching coordinator instance and monitoring instance (shinken). The coordinator instance will allow us to launch new containers and establish the link between clients et their containers.<br />
<br />
[[File:Provider_functioning.png|center|thumb|1000px|Provider functioning]]<br />
<br />
== Build and run ==<br />
<br />
'''First step: user creation'''<br />
<br />
Since we can interact only with the coordinator instance from the front-end, we need a way to launch new container. It's not possible to do so from a container, and that task need to be done from the host. That's why the first step is to create a new user on provider machine we will use to launch new containers or stop them. The moment it is done, we deploy necessary scripts in this user's home. Those scripts are necessary to launch and stop new containers. It is simpler for us to do so than transferring those files from the coordinator to the host when the connection is established.<br />
<br />
'''Second step: images creation'''<br />
<br />
Then, the second step consists in building coordinator and monitoring (shinken) images. To do so we use Dockerfile that allow us to build a container containing all we need. The coordinator instance just contains a ssh web-server. That container exposes it's port 22 and will be used as a jump host to connect the front-end/clients to the other instances.<br />
<br />
'''Third step: coordinator and monitoring instance deployment'''<br />
<br />
Finally, when the images are successfully built, we can run these containers on Docker deamon. We are now able to connect the front-end to the coordinator instance and deploy instances.<br />
<br />
== Resources management ==<br />
<br />
Docker already provides some functionalities which allow us to restrict CPU and memory usage. However, we needed to implement some functionalities ourselves like space disk usage and bandwidth restriction.<br />
<br />
'''CPU:''' To restrict CPU usage, we just need to know the hyper-threading coefficient and remember which CPU is already used. There is a Docker option we can use while launching container that allow us to choose which CPU the container will use to run. <br />
The example below shows how this works with 4 CPU (and hyper-threading coefficient is 2).<br />
<br />
[[File:CPUShare.png|center|thumb|1000px|CPU share]]<br />
<br />
<br />
'''Memory:''' While launching a container, we set memory soft limit as the value required by the client and the hard limit is set has the maximum memory provided. In doing so, a container can use more memory that his soft limit. But if several containers are running on the same host, Docker will ensure that each container doesn't consume more memory than his soft limit.<br />
<br />
<br />
'''Disk:''' Docker doesn't seem to provide a functionality to restrict disk usage. And yet, it's really important for us to make sure that a client will not use to much space disk of the provider. To do so, we implemented a watchdog that check every 30 seconds the disk usage of each container and stop them if they reach the limit defined by the provider. We also use that watchdog to inspect and save container's information that will be used on the front-end to display container's state and space disk usage. Thanks to that, clients will know if they are about to reach the limit.<br />
<br />
<br />
'''Bandwidth:''' Since all the containers run on the same Docker network, we are able to use Wondershaper to set a limit for bandwidth usage. Then, Docker takes care to divide equitably the available bandwidth to each container.<br />
<br />
= Useful links =<br />
<br />
* [https://gist.github.com/jexchan/2351996 Multiple SSH keys for github]<br />
* [https://help.github.com/articles/changing-a-remote-s-url/ Switch https to ssh - remote url github]<br />
* [https://docs.docker.com/ Docker official website]<br />
* [http://2.bp.blogspot.com/-ZGXYBT4l9II/U5BFJwe_jWI/AAAAAAAAGB4/-Le5-NavlGg/s1600/docker-cycle.png Docker cycle]<br />
* [https://www.wanadev.fr/tuto-debuter-et-comprendre-docker/ Understand how Docker works]<br />
* [http://www.occitech.fr/blog/2014/10/tuto-docker-hello-world/ Docker tutorial - Hello world (understand basic commands)]<br />
* [https://robinwinslow.uk/2014/08/27/fix-docker-networking/ Fix Docker's DNS issue with public network]<br />
* [https://wiki.gentoo.org/wiki/SSH_jump_host SSH Jump Host]<br />
* [http://www.angular-meteor.com/ Angular Meteor official website]<br />
* [https://www.mongodb.org/ MongoDB, the database used]<br />
* [https://github.com/aldeed/meteor-collection2 Collection2 - A Meteor package that allows you to attach a schema to a Mongo.Collection]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Projets-2015-2016-IaaS_Docker&diff=27201Projets-2015-2016-IaaS Docker2016-02-17T23:16:10Z<p>Malek-Hadi.Mammar: /* Build and run */</p>
<hr />
<div>= Project presentation =<br />
== Introduction ==<br />
<br />
The objective of this project is to allow a user group (member) to pool their laptops or desktop in order to calculate big data of few users. To do so, the solution should work with Docker to virtualize user machines and control the use of resources of each machine.<br />
<br />
Project under GPLv3 licence : https://www.gnu.org/licenses/gpl-3.0.fr.html<br />
<br />
== The team ==<br />
'''RICM5 students''' <br />
<br />
* EUDES Robin<br />
* DAMOTTE Alan<br />
* BARTHELEMY Romain<br />
* MAMMAR Malek<br />
* GUO Kai<br />
<br />
'''DUT Students'''<br />
<br />
* BONNARD Loïc<br />
* CAPERAN Théo<br />
<br />
'''Supervisors'''<br />
Pierre-Yves Gibello (Linagora), Vincent Zurczak (Linagora), Didier Donsez <br />
<br />
== Deliverables ==<br />
[https://github.com/EudesRobin/iaas-collaboratif Github repository]<br />
<br />
[https://waffle.io/EudesRobin/iaas-collaboratif Waffle.io]<br />
<br />
= Planning =<br />
<br />
[[File:gantt_iaas.png|center|thumb|1000px|Preliminary Gantt chart]]<br />
<br />
=== Week 1: January 25th - January 31th ===<br />
* Getting familiar with Docker (for some of the group members)<br />
* Fix Docker's DNS issue using public network (wifi-campus/eduroam)<br />
* Contacting our supervisors<br />
* First thoughts on this project, what we could do<br />
* Redaction of specifications, creation of architecture diagrams<br />
* Create scripts that start/stop containers automatically (some modifications still need to be done)<br />
<br />
=== Week 2: February 1st - February 7th ===<br />
* Manage and limit space disk usage of each container, limit resources allocation at containers' launch.<br />
** CPU and memory allocation: ok<br />
** Docker doesn't seem to implement easy way to limit container's disk usage: implementing a watchdog (script) which will check container's disk usage and stop those that exceed a limit<br />
* Think about restricted access to Docker containers: for the moment, providers are admin and can easily access to containers<br />
* See how instances can easily give their network information to coordinator <br />
* Get familiar with Shinken and study the possibilities<br />
* Speficication of technologies used<br />
* End of specification redaction + feedback from tutors<br />
* Start to work on Meteor-AngularJS tutorials<br />
* Configure a personal VM for the frontend & setup meteor-angular on it<br />
<br />
=== Week 3: February 8th - February 14th ===<br />
* '''Objective for this week:''' get a prototype that contains a basic front-end which make it possible to launch remote Docker instance.<br />
* Container deployment: <br />
** Deploy all containers on the same network: that allows us to connect to the instances from the coordinator<br />
** Create user on host: will be used to connect ourselves in ssh from coordinator instance to host and launch deployment scripts<br />
** Create script that totally automatize user creation, images creation and build, coordinator's and shinken's containers launch<br />
* At the end of the week, the prototype is working: we can launch an instance an a provider machine from the front-end. We still need to establish and test the connection between a client and his instance. We have a good cornerstone of our project yet.<br />
<br />
<br />
=== Week 4: February 15th - February 21th ===<br />
* Try to establish connection between a client and his container<br />
* Continue client/provider's web page development on front-end<br />
<br />
=What is Docker?=<br />
Docker allows you to package an application with all of its dependencies into a standardized unit for software development. <br />
Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in. <br />
<br />
'''Lightweight:'''<br />
Containers running on a single machine all share the same operating system kernel so they start instantly and make more efficient use of RAM. Images are constructed from layered filesystems so they can share common files, making disk usage and image downloads much more efficient.<br />
<br />
'''Open:'''<br />
Docker containers are based on open standards allowing containers to run on all major Linux distributions and Microsoft operating systems with support for every infrastructure.<br />
<br />
'''Secure:'''<br />
Containers isolate applications from each other and the underlying infrastructure while providing an added layer of protection for the application.<br />
<br />
==How is this different from virtual machines?==<br />
[[File:VM_vsContainer.png|200px|thumb|Virtual machines]][[File:Container_vsVM.png|200px|thumb|Docker containers]]<br />
<br />
Containers have similar resource isolation and allocation benefits as virtual machines but a different architectural approach allows them to be much more portable and efficient. <br />
<br />
'''Virtual Machines:'''<br />
Each virtual machine includes the application, the necessary binaries and libraries and an entire guest operating system - all of which may be tens of GBs in size.<br />
<br />
'''Containers:'''<br />
Containers include the application and all of its dependencies, but share the kernel with other containers. They run as an isolated process in userspace on the host operating system. They’re also not tied to any specific infrastructure – Docker containers run on any computer, on any infrastructure and in any cloud.<br />
<br />
==How does this help you build better software?==<br />
When your app is in Docker containers, you don’t have to worry about setting up and maintaining different environments or different tooling for each language. Focus on creating new features, fixing issues and shipping software.<br />
<br />
'''Accelerate Developer Onboarding:'''<br />
Stop wasting hours trying to setup developer environments, spin up new instances and make copies of production code to run locally. With Docker, you can easily take copies of your live environment and run on any new endpoint running Docker.<br />
<br />
'''Empower Developer Creativity:'''<br />
The isolation capabilities of Docker containers free developers from the worries of using “approved” language stacks and tooling. Developers can use the best language and tools for their application service without worrying about causing conflict issues.<br />
<br />
'''Eliminate Environment Inconsistencies:'''<br />
By packaging up the application with its configs and dependencies together and shipping as a container, the application will always work as designed locally, on another machine, in test or production. No more worries about having to install the same configs into a different environment.<br />
<br />
==Easily Share and Collaborate on Applications==<br />
<br />
Docker creates a common framework for developers and sysadmins to work together on distributed applications<br />
<br />
'''Distribute and share content:'''<br />
Store, distribute and manage your Docker images in your Docker Hub with your team. Image updates, changes and history are automatically shared across your organization.<br />
<br />
'''Simply share your application with others:'''<br />
Ship one or many containers to others or downstream service teams without worrying about different environment dependencies creating issues with your application. Other teams can easily link to or test against your app without having to learn or worry about how it works.<br />
<br />
==Ship More Software Faster==<br />
<br />
Docker allows you to dynamically change your application like never before from adding new capabilities, scaling out services to quickly changing problem areas.<br />
<br />
'''Ship 7X More:'''<br />
Docker users on average ship software 7X more after deploying Docker in their environment. More frequent updates provide more value to your customers faster.<br />
<br />
'''Quickly Scale:'''<br />
Docker containers spin up and down in seconds making it easy to scale an application service at any time to satisfy peak customer demand, then just as easily spin down those containers to only use the resources you need when you need it<br />
<br />
'''Easily Remediate Issues:'''<br />
Docker make it easy to identify issues and isolate the problem container, quickly roll back to make the necessary changes then push the updated container into production. The isolation between containers make these changes less disruptive than traditional software models.<br />
<br />
<br />
= System Architecture =<br />
== Containers allocation ==<br />
[[File:Infrastructure_globale.png|center|thumb|1000px|Global infrastructure]]<br />
<br />
== SSH connections to allocated containers ==<br />
[[File:Infra_generale_network.png|center|thumb|1000px|Network global infrastructure]] <br />
<br />
[[File:Legend_infra.png|center|thumb|1000px|Caption]]<br />
<br />
== Coordinator and Frontend details ==<br />
<br />
[[File:Coordinator.png]][[File:Frontend.png]]<br />
<br />
= Containers automatic deployment =<br />
<br />
The aim of this part is to automatize the containers deployment on provider side. This includes launching coordinator instance and monitoring instance (shinken). The coordinator instance will allow us to launch new containers and establish the link between clients et their containers.<br />
<br />
[[File:Provider_functioning.png|center|thumb|1000px|Provider functioning]]<br />
<br />
== Build and run ==<br />
<br />
'''First step: user creation'''<br />
<br />
Since we can interact only with the coordinator instance from the front-end, we need a way to launch new container. It's not possible to do so from a container, and that task need to be done from the host. That's why the first step is to create a new user on provider machine we will use to launch new containers or stop them. The moment it is done, we deploy necessary scripts in this user's home. Those scripts are necessary to launch and stop new containers. It is simpler for us to do so than transferring those files from the coordinator to the host when the connection is established.<br />
<br />
'''Second step: images creation'''<br />
<br />
Then, the second step consists in building coordinator and monitoring (shinken) images. To do so we use Dockerfile that allow us to build a container containing all we need. The coordinator instance just contains a ssh web-server. That container exposes it's port 22 and will be used has a jump host to connect the front-end/clients to the other instances.<br />
<br />
'''Third step: coordinator and monitoring instance deployment'''<br />
<br />
Finally, when the images are successfully built, we can run these containers on Docker deamon. We are now able to connect the front-end to the coordinator instance and deploy instances.<br />
<br />
== Resources management ==<br />
<br />
Docker already provides some functionalities which allow us to restrict CPU and memory usage. However, we needed to implement some functionalities ourselves like space disk usage and bandwidth restriction.<br />
<br />
'''CPU:''' To restrict CPU usage, we just need to know the hyper-threading coefficient and remember which CPU is already used. There is a Docker option we can use while launching container that allow us to choose which CPU the container will use to run. <br />
The example below shows how this works with 4 CPU (and hyper-threading coefficient is 2).<br />
<br />
[[File:CPUShare.png|center|thumb|1000px|CPU share]]<br />
<br />
<br />
'''Memory:''' While launching a container, we set memory soft limit as the value required by the client and the hard limit is set has the maximum memory provided. In doing so, a container can use more memory that his soft limit. But if several containers are running on the same host, Docker will ensure that each container doesn't consume more memory than his soft limit.<br />
<br />
<br />
'''Disk:''' Docker doesn't seem to provide a functionality to restrict disk usage. And yet, it's really important for us to make sure that a client will not use to much space disk of the provider. To do so, we implemented a watchdog that check every 30 seconds the disk usage of each container and stop them if they reach the limit defined by the provider. We also use that watchdog to inspect and save container's information that will be used on the front-end to display container's state and space disk usage. Thanks to that, clients will know if they are about to reach the limit.<br />
<br />
<br />
'''Bandwidth:''' Since all the containers run on the same Docker network, we are able to use Wondershaper to set a limit for bandwidth usage. Then, Docker takes care to divide equitably the available bandwidth to each container.<br />
<br />
= Useful links =<br />
<br />
* [https://gist.github.com/jexchan/2351996 Multiple SSH keys for github]<br />
* [https://help.github.com/articles/changing-a-remote-s-url/ Switch https to ssh - remote url github]<br />
* [https://docs.docker.com/ Docker official website]<br />
* [http://2.bp.blogspot.com/-ZGXYBT4l9II/U5BFJwe_jWI/AAAAAAAAGB4/-Le5-NavlGg/s1600/docker-cycle.png Docker cycle]<br />
* [https://www.wanadev.fr/tuto-debuter-et-comprendre-docker/ Understand how Docker works]<br />
* [http://www.occitech.fr/blog/2014/10/tuto-docker-hello-world/ Docker tutorial - Hello world (understand basic commands)]<br />
* [https://robinwinslow.uk/2014/08/27/fix-docker-networking/ Fix Docker's DNS issue with public network]<br />
* [https://wiki.gentoo.org/wiki/SSH_jump_host SSH Jump Host]<br />
* [http://www.angular-meteor.com/ Angular Meteor official website]<br />
* [https://www.mongodb.org/ MongoDB, the database used]<br />
* [https://github.com/aldeed/meteor-collection2 Collection2 - A Meteor package that allows you to attach a schema to a Mongo.Collection]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Projets-2015-2016-IaaS_Docker&diff=27200Projets-2015-2016-IaaS Docker2016-02-17T23:14:48Z<p>Malek-Hadi.Mammar: /* Build and run */</p>
<hr />
<div>= Project presentation =<br />
== Introduction ==<br />
<br />
The objective of this project is to allow a user group (member) to pool their laptops or desktop in order to calculate big data of few users. To do so, the solution should work with Docker to virtualize user machines and control the use of resources of each machine.<br />
<br />
Project under GPLv3 licence : https://www.gnu.org/licenses/gpl-3.0.fr.html<br />
<br />
== The team ==<br />
'''RICM5 students''' <br />
<br />
* EUDES Robin<br />
* DAMOTTE Alan<br />
* BARTHELEMY Romain<br />
* MAMMAR Malek<br />
* GUO Kai<br />
<br />
'''DUT Students'''<br />
<br />
* BONNARD Loïc<br />
* CAPERAN Théo<br />
<br />
'''Supervisors'''<br />
Pierre-Yves Gibello (Linagora), Vincent Zurczak (Linagora), Didier Donsez <br />
<br />
== Deliverables ==<br />
[https://github.com/EudesRobin/iaas-collaboratif Github repository]<br />
<br />
[https://waffle.io/EudesRobin/iaas-collaboratif Waffle.io]<br />
<br />
= Planning =<br />
<br />
[[File:gantt_iaas.png|center|thumb|1000px|Preliminary Gantt chart]]<br />
<br />
=== Week 1: January 25th - January 31th ===<br />
* Getting familiar with Docker (for some of the group members)<br />
* Fix Docker's DNS issue using public network (wifi-campus/eduroam)<br />
* Contacting our supervisors<br />
* First thoughts on this project, what we could do<br />
* Redaction of specifications, creation of architecture diagrams<br />
* Create scripts that start/stop containers automatically (some modifications still need to be done)<br />
<br />
=== Week 2: February 1st - February 7th ===<br />
* Manage and limit space disk usage of each container, limit resources allocation at containers' launch.<br />
** CPU and memory allocation: ok<br />
** Docker doesn't seem to implement easy way to limit container's disk usage: implementing a watchdog (script) which will check container's disk usage and stop those that exceed a limit<br />
* Think about restricted access to Docker containers: for the moment, providers are admin and can easily access to containers<br />
* See how instances can easily give their network information to coordinator <br />
* Get familiar with Shinken and study the possibilities<br />
* Speficication of technologies used<br />
* End of specification redaction + feedback from tutors<br />
* Start to work on Meteor-AngularJS tutorials<br />
* Configure a personal VM for the frontend & setup meteor-angular on it<br />
<br />
=== Week 3: February 8th - February 14th ===<br />
* '''Objective for this week:''' get a prototype that contains a basic front-end which make it possible to launch remote Docker instance.<br />
* Container deployment: <br />
** Deploy all containers on the same network: that allows us to connect to the instances from the coordinator<br />
** Create user on host: will be used to connect ourselves in ssh from coordinator instance to host and launch deployment scripts<br />
** Create script that totally automatize user creation, images creation and build, coordinator's and shinken's containers launch<br />
* At the end of the week, the prototype is working: we can launch an instance an a provider machine from the front-end. We still need to establish and test the connection between a client and his instance. We have a good cornerstone of our project yet.<br />
<br />
<br />
=== Week 4: February 15th - February 21th ===<br />
* Try to establish connection between a client and his container<br />
* Continue client/provider's web page development on front-end<br />
<br />
=What is Docker?=<br />
Docker allows you to package an application with all of its dependencies into a standardized unit for software development. <br />
Docker containers wrap up a piece of software in a complete filesystem that contains everything it needs to run: code, runtime, system tools, system libraries – anything you can install on a server. This guarantees that it will always run the same, regardless of the environment it is running in. <br />
<br />
'''Lightweight:'''<br />
Containers running on a single machine all share the same operating system kernel so they start instantly and make more efficient use of RAM. Images are constructed from layered filesystems so they can share common files, making disk usage and image downloads much more efficient.<br />
<br />
'''Open:'''<br />
Docker containers are based on open standards allowing containers to run on all major Linux distributions and Microsoft operating systems with support for every infrastructure.<br />
<br />
'''Secure:'''<br />
Containers isolate applications from each other and the underlying infrastructure while providing an added layer of protection for the application.<br />
<br />
==How is this different from virtual machines?==<br />
[[File:VM_vsContainer.png|200px|thumb|Virtual machines]][[File:Container_vsVM.png|200px|thumb|Docker containers]]<br />
<br />
Containers have similar resource isolation and allocation benefits as virtual machines but a different architectural approach allows them to be much more portable and efficient. <br />
<br />
'''Virtual Machines:'''<br />
Each virtual machine includes the application, the necessary binaries and libraries and an entire guest operating system - all of which may be tens of GBs in size.<br />
<br />
'''Containers:'''<br />
Containers include the application and all of its dependencies, but share the kernel with other containers. They run as an isolated process in userspace on the host operating system. They’re also not tied to any specific infrastructure – Docker containers run on any computer, on any infrastructure and in any cloud.<br />
<br />
==How does this help you build better software?==<br />
When your app is in Docker containers, you don’t have to worry about setting up and maintaining different environments or different tooling for each language. Focus on creating new features, fixing issues and shipping software.<br />
<br />
'''Accelerate Developer Onboarding:'''<br />
Stop wasting hours trying to setup developer environments, spin up new instances and make copies of production code to run locally. With Docker, you can easily take copies of your live environment and run on any new endpoint running Docker.<br />
<br />
'''Empower Developer Creativity:'''<br />
The isolation capabilities of Docker containers free developers from the worries of using “approved” language stacks and tooling. Developers can use the best language and tools for their application service without worrying about causing conflict issues.<br />
<br />
'''Eliminate Environment Inconsistencies:'''<br />
By packaging up the application with its configs and dependencies together and shipping as a container, the application will always work as designed locally, on another machine, in test or production. No more worries about having to install the same configs into a different environment.<br />
<br />
==Easily Share and Collaborate on Applications==<br />
<br />
Docker creates a common framework for developers and sysadmins to work together on distributed applications<br />
<br />
'''Distribute and share content:'''<br />
Store, distribute and manage your Docker images in your Docker Hub with your team. Image updates, changes and history are automatically shared across your organization.<br />
<br />
'''Simply share your application with others:'''<br />
Ship one or many containers to others or downstream service teams without worrying about different environment dependencies creating issues with your application. Other teams can easily link to or test against your app without having to learn or worry about how it works.<br />
<br />
==Ship More Software Faster==<br />
<br />
Docker allows you to dynamically change your application like never before from adding new capabilities, scaling out services to quickly changing problem areas.<br />
<br />
'''Ship 7X More:'''<br />
Docker users on average ship software 7X more after deploying Docker in their environment. More frequent updates provide more value to your customers faster.<br />
<br />
'''Quickly Scale:'''<br />
Docker containers spin up and down in seconds making it easy to scale an application service at any time to satisfy peak customer demand, then just as easily spin down those containers to only use the resources you need when you need it<br />
<br />
'''Easily Remediate Issues:'''<br />
Docker make it easy to identify issues and isolate the problem container, quickly roll back to make the necessary changes then push the updated container into production. The isolation between containers make these changes less disruptive than traditional software models.<br />
<br />
<br />
= System Architecture =<br />
== Containers allocation ==<br />
[[File:Infrastructure_globale.png|center|thumb|1000px|Global infrastructure]]<br />
<br />
== SSH connections to allocated containers ==<br />
[[File:Infra_generale_network.png|center|thumb|1000px|Network global infrastructure]] <br />
<br />
[[File:Legend_infra.png|center|thumb|1000px|Caption]]<br />
<br />
== Coordinator and Frontend details ==<br />
<br />
[[File:Coordinator.png]][[File:Frontend.png]]<br />
<br />
= Containers automatic deployment =<br />
<br />
The aim of this part is to automatize the containers deployment on provider side. This includes launching coordinator instance and monitoring instance (shinken). The coordinator instance will allow us to launch new containers and establish the link between clients et their containers.<br />
<br />
[[File:Provider_functioning.png|center|thumb|1000px|Provider functioning]]<br />
<br />
== Build and run ==<br />
<br />
'''First step: user creation'''<br />
<br />
Since we can interact only with the coordinator instance from the front-end, we need a way to launch new container. It's not possible to do so from a container, and that task need to be done from the host. That's why the first step is to create a new user on provider machine we will use to launch new containers or stop them. The moment it is done, we deploy necessary scripts in this user's home. That's scripts are necessary to launch and stop new containers. It is simpler for us to do so than transferring those files from the coordinator to the host when the connection is established.<br />
<br />
'''Second step: images creation'''<br />
<br />
Then, the second step consists in building coordinator and monitoring (shinken) images. To do so we use Dockerfile that allow us to build a container containing all we need. The coordinator instance just contains a ssh web-server. That container exposes it's port 22 and will be used has a jump host to connect the front-end/clients to the other instances.<br />
<br />
'''Third step: coordinator and monitoring instance deployment'''<br />
<br />
Finally, when the images are successfully built, we can run these containers on Docker deamon. We are now able to connect the front-end to the coordinator instance and deploy instances.<br />
<br />
== Resources management ==<br />
<br />
Docker already provides some functionalities which allow us to restrict CPU and memory usage. However, we needed to implement some functionalities ourselves like space disk usage and bandwidth restriction.<br />
<br />
'''CPU:''' To restrict CPU usage, we just need to know the hyper-threading coefficient and remember which CPU is already used. There is a Docker option we can use while launching container that allow us to choose which CPU the container will use to run. <br />
The example below shows how this works with 4 CPU (and hyper-threading coefficient is 2).<br />
<br />
[[File:CPUShare.png|center|thumb|1000px|CPU share]]<br />
<br />
<br />
'''Memory:''' While launching a container, we set memory soft limit as the value required by the client and the hard limit is set has the maximum memory provided. In doing so, a container can use more memory that his soft limit. But if several containers are running on the same host, Docker will ensure that each container doesn't consume more memory than his soft limit.<br />
<br />
<br />
'''Disk:''' Docker doesn't seem to provide a functionality to restrict disk usage. And yet, it's really important for us to make sure that a client will not use to much space disk of the provider. To do so, we implemented a watchdog that check every 30 seconds the disk usage of each container and stop them if they reach the limit defined by the provider. We also use that watchdog to inspect and save container's information that will be used on the front-end to display container's state and space disk usage. Thanks to that, clients will know if they are about to reach the limit.<br />
<br />
<br />
'''Bandwidth:''' Since all the containers run on the same Docker network, we are able to use Wondershaper to set a limit for bandwidth usage. Then, Docker takes care to divide equitably the available bandwidth to each container.<br />
<br />
= Useful links =<br />
<br />
* [https://gist.github.com/jexchan/2351996 Multiple SSH keys for github]<br />
* [https://help.github.com/articles/changing-a-remote-s-url/ Switch https to ssh - remote url github]<br />
* [https://docs.docker.com/ Docker official website]<br />
* [http://2.bp.blogspot.com/-ZGXYBT4l9II/U5BFJwe_jWI/AAAAAAAAGB4/-Le5-NavlGg/s1600/docker-cycle.png Docker cycle]<br />
* [https://www.wanadev.fr/tuto-debuter-et-comprendre-docker/ Understand how Docker works]<br />
* [http://www.occitech.fr/blog/2014/10/tuto-docker-hello-world/ Docker tutorial - Hello world (understand basic commands)]<br />
* [https://robinwinslow.uk/2014/08/27/fix-docker-networking/ Fix Docker's DNS issue with public network]<br />
* [https://wiki.gentoo.org/wiki/SSH_jump_host SSH Jump Host]<br />
* [http://www.angular-meteor.com/ Angular Meteor official website]<br />
* [https://www.mongodb.org/ MongoDB, the database used]<br />
* [https://github.com/aldeed/meteor-collection2 Collection2 - A Meteor package that allows you to attach a schema to a Mongo.Collection]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Benchmark_ECOM_2015_GRP5&diff=25527Benchmark ECOM 2015 GRP52015-12-15T10:23:08Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>Evaluation système<br />
------------------<br />
<br />
Introduction <br />
------------<br />
<br />
<br />
JMeter est l’outil que nous utilisons pour l’évaluation de performance de notre site. Nous avons créé 1 scénario de test qui nous pensons reprennent les actions les plus récurrentes dans le cadre d’un site commercial.<br />
Aussi nous avons réalisé des tests de burst sur plusieurs URI de l’API.<br />
<br />
Lors de la création de ces tests nous avons été contraint d’implémenter une authentification dynamique. Ce qui signifie un échange de requête successif permettant l’authentification d’un client ou d’un artisan à la manière OAuth1. <br />
<br />
Afin d’éliminer les contraintes liées à la connectivé et à la limite de bande passante du réseau de la machine executant JMeter, nous avons choisi d’exécuter nos scénarios avec BlazeMeter. Une application web permettant de lancer de manière distribuée un ensemble d’utilisateurs. <br />
En effet après lecture d’un article sur le sujet il semblerait qu’une seule JVM ne soit pas scalable. Tout au moins de manière empirique il s’avère qu’au-dela de 1000 utilisateurs (thread) en parallèle, la multiplication de puissance CPU et d’allocation mémoire n’évolue plus de manière proportionnelle au rendement d’une JVM.<br />
<br />
Description du système :<br />
------------------------<br />
<br />
Notre site web est construit selon le principe de Single page application. Ce qui signifie la présence d’au moins deux entités : une API côté backend et une application cliente en AngularJS/Html côté utilisateur.<br />
L’ensemble de notre packaging Java (Ear = {War, Ejb}) est hébergé sous une même VM accueillant un serveur Glassfish 4.1 mais aussi une base de données Derby.<br />
<br />
La VM est hébergée derrière une Box orange, avec les propriétés suivantes : <br />
<br />
* Bande passante : <br />
* Montante : 300 Mégabytes<br />
* Descendante : 700 Mégabytes<br />
<br />
Capacité alloué a la machine virtuelle : <br />
<br />
* RAM allouée : 4 Go<br />
* HDD alloué : 20 Go<br />
* CPU alloué : 1 Process 4 coeurs (Intel i5 2.5 Ghz)<br />
<br />
<br />
Objectif :<br />
----------<br />
<br />
Le but de nos tests est d’identifier le nombre d’utilisateurs maximum que notre application peut supporter. Une fois trouvé, il s’agira d’identifier le goulot d’étranglement de notre application.<br />
D’ors et déjà nous identifions plusieurs points pouvons limiter notre capacité de charge : <br />
<br />
* La VM se trouvant derrière une Box Orange, il est possible que le débit montant soit limitant, dans une certaine mesure.<br />
<br />
* La Box Orange n’est pas conçu pour supporter une charge importante de requêtes entrante, ce qui constitue un cas limitant.<br />
Par ailleurs, Le choix de d'Apache Derby comme BDD influe certainement sur les performances. Le serveur Glassfish n'a pas été "optimisé", par ailleurs. Nous utilisons pas de système de cache également.<br />
De manière générale, une machine seule se retrouve assez vite saturée.<br />
<br />
* L’utilisation de d’un système de retour en arrière (Rollback) constitue de faite un goulot d’étranglement en raison de l’atomicité des actions affectées du flag @TransactionAttribute. <br />
<br />
<br />
<br />
Scénarios : <br />
-----------<br />
<br />
Plan 1 :<br />
--------<br />
<br />
Notre premier plan de test consiste à effectuer une suite d’actions de basiques communes à un utilisateur normale. Ce dernier effectuerait ses actions dans l’ordre suivant : <br />
<br />
* Visiter la page du site<br />
* Visiter 2 formules<br />
* Ajouter les 2 formules au panier<br />
* Authentification et passage de la commande.<br />
<br />
Propriétés de simulations : <br />
---------------------------<br />
<br />
* Durée de la simulation : 15 min<br />
* Nombre de thread total (user) : 205<br />
* Montée en charge : 300 secondes. Soit ~3 nouveaux utilisateurs toutes les 2 secondes jsuqu’à atteindre les 205 utilisateurs.<br />
* Nombre d’itération : infini<br />
* Nombre de requête par seconde (RPS) : 1<br />
<br />
Remarquons que nous avons délibérarément choisi un RPS de 1, afin d’évaluer la tenue en en charge du site en terme de nombre de clients connectés.<br />
<br />
Identification du point de rupture : <br />
------------------------------------<br />
[[File:Scenario1_1_rps_without_RespTime.png]]<br />
<br />
Sur ce diagramme temporel nous observons en fonction du temps : <br />
<br />
* l’évolution du nombre d’utilisateurs (en bleu), lors de la montée progressive en charge.<br />
* l’évolution du # de requetes total par seconde (en vert)<br />
* l’évolution du # d’erreurs par seconde (en rouge)<br />
<br />
Précisons que la résolution du graphe est de 1 point / 15 secondes. Ce qui signifie que le nombre de Hit/s est une moyenne sur 15 secondes.<br />
<br />
Ce qu’il faut principalement noter sur ce graphe est le décollement de la courbe du taux de Hit/s d’erreurs, à partir de 34 utilisateurs en parallèles effectuant chacun à leur tour 1 requête toute les secondes. <br />
Il s’agit du début de rupture de notre système, puisqu’il se trouve au pied du premier pic (cf figure ci-dessous) d’erreurs culminant à une moyenne de 0.14 Hit/s (moyenne sur 15 échantillons), soit 14% des requêtes générées se sont soldées par une erreur HTTP.<br />
<br />
[[File:Scenario1_1_rps.png]]<br />
<br />
Sur la figure ci-dessus, remarquons la présence de la courbe du temps de réponse moyen, qui dans son évolution globale s’oppose de manière symétrique au pics des erreurs. Rien de plus normal car le serveur ne supportant plus le nombre de clients connectés simultanément, renvoie des erreurs Http avec un temps de réponse court.<br />
<br />
En on peut noter la chute drastique de la courbe verte (= moyenne de Hit/s ayant reçu une réponse Http, même s’il s’agit d’erreurs 500 ou autre) dès l’atteinte du seuil des 205 utilisateurs. Cela signifie que ne reçoit aucune réponse Http et que la connexion au site échoue. <br />
<br />
Cette étude nous a permis de déterminé la charge maximal (sans erreurs) en terme de nombre d’utilisateurs connectés au même moment.<br />
<br />
Plan 2 :<br />
--------<br />
<br />
Nous allons maintenant nous intéresser à une variante du plan de test. Puisque seule la fréquence de requêtes est réévaluée à 50 Rps (initialement à 1).<br />
<br />
[[File:Scenario1_50_rps.png]]<br />
<br />
Nous avons donc conservés les mêmes valeurs de montée en charge, du # d’utilisateurs et de durée d’expérience.<br />
Ce qui est possible d’extraire de ce graphe, est l’allure globale<br />
<br />
Ce qui est notable est l’affolement du système quasi instantané. En zoomant légèrement sur le début de la simulation (cf figure ci-dessous) on peut attester que dès le début de la simulation environs 3 requêtes sur 25 se sont soldées en échec. <br />
<br />
[[File:Scenario1_50_rps_zoom.png]]<br />
<br />
Identification du goulot d’étranglement : <br />
-----------------------------------------<br />
<br />
A l’observation du temps de réponse des différentes requêtes émis en fonction de l’évolution du nombre d’utilisateur, l’action GET /formules est nettement en tête.<br />
<br />
[[File:Endpoints_response_time.png]]<br />
<br />
En effet il s’agit d’une requête retournant l’ensemble des produits contenus en base de données. Elle est exécutée à chaque visite de la page principale du site. <br />
Ce premier goulot d’étranglement est dû à l’absence de pagination limitant le résultat d’une requête Http et donc du temps de réponse moyen.<br />
Voici donc un premier point d’amélioration à apporter à notre prochaine version.<br />
<br />
A l’observation des erreurs retournée par l’API, une attire particulièrement notre attention : javax.ejb.EJBTransactionRolledbackException<br />
Les Rollbacks sont principalement utilisés dans les opérations nécessitant de mettre à jour des informations de manière simultanée. Dans notre cas, elle concerne l’ajout/suppression d’une formule, mais aussi d’un artisan ou d’un client ou d’une commande.<br />
Par exemple la suppression d’un compte artisan nécessite la suppression de l’ensemble de ses formules et produits du catalogue. Cette opération doit être atomique sinon l’intégrité des données ne serait plus garantie<br />
<br />
Ainsi voici le second goulot d’étranglement rencontré qui porte sur l’accès non concurrentiel aux ressources add/delete d’un artisan/client/formule/commande.<br />
<br />
Cette erreur de Rollback signifie un retour vers l’état précédent l’exécution d’une transaction. Elle s’est manifestée au travers de teste de burst sur les endpoint simultané de création/suppression de formule et d’artisan.<br />
<br />
Limitations du système<br />
----------------------<br />
<br />
* L’option https n’a pas été explorée, même si nous avons conscience qu’elle constitue un critère important dans l’interaction avec l’API. En effet, les tokens ne devraient jamais être utilisés en clair mais crypté par une session https. <br />
Cette tâche fait partie des améliorations prévues.<br />
<br />
* Une transaction bancaire dans notre système est traduite par une simple écriture d’entrée dans une table Orders. En effet dans notre système nous supposons qu’une transaction bancaire n’échoue pas. Ce qui implique indirectement que : <br />
les coordonnées bancaires du client sont correctes<br />
la connectivité à l’API bancaire est fiable.<br />
<br />
* Nous n’avons pas implémenté d’entité JMS (Java Message Service. En effet on suppose que le système ne tombe pas en panne au cours d’une validation de commande. Car si tel est le cas, nous n'aurions pas moyen de récupérer l’état avant crash. <br />
Ainsi certaines fonctionnalités telle que les news letters, ou la validation d’un compte client après redirection vers un lien envoyé par mail, sont gérés à l’aide d’un timer.<br />
Enfin l’atomicité de certaines opération tel que la commande est géré par un système de rolling back par un flag de type @TransactionAttribute .</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Benchmark_ECOM_2015_GRP5&diff=25523Benchmark ECOM 2015 GRP52015-12-15T10:20:37Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>Evaluation système<br />
------------------<br />
<br />
Introduction <br />
------------<br />
<br />
<br />
JMeter est l’outil que nous utilisons pour l’évaluation de performance de notre site. Nous avons créé 1 scénario de test qui nous pensons reprennent les actions les plus récurrentes dans le cadre d’un site commercial.<br />
Aussi nous avons réalisé des tests de burst sur plusieurs URI de l’API.<br />
<br />
Lors de la création de ces tests nous avons été contraint d’implémenter une authentification dynamique. Ce qui signifie un échange de requête successif permettant l’authentification d’un client ou d’un artisan à la manière OAuth1. <br />
<br />
Afin d’éliminer les contraintes liées à la connectivé et à la limite de bande passante du réseau de la machine executant JMeter, nous avons choisi d’exécuter nos scénarios avec BlazeMeter. Une application web permettant de lancer de manière distribuée un ensemble d’utilisateurs. <br />
En effet après lecture d’un article sur le sujet il semblerait qu’une seule JVM ne soit pas scalable. Tout au moins de manière empirique il s’avère qu’au-dela de 1000 utilisateurs (thread) en parallèle, la multiplication de puissance CPU et d’allocation mémoire n’évolue plus de manière proportionnelle au rendement d’une JVM.<br />
<br />
Description du système :<br />
------------------------<br />
<br />
Notre site web est construit selon le principe de Single page application. Ce qui signifie la présence d’au moins deux entités : une API côté backend et une application cliente en AngularJS/Html côté utilisateur.<br />
L’ensemble de notre packaging Java (Ear = {War, Ejb}) est hébergé sous une même VM accueillant un serveur Glassfish 4.1 mais aussi une base de données Derby.<br />
<br />
La VM est hébergée derrière une Box orange, avec les propriétés suivantes : <br />
<br />
* Bande passante : <br />
* Montante : 300 Mégabytes<br />
* Descendante : 700 Mégabytes<br />
<br />
Capacité alloué a la machine virtuelle : <br />
<br />
* RAM allouée : 4 Go<br />
* HDD alloué : 20 Go<br />
* CPU alloué : 1 Process 4 coeurs (Intel i5 2.5 Ghz)<br />
<br />
<br />
Objectif :<br />
----------<br />
<br />
Le but de nos tests est d’identifier le nombre d’utilisateurs maximum que notre application peut supporter. Une fois trouvé, il s’agira d’identifier le goulot d’étranglement de notre application.<br />
D’ors et déjà nous identifions plusieurs points pouvons limiter notre capacité de charge : <br />
<br />
* La VM se trouvant derrière une Box Orange, il est possible que le débit montant soit limitant, dans une certaine mesure.<br />
<br />
* La Box Orange n’est pas conçu pour supporter une charge importante de requêtes entrante, ce qui constitue un cas limitant.<br />
Par ailleurs, Le choix de d'Apache Derby comme BDD influe certainement sur les performances. Le serveur Glassfish n'a pas été "optimisé", par ailleurs. Nous utilisons pas de système de cache également.<br />
De manière générale, une machine seule se retrouve assez vite saturée.<br />
<br />
* L’utilisation de d’un système de retour en arrière (Rollback) constitue de faite un goulot d’étranglement en raison de l’atomicité des actions affectées du flag @TransactionAttribute. <br />
<br />
<br />
<br />
Scénarios : <br />
-----------<br />
<br />
Plan 1 :<br />
--------<br />
<br />
Notre premier plan de test consiste à effectuer une suite d’actions de basiques communes à un utilisateur normale. Ce dernier effectuerait ses actions dans l’ordre suivant : <br />
<br />
* Visiter la page du site<br />
* Visiter 2 formules<br />
* Ajouter les 2 formules au panier<br />
* Authentification et passage de la commande.<br />
<br />
Propriétés de simulations : <br />
---------------------------<br />
<br />
* Durée de la simulation : 15 min<br />
* Nombre de thread total (user) : 205<br />
* Montée en charge : 300 secondes. Soit ~3 nouveaux utilisateurs toutes les 2 secondes jsuqu’à atteindre les 205 utilisateurs.<br />
* Nombre d’itération : infini<br />
* Nombre de requête par seconde (RPS) : 1<br />
<br />
Remarquons que nous avons délibérarément choisi un RPS de 1, afin d’évaluer la tenue en en charge du site en terme de nombre de clients connectés.<br />
<br />
Identification du point de rupture : <br />
------------------------------------<br />
[[File:Scenario1_1_rps_without_RespTime.png]]<br />
<br />
Sur ce diagramme temporel nous observons en fonction du temps : <br />
<br />
* l’évolution du nombre d’utilisateurs (en bleu), lors de la montée progressive en charge.<br />
* l’évolution du # de requetes total par seconde (en vert)<br />
* l’évolution du # d’erreurs par seconde (en rouge)<br />
<br />
Précisons que la résolution du graphe est de 1 point / 15 secondes. Ce qui signifie que le nombre de Hit/s est une moyenne sur 15 secondes.<br />
<br />
Ce qu’il faut principalement noter sur ce graphe est le décollement de la courbe du taux de Hit/s d’erreurs, à partir de 34 utilisateurs en parallèles effectuant chacun à leur tour 1 requête toute les secondes. <br />
Il s’agit du début de rupture de notre système, puisqu’il se trouve au pied du premier pic (cf figure ci-dessous) d’erreurs culminant à une moyenne de 0.14 Hit/s (moyenne sur 15 échantillons), soit 14% des requeêtes générées se sont soldées par une erreur HTTP.<br />
<br />
[[File:Scenario1_1_rps.png]]<br />
<br />
Sur la figure ci-dessus, remarquons la présence de la courbe du temps de réponse moyen, qui dans son évolution globale s’oppose de manière symétrique au pics des erreurs. Rien de plus normal car le serveur ne supportant plus le nombre de clients connectés simultanément, renvoie des erreurs Http avec un temps de réponse court.<br />
<br />
En on peut noter la chute drastique de la courbe verte (= moyenne de Hit/s ayant reçu une réponse Http, même s’il s’agit d’erreurs 500 ou autre) dès l’atteinte du seuil des 205 utilisateurs. Cela signifie que ne reçoit aucune réponse Http et que la connexion au site échoue. <br />
<br />
Cette étude nous a premis de determiné la charge maximal (sans erreurs) en terme de nombre d’utilisateurs connectés au même moment.<br />
<br />
Plan 2 :<br />
--------<br />
<br />
Nous allons maintenant nous intéresser à une variante du plan de test. Puisque seule la fréquence de requêtes est réévaluée à 50 Rps (initialement à 1).<br />
<br />
[[File:Scenario1_50_rps.png]]<br />
<br />
Nous avons donc conservés les mêmes valeurs de montée en charge, du # d’utilisateurs et de durée d’expérience.<br />
Ce qui est possible d’extraire de ce graphe, est l’allure globale<br />
<br />
Ce qui est notable est l’affolement du système quasi instantané. En zoomant légèrement sur le début de la simulation (cf figure ci-dessous) on peut attester que dès le début de la simulation environs 3 requêtes sur 25 se sont soldées en échec. <br />
<br />
[[File:Scenario1_50_rps_zoom.png]]<br />
<br />
Identification du goulot d’étranglement : <br />
-----------------------------------------<br />
<br />
A l’observation du temps de réponse des differentes requêtes émisent en fonction de l’évolution du nombre d’utilisateur, l’action GET /formules est nettement en tête.<br />
<br />
[[File:Endpoints_response_time.png]]<br />
<br />
En effet il s’agit d’une requête retournant l’ensemble des produits contenus en base de données. Elle est exécutée à chaque visite de la page principale du site. <br />
Ce premier goulot d’étranglement est dû à l’absence de pagination limitant le résultat d’une requête Http et donc du temps de réponse moyen.<br />
Voici donc un premier point d’amélioration à apporter à notre prochaine version.<br />
<br />
A l’observation des erreurs retournée par l’API, une attire particulièrement notre attention : javax.ejb.EJBTransactionRolledbackException<br />
Les Rollbacks sont principalement utilisés dans les opérations nécessitant de mettre à jour des informations de manière simultanée. Dans notre cas, elle concerne l’ajout/suppression d’une formule, mais aussi d’un artisan ou d’un client ou d’une commande.<br />
Par exemple la suppression d’un compte artisan nécessite la suppression de l’ensemble de ses formules et produits du catalogue. Cette opération doit être atomique sinon l’intégrité des données ne serait plus garantie<br />
<br />
Ainsi voici le second goulot d’étranglement rencontré qui porte sur l’accès non concurrentiel aux ressources add/delete d’un artisan/client/formule/commande.<br />
<br />
Cette erreur de Rollback signifie un retour vers l’état précédent l’éxécution d’une transaction. Elle s’est manifestée au travers de teste de burst sur les endpoint simultané de création/suppression de formule et d’artisan.<br />
<br />
Limitations du système<br />
----------------------<br />
<br />
* L’option https n’a pas été explorée, même si nous avons conscience qu’elle constitue un critère important dans l’intéraction avec l’API. En effet, les tokens ne devraient jamais être utilisés en clair mais crypté par une session https. <br />
Cette tâche fait partie des améliorations prévues.<br />
<br />
* Une transaction bancaire dans notre système est traduite par une simple écriture d’entrée dans une table Orders. En effet dans notre système nous supposons qu’une transaction bancaire n’échoue pas. Ce qui implique indirectement que : <br />
les coordonnées bancaires du client sont correctes<br />
la connectivité à l’API bancaire est fiable.<br />
<br />
* Nous n’avons pas implémenté d’entité JMS (Java Message Service. En effet on suppose que le système ne tombe pas en panne au cours d’une validation de commande. Car si tel est le cas, nous n'aurions pas moyen de récupérer l’état avant crash. <br />
Ainsi certaines fonctionnalités telle que les news letters, ou la validation d’un compte client après redirection vers un lien envoyé par mail, sont gérés à l’aide d’un timer.<br />
Enfin l’atomicité de certaines opération tel que la commande est géré par un système de rolling back par un flag de type @TransactionAttribute .</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Benchmark_ECOM_2015_GRP5&diff=25496Benchmark ECOM 2015 GRP52015-12-14T22:03:37Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>Evaluation système<br />
------------------<br />
<br />
Introduction <br />
------------<br />
<br />
<br />
JMeter est l’outil que nous utilisons pour l’évaluation de performance de notre site. Nous avons créé 1 scénario de test qui nous pensons reprennent les actions les plus récurrentes dans le cadre d’un site commercial.<br />
Aussi nous avons réalisé des tests de burst sur plusieurs URI de l’API.<br />
<br />
Lors de la création de ces tests nous avons été contraint d’implémenter une authentification dynamique. Ce qui signifie un échange de requête successif permettant l’authentification d’un client ou d’un artisan à la manière OAuth1. <br />
<br />
Afin d’éliminer les contraintes liées à la connectivé et à la limite de bande passante du réseau de la machine executant JMeter, nous avons choisi d’exécuter nos scénarios avec BlazeMeter. Une application web permettant de lancer de manière distribuée un ensemble d’utilisateurs. <br />
En effet après lecture d’un article sur le sujet il semblerait qu’une seule JVM ne soit pas scalable. Tout au moins de manière empirique il s’avère qu’au-dela de 1000 utilisateurs (thread) en parallèle, la multiplication de puissance CPU et d’allocation mémoire n’évolue plus de manière proportionnelle au rendement d’une JVM.<br />
<br />
Description du système :<br />
------------------------<br />
<br />
Notre site web est construit selon le principe de Single page application. Ce qui signifie la présence d’au moins deux entités : une API côté backend et une application cliente en AngularJS/Html côté utilisateur.<br />
L’ensemble de notre packaging Java (Ear = {War, Ejb}) est hébergé sous une même VM accueillant un serveur Glassfish 4.1 mais aussi une base de données Derby.<br />
<br />
La VM est hebergée derrière une Box orange, avec les propriétés suivantes : <br />
<br />
* Bande passante : <br />
* Mentente : 400 Mégabytes (en théorie)<br />
* Descendante : 800 Mégabytes<br />
<br />
Capacité alloué a la machine virtuelle : <br />
<br />
* RAM allouée : 2 Go<br />
* HDD alloué : 20 Go<br />
* CPU alloué : 1 Process 4 coeurs (Intel i5 2.5 Ghz)<br />
<br />
<br />
Objectif :<br />
----------<br />
<br />
Le but de nos tests est d’identifier le nombre d’utilisateurs maximum que notre application peut supporter. Une fois trouvé, il s’agira d’identifier le goulot d’étranglement de notre application.<br />
D’ors et déjà nous identifions plusieurs points pouvons limiter notre capacité de charge : <br />
La VM se trouvant derrière une Box Orange, il est très possible que le débit montant soit plus limitant que le débit théorique de l’abonnement (400 Mégabytes théorique)<br />
La Box Orange n’est pas concu pour supporter une charge importante de requêtes entrante, ce qui constitue un cas limitant.<br />
L’utilisation de d’un système de retour en arrière (Rollback) constitue de faite un goulot d’étranglement en raison de l’atomicité des actions affectées du flag @TransactionAttribute. <br />
Leur utilisations se fait sentir notamment <br />
<br />
<br />
Scénarios : <br />
-----------<br />
<br />
Plan 1 :<br />
--------<br />
<br />
Notre premier plan de test consiste à effectuer une suite d’actions de basiques communent à un utilisateur normale. Ce dernier effectuerait ses actions dans l’ordre suivant : <br />
<br />
* Visiter la page du site<br />
* Visiter 2 formules<br />
* Ajouter les 2 formules au panier<br />
* Authentification et passage de la commande.<br />
<br />
Propriétés de simulations : <br />
---------------------------<br />
<br />
* Durée de la simulation : 15 min<br />
* Nombre de thread total (user) : 205<br />
* Montée en charge : 300 secondes. Soit ~3 nouveaux utilisateurs toutes les 2 secondes jsuqu’à atteindre les 205 utilisateurs.<br />
* Nombre d’itération : infini<br />
* Nombre de requête par seconde (RPS) : 1<br />
<br />
Remarquons que nous avons délibérarément choisi un RPS de 1, afin d’évaluer la tenue en en charge du site en terme de nombre de clients connectés.<br />
<br />
Identification du point de rupture : <br />
------------------------------------<br />
[[File:Scenario1_1_rps_without_RespTime.png]]<br />
<br />
Sur ce diagramme temporel nous observons en fonction du temps : <br />
<br />
* l’évolution du nombre d’utilisateurs (en bleu), lors de la montée progressive en charge.<br />
* l’évolution du # de requetes total par seconde (en vert)<br />
* l’évolution du # d’erreurs par seconde (en rouge)<br />
<br />
Précisons que la résolution du graphe est de 1 point / 15 secondes. Ce qui signifie que le nombre de Hit/s est une moyenne sur 15 secondes.<br />
<br />
Ce qu’il faut principalement noter sur ce graphe est le décollement de la courbe du taux de Hit/s d’erreurs, à partir de 34 utilisateurs en parallèles effectuant chacun à leur tour 1 requête toute les secondes. <br />
Il s’agit du début de rupture de notre système, puisqu’il se trouve au pied du premier pic (cf figure ci-dessous) d’erreurs culminant à une moyenne de 0.14 Hit/s (moyenne sur 15 échantillons), soit 14% des requeêtes générées se sont soldées par une erreur HTTP.<br />
<br />
[[File:Scenario1_1_rps.png]]<br />
<br />
Sur la figure ci-dessus, remarquons la présence de la courbe du temps de réponse moyen, qui dans son évolution globale s’oppose de manière symétrique au pics des erreurs. Rien de plus normal car le serveur ne supportant plus le nombre de clients connectés simultanément, renvoie des erreurs Http avec un temps de réponse court.<br />
<br />
En on peut noter la chute drastique de la courbe verte (= moyenne de Hit/s ayant reçu une réponse Http, même s’il s’agit d’erreurs 500 ou autre) dès l’atteinte du seuil des 205 utilisateurs. Cela signifie que ne reçoit aucune réponse Http et que la connexion au site échoue. <br />
<br />
Cette étude nous a premis de determiné la charge maximal (sans erreurs) en terme de nombre d’utilisateurs connectés au même moment.<br />
<br />
Plan 2 :<br />
--------<br />
<br />
Nous allons maintenant nous intéresser à une variante du plan de test. Puisque seule la fréquence de requêtes est réévaluée à 50 Rps (initialement à 1).<br />
<br />
[[File:Scenario1_50_rps.png]]<br />
<br />
Nous avons donc conservés les mêmes valeurs de montée en charge, du # d’utilisateurs et de durée d’expérience.<br />
Ce qui est possible d’extraire de ce graphe, est l’allure globale<br />
<br />
Ce qui est notable est l’affolement du système quasi instantané. En zoomant légèrement sur le début de la simulation (cf figure ci-dessous) on peut attester que dès le début de la simulation environs 3 requêtes sur 25 se sont soldées en échec. <br />
<br />
[[File:Scenario1_50_rps_zoom.png]]<br />
<br />
Identification du goulot d’étranglement : <br />
-----------------------------------------<br />
<br />
A l’observation du temps de réponse des differentes requêtes émisent en fonction de l’évolution du nombre d’utilisateur, l’action GET /formules est nettement en tête.<br />
<br />
[[File:Endpoints_response_time.png]]<br />
<br />
En effet il s’agit d’une requête retournant l’ensemble des produits contenus en base de données. Elle est exécutée à chaque visite de la page principale du site. <br />
Ce premier goulot d’étranglement est dû à l’absence de pagination limitant le résultat d’une requête Http et donc du temps de réponse moyen.<br />
Voici donc un premier point d’amélioration à apporter à notre prochaine version.<br />
<br />
A l’observation des erreurs retournée par l’API, une attire particulièrement notre attention : javax.ejb.EJBTransactionRolledbackException<br />
Les Rollbacks sont principalement utilisés dans les opérations nécessitant de mettre à jour des informations de manière simultanée. Dans notre cas, elle concerne l’ajout/suppression d’une formule, mais aussi d’un artisan ou d’un client ou d’une commande.<br />
Par exemple la suppression d’un compte artisan necessite la suppression de l’ensemble de ses formules et produits du catalogue. Cette opération doit être atomique sinon l’intégrité des données ne serait plus garantie<br />
<br />
Ainsi voici le second goulot d’étranglement rencontré qui porte sur l’accès non concurrentiel aux ressources add/delete d’un artisan/client/formule/commande.<br />
<br />
Cette erreur de Rollback signifie un retour vers l’état précédent l’éxécution d’une transaction. Elle s’est manisfestée au travers de teste de burst sur les endpoint simultané de création/suppression de formule et d’artisan.<br />
<br />
Limitations du système<br />
----------------------<br />
<br />
* L’option https n’a pas été explorée, même si nous avons conscience qu’elle constitue un critère important dans l’intéraction avec l’API. En effet, les tokens ne devraient jamais être utilisés en clair mais crypté par une session https. <br />
Cette tâche fait partie des améliorations prévues.<br />
<br />
* Une transaction bancaire dans notre système est traduite par une simple écriture d’entrée dans une table Orders. En effet dans notre système nous supposons qu’une transaction bancaire n’échoue pas. Ce qui implique indirectement que : <br />
les coordonnées bancaires du client sont correctes<br />
la connectivité à l’API bancaire est fiable.<br />
<br />
* Nous n’avons pas implémenté d’entité JMS (Java Message Service. En effet on suppose que le système ne tombe pas en panne au cours d’une validation de commande. Car si tel est le cas, nous n'aurions pas moyen de récupérer l’état avant crash. <br />
Ainsi certaines fonctionnalités telle que les news letters, ou la validation d’un compte client après redirection vers un lien envoyé par mail, sont gérés à l’aide d’un timer.<br />
Enfin l’atomicité de certaines opération tel que la commande est géré par un système de rolling back par un flag de type @TransactionAttribute .</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Benchmark_ECOM_2015_GRP5&diff=25495Benchmark ECOM 2015 GRP52015-12-14T21:58:57Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>Evaluation système<br />
------------------<br />
<br />
Introduction <br />
------------<br />
<br />
<br />
JMeter est l’outil que nous utilisons pour l’évaluation de performance de notre site. Nous avons créé 1 scénario de test qui nous pensons reprennent les actions les plus récurrentes dans le cadre d’un site commercial.<br />
Aussi nous avons réalisé des tests de burst sur plusieurs URI de l’API.<br />
<br />
Lors de la création de ces tests nous avons été contraint d’implémenter une authentification dynamique. Ce qui signifie un échange de requête successif permettant l’authentification d’un client ou d’un artisan à la manière OAuth1. <br />
<br />
Afin d’éliminer les contraintes liées à la connectivé et à la limite de bande passante du réseau de la machine executant JMeter, nous avons choisi d’exécuter nos scénarios avec BlazeMeter. Une application web permettant de lancer de manière distribuée un ensemble d’utilisateurs. <br />
En effet après lecture d’un article sur le sujet il semblerait qu’une seule JVM ne soit pas scalable. Tout au moins de manière empirique il s’avère qu’au-dela de 1000 utilisateurs (thread) en parallèle, la multiplication de puissance CPU et d’allocation mémoire n’évolue plus de manière proportionnelle au rendement d’une JVM.<br />
<br />
Description du système :<br />
------------------------<br />
<br />
Notre site web est construit selon le principe de Single page application. Ce qui signifie la présence d’au moins deux entités : une API côté backend et une application cliente en AngularJS/Html côté utilisateur.<br />
L’ensemble de notre packaging Java (Ear = {War, Ejb}) est hébergé sous une même VM accueillant un serveur Glassfish 4.1 mais aussi une base de données Derby.<br />
<br />
La VM est hebergée derrière une Box orange, avec les propriétés suivantes : <br />
<br />
* Bande passante : <br />
* Mentente : 400 Mégabytes (en théorie)<br />
* Descendante : 800 Mégabytes<br />
<br />
Capacité alloué a la machine virtuelle : <br />
<br />
* RAM allouée : 2 Go<br />
* HDD alloué : 20 Go<br />
* CPU alloué : 1 Process 4 coeurs (Intel i5 2.5 Ghz)<br />
<br />
<br />
Objectif :<br />
----------<br />
<br />
Le but de nos tests est d’identifier le nombre d’utilisateurs maximum que notre application peut supporter. Une fois trouvé, il s’agira d’identifier le goulot d’étranglement de notre application.<br />
D’ors et déjà nous identifions plusieurs points pouvons limiter notre capacité de charge : <br />
La VM se trouvant derrière une Box Orange, il est très possible que le débit montant soit plus limitant que le débit théorique de l’abonnement (400 Mégabytes théorique)<br />
La Box Orange n’est pas concu pour supporter une charge importante de requêtes entrante, ce qui constitue un cas limitant.<br />
L’utilisation de d’un système de retour en arrière (Rollback) constitue de faite un goulot d’étranglement en raison de l’atomicité des actions affectées du flag @TransactionAttribute. <br />
Leur utilisations se fait sentir notamment <br />
<br />
<br />
Scénarios : <br />
-----------<br />
<br />
Plan 1 :<br />
--------<br />
<br />
Notre premier plan de test consiste à effectuer une suite d’actions de basiques communent à un utilisateur normale. Ce dernier effectuerait ses actions dans l’ordre suivant : <br />
<br />
* Visiter la page du site<br />
* Visiter 2 formules<br />
* Ajouter les 2 formules au panier<br />
* Authentification et passage de la commande.<br />
<br />
Propriétés de simulations : <br />
---------------------------<br />
<br />
* Durée de la simulation : 15 min<br />
* Nombre de thread total (user) : 205<br />
* Montée en charge : 300 secondes. Soit ~3 nouveaux utilisateurs toutes les 2 secondes jsuqu’à atteindre les 205 utilisateurs.<br />
* Nombre d’itération : infini<br />
* Nombre de requête par seconde (RPS) : 1<br />
<br />
Remarquons que nous avons délibérarément choisi un RPS de 1, afin d’évaluer la tenue en en charge du site en terme de nombre de clients connectés.<br />
<br />
Identification du point de rupture : <br />
------------------------------------<br />
[[File:Scenario1_1_rps_without_RespTime.png]]</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=Benchmark_ECOM_2015_GRP5&diff=25493Benchmark ECOM 2015 GRP52015-12-14T21:53:38Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>Evaluation système<br />
------------------<br />
<br />
Introduction <br />
------------<br />
<br />
<br />
JMeter est l’outil que nous utilisons pour l’évaluation de performance de notre site. Nous avons créé 1 scénario de test qui nous pensons reprennent les actions les plus récurrentes dans le cadre d’un site commercial.<br />
Aussi nous avons réalisé des tests de burst sur plusieurs URI de l’API.<br />
<br />
Lors de la création de ces tests nous avons été contraint d’implémenter une authentification dynamique. Ce qui signifie un échange de requête successif permettant l’authentification d’un client ou d’un artisan à la manière OAuth1. <br />
<br />
Afin d’éliminer les contraintes liées à la connectivé et à la limite de bande passante du réseau de la machine executant JMeter, nous avons choisi d’exécuter nos scénarios avec BlazeMeter. Une application web permettant de lancer de manière distribuée un ensemble d’utilisateurs. <br />
En effet après lecture d’un article sur le sujet il semblerait qu’une seule JVM ne soit pas scalable. Tout au moins de manière empirique il s’avère qu’au-dela de 1000 utilisateurs (thread) en parallèle, la multiplication de puissance CPU et d’allocation mémoire n’évolue plus de manière proportionnelle au rendement d’une JVM.<br />
<br />
Description du système :<br />
------------------------<br />
<br />
Notre site web est construit selon le principe de Single page application. Ce qui signifie la présence d’au moins deux entités : une API côté backend et une application cliente en AngularJS/Html côté utilisateur.<br />
L’ensemble de notre packaging Java (Ear = {War, Ejb}) est hébergé sous une même VM accueillant un serveur Glassfish 4.1 mais aussi une base de données Derby.<br />
<br />
La VM est hebergée derrière une Box orange, avec les propriétés suivantes : <br />
<br />
* Bande passante : <br />
* Mentente : 400 Mégabytes (en théorie)<br />
* Descendante : 800 Mégabytes<br />
<br />
Capacité alloué a la machine virtuelle : <br />
<br />
* RAM allouée : 2 Go<br />
* HDD alloué : 20 Go<br />
* CPU alloué : 1 Process 4 coeurs (Intel i5 2.5 Ghz)<br />
<br />
<br />
Objectif :<br />
----------<br />
<br />
Le but de nos tests est d’identifier le nombre d’utilisateurs maximum que notre application peut supporter. Une fois trouvé, il s’agira d’identifier le goulot d’étranglement de notre application.<br />
D’ors et déjà nous identifions plusieurs points pouvons limiter notre capacité de charge : <br />
La VM se trouvant derrière une Box Orange, il est très possible que le débit montant soit plus limitant que le débit théorique de l’abonnement (400 Mégabytes théorique)<br />
La Box Orange n’est pas concu pour supporter une charge importante de requêtes entrante, ce qui constitue un cas limitant.<br />
L’utilisation de d’un système de retour en arrière (Rollback) constitue de faite un goulot d’étranglement en raison de l’atomicité des actions affectées du flag @TransactionAttribute. <br />
Leur utilisations se fait sentir notamment <br />
<br />
<br />
Scénarios : <br />
-----------<br />
<br />
Plan 1 :<br />
--------<br />
<br />
Notre premier plan de test consiste à effectuer une suite d’actions de basiques communent à un utilisateur normale. Ce dernier effectuerait ses actions dans l’ordre suivant : <br />
<br />
* Visiter la page du site<br />
* Visiter 2 formules<br />
* Ajouter les 2 formules au panier<br />
* Authentification et passage de la commande.<br />
<br />
Propriétés de simulations : <br />
---------------------------<br />
<br />
* Durée de la simulation : 15 min<br />
* Nombre de thread total (user) : 205<br />
* Montée en charge : 300 secondes. Soit ~3 nouveaux utilisateurs toutes les 2 secondes jsuqu’à atteindre les 205 utilisateurs.<br />
* Nombre d’itération : infini<br />
* Nombre de requête par seconde (RPS) : 1<br />
<br />
Remarquons que nous avons délibérarément choisi un RPS de 1, afin d’évaluer la tenue en en charge du site en terme de nombre de clients connectés.<br />
<br />
Identification du point de rupture : <br />
------------------------------------</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:Scenario1_1_rps.png&diff=25492File:Scenario1 1 rps.png2015-12-14T21:51:31Z<p>Malek-Hadi.Mammar: Malek-Hadi.Mammar uploaded a new version of &quot;File:Scenario1 1 rps.png&quot;</p>
<hr />
<div></div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:Scenario1_1_rps_without_RespTime.png&diff=25491File:Scenario1 1 rps without RespTime.png2015-12-14T21:47:28Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div></div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:Scenario1_50_rps_zoom.png&diff=25490File:Scenario1 50 rps zoom.png2015-12-14T21:46:08Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div></div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:Scenario1_1_rps.png&diff=25489File:Scenario1 1 rps.png2015-12-14T21:43:15Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div></div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:Scenario1_50_rps.png&diff=25488File:Scenario1 50 rps.png2015-12-14T21:41:01Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div></div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:Endpoints_response_time.png&diff=25487File:Endpoints response time.png2015-12-14T21:39:54Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div></div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=ECOM_RICM5_Groupe5_2015&diff=24311ECOM RICM5 Groupe5 20152015-10-13T14:41:58Z<p>Malek-Hadi.Mammar: /* Base de données */</p>
<hr />
<div>Bienvenue sur la fiche de suivi du projet ''Restauration personnalisée en ligne'' .<br />
<br />
Un projet de site de E-commerce dans lequel nous allons nous initier à la programmation J2EE.<br />
<br />
Nous sommes le groupe 5 de la promotion RICM5 - 2015/2016. <br />
<br />
== Présentation du projet ==<br />
<br />
Le site porte sur un service de restauration personnalisée. <br />
Deux modes de fonctionnement vous sont possibles : <br />
<br />
* des formules sont proposées par des artisans restaurateurs, sur lesquelles il vous est possible d’imposer des contraintes (la cuisson,...) selon vos affinités gustative, si l’artisan le propose.<br />
<br />
* des thèmes culinaires sont proposés par des artisans restaurateurs qui se charge de répondre à votre demande de plat dans un temps imparti. Il est à noter que l’artisan peut librement accepter ou refuser le traitement de votre demande dans la mesure des stocks disponibles. Dans le cas d’un refus une proposition peut vous être faite par l’artisan.<br />
<br />
==L'équipe==<br />
<br />
* [[User:Robin.Eudes|Robin Eudes]] : '''''Chef de projet'''''<br />
* [[User:Malek-Hadi.Mammar|Malek Mammar]] : '''''Scrum Master'''''<br />
* [[User:Zhengmeng.Zhang|Zhang Zhengmeng]] : '''''Développeur'''''<br />
<br />
== Etude du marché ==<br />
Suite à la diffusion de notre [https://docs.google.com/forms/d/14Bcd32h7TER11Bxbu9Sg22n8N94EqxBxuCFtMLpmzaQ/viewform questionnaire], nous avons obtenu 26 réponses à l'heure actuelle. Bien que cet échantillon de réponse soit limité, nous l'avons jugé suffisamment représentatif pour baser nos principaux axes de travail en adéquation avec les réponses reçues. <br />
<br />
=== Utilisateurs cibles ===<br />
<br />
[[File:Users_cible.png]]<br />
<br />
Nous ciblons principalement les étudiants, ou les jeunes salariés.<br />
<br />
=== Besoins utilisateurs ===<br />
<br />
[[File:Users_need1.png]]<br />
[[File:Uses_need2.png]]<br />
[[File:Uses_need3.png]]<br />
<br />
Le moyen principal de paiement serait la carte bancaire, cependant il serait souhaitable que notre système accepte différents modules de paiements tel que [https://www.paypal.com/fr/home Paypal], [http://www.izly.fr/ Izly]. La base d'utilisateur est par ailleurs favorable à un système de fidélité, récompensant le client d'une commande offerte après une certaine quantité d'achats à définir. Le site doit également donner accès à un système de notation sur les formules ou plats proposés par les restaurateurs, l'avis des autres clients étant un critère de choix important.<br />
<br />
=== Etude de la concurrence ===<br />
<br />
La concurrence est nombreuse, et souvent spécialisée dans un domaine culinaire. En voici quelques exemples :<br />
<br />
* [https://www.foodpanda.com/ Foodpanda] : Le site nous proposera d'abord de choisir un restaurant, puis le menu que l'ont souhaite commander, avant de finaliser la commande (paiement). Cependant, on peut également effectuer une recherche par type de cuisine,et donc trouver les restaurants servant ce type de plats, pour revenir dans le premier schéma évoqué (choix restaurant -> choix plat -> paiement). La recherche par type de cuisine est pas mise en avant. Le site reste malgré tout assez clair, bien que chargé. Une application mobile est proposée par ailleurs (Android/iOS/Windows Phone).<br />
<br />
* [https://www.sushishop.fr/ SushiShop] : Thème "sombre" pour le site, on a un accès direct aux "boxes" (menus sushis), ou à la carte détaillée. Le menu donnant accès à la carte nous offre un "diaporama" des plats servis, très agréable visuellement. Le panier sera affiché dans un menu sur la droite uniquement une fois que nous avons sélectionné un plat. Un espace de connexion vers son compte est disponible en haut à droite. Logo discret sur le coin supérieur gauche.<br />
<br />
=== Plateformes d'utilisation ===<br />
<br />
[[File:Uses_plat.png]]<br />
<br />
La mise en forme de notre site devra être capable de supporter différents supports, PC et mobiles principalement (responsive design).<br />
<br />
== Définition des services rendus ==<br />
=== Exigences ===<br />
==== Exigences fonctionnelles ====<br />
* Tâches prioritaires<br />
** Gestion d'une session sécurisée<br />
** Acteur client : Effectuer une commande<br />
** Acteur client : Gérer son panier<br />
** Acteur artisan : Gérer son catalogue<br />
<br />
* Tâches secondaires<br />
** Acteur client : Effectuer un appel d'offre<br />
** Acteur artisan : Répondre à un appel d'offre<br />
<br />
==== Exigences non fonctionnelles ====<br />
* [https://fr.wikipedia.org/wiki/Propri%C3%A9t%C3%A9s_ACID Propriétés ACID] sur les transactions (en particulier le paiement)<br />
* Interface user-friendly, selon [http://www.ergolab.net/articles/criteres-ergonomiques-1.php Les critères ergonomiques de Bastien & Scapin]<br />
* Gestion fine de l'utilisation de HTTPS<br />
* Résistance du système à la montée en charge (Temps de service constant)<br />
* Réduire au minimum le parcours de paiement<br />
* Portabilité (responsive design) PC, mobiles.<br />
<br />
== Conception du système ==<br />
=== Arbres des tâches ===<br />
====Tâches prioritaires====<br />
<br />
[[File:Arbre_taches_client_faire_une_commande.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_gerer_catalogue.png]]<br />
<br />
====Tâches secondaires :====<br />
<br />
[[File:Arbre_taches_client_faire_un_appel_d_offre.png]]<br />
<br />
<br />
[[File:Arbre_taches_artisan_repondre_appel_d_offre.png]]<br />
<br />
=== Diagramme de contexte ===<br />
[[File:Diagramme_de_contexte_ecom5.png]]<br />
<br />
=== Base de données ===<br />
[[File:UML_-_DataBase.png]]<br />
<br />
Vous remarquerez, qu'il n'y a pas de table "Panier" ou "Historique", car nous considérons que ces données sont à sauvegarder en session.<br />
<br />
=== IHM abstraites ===<br />
==== Faire une commande (client) ====<br />
Priorité : forte<br />
<br />
<br />
La tâche "Faire une commande" pour l'acteur Client se décomposer en ces 2 IHM abstraites : '''Consulter la carte''' et '''Consulter son panier''' .<br />
<br />
[[File:Client_-_consulter_carte_-_IHM_abstraite.png]]<br />
<br />
[[File:IHM_abstraite_-_consulter_panier_(client).png]]<br />
<br />
==== Gérer son catalogue (artisan) ====<br />
Priorité : forte<br />
<br />
<br />
[[File:IHM_abstraite_-_Gestion_catalogue_artisan.png]]<br />
<br />
=== Maquettes du site ===<br />
<br />
==== Maquette Accueil du site ====<br />
[[File:Maquette_carte.png]]<br />
<br />
==== Maquette page produit ====<br />
<br />
== Planification du projet - SCRUM ==<br />
<br />
SCRUM est la méthode de travail préconisée dans ce projet.<br />
<br />
Sprint planning<br />
---------------<br />
<br />
==== Sprint 1 : 15/09/2015 - 28/09/2015 ====<br />
* Choix d'un sujet de commerce en ligne<br />
* Prise en main des outils de développement J2EE<br />
* Réalisation d'un questionnaire <br />
** ciblage du marché<br />
** étude de marché sur la concurrence<br />
** identification des besoins utilisateur<br />
<br />
==== Sprint 2 : 29/09/2015 - 12/10/2015 ====<br />
* Réalisation d'un arbre des tâches<br />
* Conception d'une architecture générale<br />
* Publication des documents de conception IHM sur air.imag.fr<br />
* Analyse des résultats du questionnaire<br />
* Mise en forme des arbres des tâches, IHM abstraites.<br />
* Analyse de la concurrence<br />
* Réalisation de la maquette<br />
<br />
==== Sprint 3 : 27/10/2015 - 09/11/2015 ====<br />
<br />
==== Sprint 4 : 10/11/2015 - 23/11/2015 ====<br />
<br />
==== Sprint 5 : 24/11/2015 - 07/12/2015 ====<br />
<br />
==== Sprint 6 : 08/12/2015 - 16/12/2015 ====<br />
<br />
== Liens externes ==<br />
=== Dépôt Github ===<br />
[https://github.com/EudesRobin/ecom GitHub - ECOM GRP5] (dépôt actuellement privé).</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=ECOM_RICM5_Groupe5_2015&diff=24134ECOM RICM5 Groupe5 20152015-10-13T06:15:38Z<p>Malek-Hadi.Mammar: Created page with "Bienvenue sur la fiche de suivi du projet **Restauration personnalisée en ligne** . Un projet de site de E-commerce nous initions à la programmation J2EE. Nous sommes le gr..."</p>
<hr />
<div>Bienvenue sur la fiche de suivi du projet **Restauration personnalisée en ligne** . <br />
Un projet de site de E-commerce nous initions à la programmation J2EE.<br />
Nous sommes le groupe 5 de la promotion RICM5 - 2015/2016. <br />
<br />
==L'équipe==<br />
* Robin Eudes **Chef de projet**<br />
* Malek Mammar *Scrum Master*<br />
* Zhang Zhengmeng<br />
<br />
<br />
==Documents==<br />
<br />
<br />
==Gestion du travail==<br />
<br />
SCRUM est la méthode de travail préconisée dans ce projet.<br />
<br />
<br />
Sprint planning<br />
---------------<br />
<br />
==== Sprint 1 : 15/09/2015 - 28/09/2015 ====<br />
* Choix d'un sujet de commerce en ligne<br />
* Prise en main des outils de développement J2EE<br />
* Réalisation d'un questionnaire <br />
** ciblage du marché<br />
** étude de marché sur la concurrence<br />
** identification des besoins utilisateur<br />
<br />
==== Sprint 2 : 29/09/2015 - 12/10/2015 ====<br />
* Réalisation d'un arbre des tâches<br />
* Conception d'une architecture générale<br />
<br />
==== Sprint 3 : 27/10/2015 - 09/11/2015 ====<br />
<br />
==== Sprint 4 : 10/11/2015 - 23/11/2015 ====<br />
<br />
==== Sprint 5 : 24/11/2015 - 07/12/2015 ====<br />
<br />
==== Sprint 6 : 08/12/2015 - 16/12/2015 ====</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23907VT2015 Graph Databases2015-10-07T22:21:12Z<p>Malek-Hadi.Mammar: /* Synthèse écrite */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
The democratization of graph databases comes in continuity to the NoSQL (NotOnlySQL) fashion, which spreads the idea that relational databases are not the only possible storage. <br />
Also we must not forget to point out that social networks spreading contributed a lot to "graph databases" appearance. I think of facebook, twitter, linkedIn who pioneered to this democratization with the development of wrappers for relational database to facilitate the use of graph structures (eg. TAO, FlockDB). <br />
In this presentation we shall see what is the goal of using graph databases and focus on Neo4j database.<br />
<br />
==Résumé==<br />
<br />
La démocratisation des bases de données de graphes vient en continuité au mouvement NoSQL (NotOnlySQL), qui répand l'idée que les bases de données relationnelles ne sont pas le seul moyen de stockage possible.<br />
Aussi, nous ne devons pas oublier de souligner que l'explosion des réseaux sociaux a également beaucoup contribué à l’émergence des bases de données en graphes. Je pense notamment à aux pionniers de cette démocratisation, de Facebook, Twitter, LinkedIn, ... avec le développement de "wrapper" pour les bases de données relationnelles qui ont pour but de faciliter la manipulation de structures en graphes (ex. Tao, FlockDB).<br />
Dans cette présentation, nous verrons quel est le but de l'utilisation de bases de données en graphe et se pencher particulièrement Neo4j.<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe vient en continuation au mouvement NoSQL(NotOnlySQL) qui prône l'idée que les BD relationnelles ne sont pas les seuls moyens de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui a tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de données qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisation des BD en graphe sont multiples : <br />
* centralisation des logs issus d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisation qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble à celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour se donner une idée de performance, je reprends l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|700px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées là-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépasser en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en matière de performances par ses homologues relationnels. <br />
<br />
Quel est donc l'intérêt de Neo4j ? Eh bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernières slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster un calcul de plus court chemin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performances en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principal avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au-dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de données ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m’interrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|300px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle-même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* a un impact fondamental sur les performances de Neo4j. Le principal inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatiale du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilités d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vieille BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23906VT2015 Graph Databases2015-10-07T22:00:52Z<p>Malek-Hadi.Mammar: /* Abstract */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
The democratization of graph databases comes in continuity to the NoSQL (NotOnlySQL) fashion, which spreads the idea that relational databases are not the only possible storage. <br />
Also we must not forget to point out that social networks spreading contributed a lot to "graph databases" appearance. I think of facebook, twitter, linkedIn who pioneered to this democratization with the development of wrappers for relational database to facilitate the use of graph structures (eg. TAO, FlockDB). <br />
In this presentation we shall see what is the goal of using graph databases and focus on Neo4j database.<br />
<br />
==Résumé==<br />
<br />
La démocratisation des bases de données de graphes vient en continuité au mouvement NoSQL (NotOnlySQL), qui répand l'idée que les bases de données relationnelles ne sont pas le seul moyen de stockage possible.<br />
Aussi, nous ne devons pas oublier de souligner que l'explosion des réseaux sociaux a également beaucoup contribué à l’émergence des bases de données en graphes. Je pense notamment à aux pionniers de cette démocratisation, de Facebook, Twitter, LinkedIn, ... avec le développement de "wrapper" pour les bases de données relationnelles qui ont pour but de faciliter la manipulation de structures en graphes (ex. Tao, FlockDB).<br />
Dans cette présentation, nous verrons quel est le but de l'utilisation de bases de données en graphe et se pencher particulièrement Neo4j.<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|700px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|300px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23905VT2015 Graph Databases2015-10-07T21:56:23Z<p>Malek-Hadi.Mammar: /* Abstract */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
The democratization of graph databases comes in continuity to the NoSQL (NotOnlySQL) fashion, which spreads the idea that relational databases are not the only possible storage. <br />
Also we must not forget to point out that social networks spreading contributed a lot to "graph databases" appearance. I think of facebook, twitter, linkedIn who pioneered to this democratization with the development of wrappers for relational database to facilitate the use of graph structures (eg. TAO, FlockDB). <br />
In this presentation we shall see what is the goal of using graph databases and focus on Neo4j database.<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|700px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|300px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23869VT2015 Graph Databases2015-10-06T17:14:36Z<p>Malek-Hadi.Mammar: /* Comparatif de performance */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|700px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|300px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23868VT2015 Graph Databases2015-10-06T17:14:27Z<p>Malek-Hadi.Mammar: /* Comparatif de performance */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|500px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|300px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23867VT2015 Graph Databases2015-10-06T17:14:17Z<p>Malek-Hadi.Mammar: /* Comparatif de performance */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|300px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|300px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23866VT2015 Graph Databases2015-10-06T17:13:58Z<p>Malek-Hadi.Mammar: /* Zoom sur Neo4j */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|300px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23865VT2015 Graph Databases2015-10-06T17:13:49Z<p>Malek-Hadi.Mammar: /* Zoom sur Neo4j */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|200px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23864VT2015 Graph Databases2015-10-06T17:13:30Z<p>Malek-Hadi.Mammar: /* Zoom sur Neo4j */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_neo4j.png|500px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23863VT2015 Graph Databases2015-10-06T17:13:10Z<p>Malek-Hadi.Mammar: /* Zoom sur Neo4j */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
[[File:VT2015_Graph_Databases_demo.png|500px|center|Wrapper performance]]<br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23862VT2015 Graph Databases2015-10-06T17:12:47Z<p>Malek-Hadi.Mammar: /* Solution */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:VT2015_Graph_Databases_demo.png&diff=23861File:VT2015 Graph Databases demo.png2015-10-06T17:11:53Z<p>Malek-Hadi.Mammar: A demonstration on graph database</p>
<hr />
<div>A demonstration on graph database</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:VT2015_Graph_Databases_benchmarking.png&diff=23860File:VT2015 Graph Databases benchmarking.png2015-10-06T17:11:42Z<p>Malek-Hadi.Mammar: Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/</p>
<hr />
<div>Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:VT2015_Graph_Databases_SQL_VERTEX.png&diff=23859File:VT2015 Graph Databases SQL VERTEX.png2015-10-06T17:11:26Z<p>Malek-Hadi.Mammar: Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/</p>
<hr />
<div>Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=File:VT2015_Graph_Databases_neo4j.png&diff=23858File:VT2015 Graph Databases neo4j.png2015-10-06T17:11:02Z<p>Malek-Hadi.Mammar: Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals</p>
<hr />
<div>Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23857VT2015 Graph Databases2015-10-06T17:10:05Z<p>Malek-Hadi.Mammar: /* Solution */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Wrapper performance]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23856VT2015 Graph Databases2015-10-06T17:09:39Z<p>Malek-Hadi.Mammar: /* Solution */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
[[File:VT2015_Graph_Databases_SQL_VERTEX.png|500px|center|Benchmarking]]<br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23855VT2015 Graph Databases2015-10-06T17:09:12Z<p>Malek-Hadi.Mammar: /* Comparatif de performance */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23854VT2015 Graph Databases2015-10-06T17:08:45Z<p>Malek-Hadi.Mammar: /* Comparatif de performance */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[File:VT2015_Graph_Databases_benchmarking.png|500px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23853VT2015 Graph Databases2015-10-06T17:08:28Z<p>Malek-Hadi.Mammar: /* Comparatif de performance */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
[[Image:VT2015_Graph_Databases_benchmarking.png|500px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23852VT2015 Graph Databases2015-10-06T17:00:40Z<p>Malek-Hadi.Mammar: /* Comparatif de performance */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
<<add benchmark image>><br />
[[Image:ChoixSujetsVT2015.png|500px|center|Benchmarking]]<br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23851VT2015 Graph Databases2015-10-06T16:48:56Z<p>Malek-Hadi.Mammar: /* Document */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
<<add benchmark image>><br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23850VT2015 Graph Databases2015-10-06T16:48:17Z<p>Malek-Hadi.Mammar: /* Document */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
[Slides de présentation](File:VT2015_Graph_Databases.pdf)<br />
<br />
[[File:VT2015_Graph_Databases.pdf|Slides de présentation]]<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
<<add benchmark image>><br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23849VT2015 Graph Databases2015-10-06T16:45:33Z<p>Malek-Hadi.Mammar: /* =Zoom sur Neo4j */</p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
[Slides de présentation]()<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
<<add benchmark image>><br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
===Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23848VT2015 Graph Databases2015-10-06T16:45:00Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Document==<br />
[Slides de présentation]()<br />
<br />
==Abstract==<br />
<br />
<br />
==Synthèse écrite==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
<<add benchmark image>><br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste à démarrer d'un noeud source, et de successivement visiter ses noeuds voisins. Contre toute attente, là encore Neo4j se fait devancer en terme de performances par ses homologues relationnels. <br />
<br />
Quelles est donc l'intérêt de Neo4j ? Et bien, c'est d'offrir une API facilitant la manipulation de structure en graphe. Sur les dernière slides de ma présentation une preuve à l'appui d'un exemple de requête ayant pour but de contraster une calcul de plus court chamin entre une syntaxe Cypher (utilisée par Neo4j) et une syntaxe SQL.<br />
<br />
===Avantages/Inconvénients===<br />
<br />
Pour récapituler plusieurs avantages et inconvénients sont à souligner : <br />
<br />
Pour les BD en graphe :<br />
* Avantages :<br />
** une interface de requête plus adaptée aux structures en graphe<br />
* Inconvénients:<br />
** perte en performance en raison de l’implémentation sous-jacente (voir Zoom sur Neo4j)<br />
<br />
<br />
Pour les BD relationnelles : <br />
* Avantages :<br />
** performance (quel que soit le type de requêtes)<br />
* Inconvénients : <br />
** complexification des requêtes de type graphe<br />
** perte en temps de développement<br />
** risque d’erreurs<br />
<br />
===Solution===<br />
<br />
Une solution mixte liant la performance des BD relationnelle à la facilité de manipulation de structures en rgaphe, consiste à élaborer une interface plus "graph-friendly" qui se mappe au moteur SQL (eg. Giraph, Pregel, ...)<br />
<br />
Le principale avantage est l'abstraction de la syntaxe SQL. Et l'unique inconvénient est l'ajout d'un temps de traitement supplémentaire. <br />
Sur le tableau ci-dessous on met en évidence l'impact d'un "wrapper" au dessus de la BD relationnelle voltDB (mentionné plus haut). On peut clairement remarquer un temps de calcul plus ou moins proportionnel à la taille des données manipulées. Sur une petite base de donnée ~4K noeuds (Facebook) la perte s'évalue à 10 secondes tandis que sur une taille plus importante (de 81K noeuds), la perte s'élève à 140 secondes. Ce qui est non négligeable !<br />
<br />
<<add file table on wrapper performance>><br />
Comparaison des interfaces SQL - Vertex-centric (= similaire à Giraph)<br />
Source : http://istc-bigdata.org/index.php/benchmarking-graph-databases/<br />
<br />
Enfin je citerai quelques exemples de “wrapper” MySQL : FlockDB (Twitter), TAO (Facebook).<br />
<br />
En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
====Zoom sur Neo4j===<br />
<br />
<<add file neo4j structure>><br />
Structure des données dans Neo4j<br />
Source : http://fr.slideshare.net/thobe/an-overview-of-neo4j-internals<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
===Conclusion===<br />
<br />
En conclusion l'application à développer déterminera le choix de la BD. Selon que l'on recherche : <br />
* performances et scalabilité, on partira sur du NoSQL<br />
* des propriétés ACID, cruciales dans les domaines de transactions (eg. bancaires, ...), on choisira une bonne vielle BD relationnelle.<br />
* une facilité de syntaxe des requêtes, pour un développement plus rapide d'une application impliquant la manipulation de structure en graphe, on partira sur<br />
** l'utilisation de “wrapper” de requêtes SQL (Giraph, Pegasus, …)<br />
** l'utilisation des BD dédiés graphe : Neo4j (Cypher)</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23847VT2015 Graph Databases2015-10-06T16:00:18Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
<br />
Sujet : Graph databases<br />
<br />
<br />
==Abstract==<br />
<br />
==Synthèse==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
<<add benchmark image>><br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste en un noeud source, et successivement ses noeuds voisins sont visités. Contre toute attente, la encore Neo4j se fait devancer en terme de performance par ses homologues relationnels. En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
<<add file neo4j structure>><br />
.imagelink_wikilogo a {<br />
width:135px;<br />
height:135px;<br />
display:block;<br />
text-decoration:none;<br />
background-image: url("http://upload.wikimedia.org/wikipedia/mediawiki/b/bc/Wiki.png") <br />
}<br />
<br />
Ce que l'on peut clairement observer c'est la structure d'un noeud, contenant une liste chaînée de propriétés de type clé-valeur, et de relation trié par type, puis par catégorie In si l'arc (équivalent à une relation) est incident, Out s'il est sortant. Un noeud contient uniquement une référence vers une liste chaînée de relations.<br />
Une relation est elle même une structure contenant un type, une liste chaînée de propriétés ainsi que son noeud de départ (start) et d'arrivée (end).<br />
Un graphe est donc stocké sous forme d'une liste chaînée de noeuds contenant chacun toute l'information nécessaire sur les arcs entrants et sortants du noeud. <br />
La redondance du terme *liste chaînée* à un impact fondamentale sur les performances de Neo4j. Le principale inconvénient d'une structure en liste chaînée est le coût en temps et en nombre d'accès mémoire I/O. Contrairement au BD relationnelle il n'y a là pas possibilité de cache, à localité spatial du moins, au niveau matériel. Et ce, pour la simple raison que les données ne sont pas contiguës en mémoire mais éparpillées sur le disque. Il y a sans doute possibilité de constituer un cache logique, mais sans possibilité d'égaler les performances d'un cache matériel.<br />
<br />
<br />
To be continued ...</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23813VT2015 Graph Databases2015-10-05T22:40:19Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>==Présentation==<br />
<br />
Enseignants : D. Donsez, GP. Bonneau<br />
Sujet : Graph databases<br />
<br />
<br />
==Abstract==<br />
<br />
==Synthèse==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
<<add benchmark image>><br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste en un noeud source, et successivement ses noeuds voisins sont visités. Contre toute attente, la encore Neo4j se fait devancer en terme de performance par ses homologues relationnels. En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
<<add file neo4j structure>><br />
<br />
<br />
<br />
<br />
<br />
To be continued ...</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23812VT2015 Graph Databases2015-10-05T22:38:32Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>==Synthèse==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
<br />
<<add benchmark image>><br />
<br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément,<br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
Deux bases de données permettent l'évaluation des performances : <br />
* une constituée de 4K noeuds<br />
* une seconde constituée de 81K noeuds<br />
<br />
Deux types de requêtes sont élaborées :<br />
* *pageRank* qui consiste en un noeud avec potentiellement des jointures. Les BD relationnelle sont très optimisées la-dessus. D'ailleurs cela se constate par le fait que Neo4j se fait dépassé en terme de performance.<br />
* *shortestPath* qui consiste en un noeud source, et successivement ses noeuds voisins sont visités. Contre toute attente, la encore Neo4j se fait devancer en terme de performance par ses homologues relationnels. En m'intérrogeant sur l'origine de ce manque de performance, je me suis penché sur la structure de Neo4j.<br />
<br />
<<add file neo4j structure>><br />
<br />
<br />
<br />
<br />
<br />
To be continued ...</div>Malek-Hadi.Mammarhttps://air.imag.fr/index.php?title=VT2015_Graph_Databases&diff=23811VT2015 Graph Databases2015-10-05T22:15:47Z<p>Malek-Hadi.Mammar: </p>
<hr />
<div>==Synthèse==<br />
<br />
====Introduction====<br />
<br />
La démocratisation des bases de données en graphe viens en continuation au mouvement NoSQL(NotOnlySQL) qui à prône l'idée que les BD relationnelles ne sont pas le seul moyen de stockage. <br />
Aussi on ne peut oublier de souligner, l'explosion des réseaux sociaux qui à tout aussi favorisé leur apparition. Je pense notamment à facebook, twitter, linkedIn qui furent les pionniers vers cette démocratisation avec l'élaboration de "wrappers" de BD relationnelle facilitant l'usage de structures en graphe (eg. TAO, FlockDB).<br />
On est en droit de se demander quelle est l'utilité des BD en graphe.<br />
<br />
====Motivations====<br />
<br />
<br />
Pour faire court, 2 raisons motivent l'utilisation de BD en graphe : <br />
* posséder une structure de donnée qui reflète l'architecture de l'application à coder. C'est typique de l'application à consonance *networking* : facebook, etc...<br />
* une syntaxe de requête plus *graph-friendly*<br />
<br />
Les cas d'utilisations des BD en graphe sont multiples : <br />
* centralisation des logs issues d'applications hétérogènes mais dont les interactions sont complexes. <br />
* un gestionnaire de modules, ou bibliothèques (NPM, ...) nécessitant un graphe de dépendances.<br />
<br />
Bref, il y a autant de cas d'utilisations qu'il y a de problème de graphe nécessitant une persistance des données dans le temps.<br />
<br />
====Analyse de marché====<br />
<br />
<br />
On peut répertorier les bases de données sous 3 catégories. Et dans chacune des distinctions sont possibles. L'ordre ressemble a celui-ci : <br />
* les relationnelles : basées sur une structure en tables<br />
** orientée colonne (eg. Vertica)<br />
** orientée ligne (eg. MySQL)<br />
<br />
* les NotOnlySQL : basées sur différents systèmes<br />
** clé-valeur (eg. Redis)<br />
** document (eg. MongoDB)<br />
** ...<br />
<br />
* les structures en graphe : basées sur différents systèmes<br />
** une structure en graphe (eg. Neo4j, LDAP)<br />
** *wrapper* d'une BD relationnelle (eg. TAO, FlockDB)<br />
<br />
Ce qui différencie une BD relationnelle orientée colonne et à une autre orientée ligne est la façon dont la sérialisation des données est effectuée sur le disque dur. En *orientée-colonne* les colonnes d'une table sont écrites sur disque successivement de manière contiguë. En *orientée-ligne* les lignes sont cette fois-ci écrites successivement.<br />
<br />
====Comparatif de performance====<br />
<br />
<br />
Pour ce donner une idée de performance, je reprend l'exemple d'un benchmark réalisé par Alekh Jindal, un post doctorant dans le groupe Data base Group du laboratoire MIT CAIL. <br />
On peut reconnaître 2 types de BD : <br />
* Neo4j (en graphe)<br />
* les autres (en relationnelle). Plus précisément la <br />
** Vertica est orientée colonne<br />
** MySQL est orientée ligne<br />
** VoltDB est orientée stockage en RAM<br />
<br />
<br />
<br />
To be continued ...</div>Malek-Hadi.Mammar