Author: afages Date: 2010-03-12 13:09:52 +0100 (Fri, 12 Mar 2010) New Revision: 220 Log: Modif rapport Modified: trunk/src/site/doc/rapport/rapport.rst Modified: trunk/src/site/doc/rapport/rapport.rst =================================================================== --- trunk/src/site/doc/rapport/rapport.rst 2010-03-11 17:09:36 UTC (rev 219) +++ trunk/src/site/doc/rapport/rapport.rst 2010-03-12 12:09:52 UTC (rev 220) @@ -1,5 +1,6 @@ -Rapport de projet de fin d'étude : Map Storage Manager ====================================================== +Rapport de PFE : Map Storage Manager +====================================================== :Authors: Gilles CRIELOUE., @@ -93,7 +94,7 @@ Outils ---------------------- -- Technologies : Java, JAXX, JMX +- Technologies : Java, Maven, JAXX, JMX - SVN : Dépôt de Code Lutin prévu à cet effet. - Architecture Maven comportant un pom.xml natif à Code Lutin permettant l'utilisation d'artifact JAXX notamment. @@ -131,30 +132,372 @@ analyse des technologies ------------------------ -JAXX, JMX +Maven +~~~~~ +Maven est connu de bon nombre de développeurs. Il s'agit d'un outil de +développement permettant de faciliter la compilation, la documentation, +les tests et surtout les dépendances récupérées automatiquement sur +l'Internet. +Le fichier de description d'un projet Maven est un pom.xml. +Code Lutin dispose de leur propre pom.xml permettant d'aller récupérer +les dépendances qui vont suivre. + +Jaxx +~~~~ + +Jaxx est un framework permettant de générer une interface graphique en +SWING (Java). SWING est parfois fastidieux à gérer et le code n'est +pas toujours très propre. Le but de Jaxx est donc de contraindre un +développeur à obtenir du code propre et performant en SWING. + +Le principe est très simple. On définit les éléments de la vue +(les composants graphiques), les contrôleurs, les classes Java à utiliser +dans un fichier XML. Le moteur Jaxx analyse ensuite le fichier et +génère le code adapté. + +Il faut savoir qu'à l'origine, Jaxx est un projet récupéré par Code Lutin +qui l'a fait évoluer jusqu'à atteindre une version 2.0. +La dépendance est explicitée dans le fichier pom.xml de l'entreprise. + +Plus de précisions à cet endroit : +http://maven-site.nuiton.org/jaxx/index.html + +Jmx +~~~ + analyse du domaine ------------------ -BigTable... -usecase1 --------- +Analyse de BigTable (de google Inc.) -usecase2 --------- +But de l'analyse +~~~~~~~~~~~~~~~~ -usecase3 --------- +Permettre la compréhension de Big Table et de ses diverses implémentations +ainsi que l'extraction d'interface pour le projet MSM. -usecase4 --------- +Introduction : Qu'est-ce que BigTable ? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -usecase5 --------- +BigTable est la spécification d'un système de stockage distribué permettant +de gérer des données. Il est conçu pour s'adapter fiablement à des tailles +de contenu allant jusqu'au "Peta". BigTable est utilisé pour plusieurs raisons : -usecase6 --------- +- Toucher un large ensemble d'applications +- Mise à l'échelle +- Très bonnes performances (temps de réponse...) +- Forte disponibilité +Le modèle de données de BigTable +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Le modèle de données de BigTable se comporte comme un dictionnaire +multidimensionnel (matrice) indexé par le triplet +<row key, column key, timestamp>. Chaque valeur de ce dictionnaire +est un table d'octets. + +Les clés pour une rangée du dictionnaire sont des chaînes de charactères +arbitraires et BigTable maintient les données dans un ordre lexicographique +grâce à ce type de clé. + +ex de clé de rangée : "com.google.maps/index.html" (reversed URL) + +La portée d'une rangée est appelée "tablet", unité de distribution et d'équilibrage +de charge. + +Les clés de colonne sont groupées en ensembles appelés "famille de colonnes". +Une clé de colonne est nommé suivant le schéma : family:qualifier. +Les noms de famille doivent être lisibles facilement mais les qualificateurs peuvent +être des chaînes de charactères arbitraires + +ex de famille de colonne : "contents:" + +Ainsi, le contenu d'une cellule indexée par <com.google.maps/index.html, contents:, ?> +serait le contenu de la page "index.html" (le code html). +Une cellule peut contenir plusieurs versions de la même donnée via le mécanisme de timestamp. +Chaque cellule stocke plusieurs timestamp en ordre décroissant si bien que : + +- <com.google.maps/index.html, contents:, ts1> donne la version la plus récente du contenu. +- <com.google.maps/index.html, contents:, ts2> donne une version plus ancienne du contenu. + +Stockage +~~~~~~~~ + +BigTable utilise le système de fichier google GFS (Google File System) +pour stocker les logs et fichiers de données. + +Le format de fichier google SSTable est utilisé pour stocker les données +internes à BigTable. + +API BigTable (client) +~~~~~~~~~~~~~~~~~~~~~ + +Voici les fonctionnalités prévues par la spécification BigTable : + +- Création de tables. +- Création de familles de colonne. +- Suppression de tables. +- Suppression de familles de colonne. +- Changement de cluster (?). +- Changement de table. +- Changement de méta données sur une famille de colonne (droits d'accès...). +- Ecriture des données dans une table. +- Suppression des données dans une table. +- Recherche des données dans une table depuis des rangées individuelles. +- Itération sur un sous-ensemble de données d'une table. +- Manipulation avancée des données : Transactions "Lecture - Modification - Ecriture" +sur une rangée simple (BigTable ne supporte pas les transactions par rangées multiples). +- Utilisation des cellules comme compteurs d'entier. +- Excécution de scripts clients dans l'espace d'adressage des serveurs (langage : sawzall). +- Calcul parallèle avec le framework MapReduce. + +Source +~~~~~~ + +Cette analyse est une synthèse des éléments utiles dans le cadre du +projet, issue de la spécification même de Google Inc. +"BigTable: A Distributed Storage System for Structured Data" + +lien : labs.google.com/papers/bigtable-osdi06.pdf + +Description des cas d'utilisation +--------------------------------- + +Describe Database +----------------- + +- Use case : 11.Describe Database +- Goal in context : décrire la structure d'une base de données +BigTable (Hbase, HashMap...) en affichant les différentes tables graphiquement selon le plugin de la base. +- Scope : MSM -GUI/IHM +- Level : sous-fonctionnalité +- Primary actor : utilisateur de MSM +- Trigger : L'utilisateur souhaite décrire la base en cours +- Frequency : très souvent (toute utilisation d'une base passe par sa description normalement) - 100/jour +- Pre-conditions : + PRE1 : l'utilisateur doit être connecté à la base qu'il veut décrire. + On connait la base. +- Post-conditions : + POST1 : l'utilisateur dispose graphiquement de la structure de la + base. +- Main success scenario : + 1) L'utilisateur se connecte à la base de données + 2) MSM renvoie la base de données à l'utilisateur + 3) L'utilisateur souhaite décrire sa base + 4) MSM renvoie la structure de la base (tables) + 5) L'utilisateur traite la structure de la base +- Extensions : +- Performance : selon la fréquence d'exécution, doit être très rapide. +L'utilisateur doit obtenir la structure de la base immédiatement. + +Describe Table +-------------- + +- Use case : 12.Describe Table +- Goal in context : décrire la structure d'une table d'une base +BigTable (Hbase, HashMap...) en affichant les différents éléments (colonnes, types...) +graphiquement selon le plugin de la base. +- Scope : MSM -GUI/IHM +- Level : sous-fonctionnalité +- Primary actor : utilisateur de MSM +- Trigger : L'utilisateur souhaite décrire une table de la base +- Frequency : très souvent (toute utilisation d'une table passe par sa description normalement) - 100/jour +- Pre-conditions : + PRE1 : l'utilisateur doit être connecté à la base qu'il veut décrire. + On dispose d'un accès à la table. +- Post-conditions : + POST1 : l'utilisateur dispose graphiquement de la structure de la + table. +- Main success scenario : + 1) L'utilisateur se connecte à la base de données + 2) MSM renvoie la base de données à l'utilisateur + 3) L'utilisateur décrit la base + 4) MSM renvoie la structure de la base (tables) + 5) L'utilisateur sélectionne une table + 6) MSM renvoie la structure de la table + 7) L'utilisateur traite la structure de la table +- Extensions : + 5.a : l'utilisateur effectue une recherche sur la table +- Performance : selon la fréquence d'exécution, doit être très rapide. +L'utilisateur doit obtenir la structure de la table immédiatement. + +View content +------------ + +- Use case : 2.View content +- Goal in context : obtenir les données d'une table (son contenu) d'une base +BigTable (Hbase, HashMap...) selon le plugin de la base. +- Scope : MSM - GUI/IHM +- Level : fonctionnalité +- Primary actor : utilisateur de MSM +- Trigger : L'utilisateur souhaite voir les données contenues dans une table. +- Frequency : très souvent - 100/jour +- Pre-conditions : + PRE1 : l'utilisateur doit être connecté à la base dont il veut les + données. On dispose d'un accès à la table. +- Post-conditions : + POST1 : l'utilisateur dispose graphiquement des données contenues + dans la table. +- Main success scenario : + 1) L'utilisateur se connecte à la base de données + 2) MSM renvoie la base de données à l'utilisateur + 3) L'utilisateur décrit la base + 4) MSM renvoie la structure de la base (tables) + 5) L'utilisateur sélectionne une table et demande à voir son contenu + 6) MSM renvoie les données de la table + 7) L'utilisateur traite les données +- Extensions : + 5.a : l'utilisateur effectue une recherche sur la table +- Performance : selon la fréquence d'exécution, doit être très rapide. +L'utilisateur doit obtenir les données immédiatement. + +Monitor +------- + +- Use case : 3.Monitor +- Goal in context : surveiller la base de sorte à vérifier l'activité des noeuds (charge, espace disque...) +- Scope : MSM - GUI/IHM +- Level : fonctionnalité +- Primary actor : utilisateur de MSM +- Trigger : +- Frequency : peu souvent - 10/jour +- Pre-conditions : + PRE1 : +- Post-conditions : + POST1 : +- Main success scenario : + 1) + 2) + 3) + 4) + 5) + 6) + 7) +- Extensions : + +- Performance : la qualité du monitoring est tout aussi importante que +la temps-réel (actualité des données) de la tâche. + +Import +------ + +- Use case : 4.Import +- Goal in context : importer des données dans une base de données +(tables, données). +- Scope : MSM +- Level : fonctionnalité +- Primary actor : utilisateur de MSM +- Trigger : l'utilisateur désire importer ses données dans une base +- Frequency : peu souvent - 2/jour +- Pre-conditions : + PRE1 : la base de données doit exister et être connue + PRE2 : le fichier d'importation doit exister + PRE3 : l'utilisateur doit être connecté à la base +- Post-conditions : + POST1 : les données sont insérées dans la base + POST2 : les données sont manipulables +- Main success scenario : + 1) L'utilisateur se connecte à la base de données + 2) L'utilisateur désire importer des données dans la base + 3) MSM demande à l'utilisateur de sélectionner un fichier + d'imporation + 4) L'utilisateur sélectionne un fichier d'importation + 5) MSM importe les données contenues dans le fichier + 6) MSM renvoie le résultat de l'importation à l'utilisateur + 7) L'utilisateur traite les données de la base +- Extensions : +- Performance : la rapidité d'exécution est primordiale (le volume de données étant assez élevé). +On priviligie la qualité avec une fiabilité haute. +- Open issues : Que faire si erreur lors du traitement du fichier ? +=> Reporter l'erreur à l'utilisateur. + + +Export +------ + +- Use case : 5.Export +- Goal in context : exporter des données dans un fichier depuis une base +(tables, données). +- Scope : MSM +- Level : fonctionnalité +- Primary actor : utilisateur de MSM +- Trigger : l'utilisateur désire exporter les données de la base en cours +- Frequency : peu souvent - 2/jour +- Pre-conditions : + PRE1 : la base de données doit exister et être connue + PRE2 : l'utilisateur doit être connecté à la base +- Post-conditions : + POST1 : un fichier contenant les données est créé + POST2 : le fichier peut servir pour une réimportation +- Main success scenario : + 1) L'utilisateur se connecte à la base de données + 2) L'utilisateur désire exporter les données de la base + 3) MSM demande un nom de fichier + 4) L'utilisateur entre un nom désiré pour le fichier + 5) MSM crée le fichier + 6) MSM réalise l'exportation dans le fichier +- Extensions : +- Performance : la rapidité d'exécution est primordiale (le volume de données étant assez élevé). +On priviligie la qualité avec une fiabilité haute. +- Open issues : Que faire si erreur lors de transmission des données dans +le fichier ? + +Connect +------- + +- Use case : 6.Connect +- Goal in context : se connecter à une base de données BigTable +préalablement choisie +pour la rendre active dans MSM. +- Scope : MSM - GUI/IHM +- Level : fonctionnalité +- Primary actor : utilisateur de MSM +- Trigger : l'utilisateur désire se connecter à une base +- Frequency : très souvent - 100/jour +- Pre-conditions : + PRE1 : la base distante doit exister +- Post-conditions : + POST1 : l'utilisateur est connecté + POST2 : l'utilisateur peut manipuler la base +- Main success scenario : + 1) L'utilisateur désire se connecter + 2) L'utilisateur choisit une base de données à laquelle se connecter + 3) En fonction de la base, MSM demande diverses informations de + connexion (utilisateur, mot de passe, port...) + 4) L'utilisateur entre ces informations et se connecte + 5) MSM renvoie le résultat de la connexion + 6) L'utilisateur traite la base +- Extensions : + 2.a : l'utilisateur recherche le nom d'une base +- Performance : la rapidité d'exécution est primordiale étant donné la fréquence d'exécution. +Gestion des erreurs importante. + +Extend +------ + +- Use case : 7.Extend +- Goal in context : Etendre MSM en développant un plugin correspondant à +une nouvelle base de données BigTable (graphique et fonctionnalités) +pour la rendre active dans MSM. +- Scope : MSM - GUI/IHM +- Level : fonctionnalité +- Primary actor : développeur +- Trigger : le développeur veut ajouter une nouvelle base dans MSM +- Frequency : peu souvent 1/semaine +- Pre-conditions : + PRE1 : le développeur dispose des API MSM +- Post-conditions : + POST1 : la base de données développée est utilisable dans MSM +- Main success scenario : + 1) Le développeur désire développer un plugin + 2) Le développeur implémente l'interface BigTable + 3) Le développeur implémente l'interface GUI en se servant de + son implémentation de BigTable + 4) Le développeur crée un JAR du plugin +- Extensions : +- Performance : + Modèles et architecture du domaine ----------------------------------