Nous allons commencer par prendre un peu de temps pour résumer ce qui a été dit dans cette présentation et puis nous le confronterons aux critères de validation.
Rasdaman est un serveur de données permettant de gérer des MDD. Ceux-ci sont des structures inspirées des tableaux informatiques qui permettent de gérer des rasters de dimensionnalité et taille a priori in nis. De plus, les MDD peuvent contenir des cellules dont le type est composé de plusieurs types primitifs.
Rasdaman est un middleware et le stockage des informations est délégué à un SGBD, dans notre cas, PostgreSQL. Le rôle de Rasdaman est la gestion des MDD uniquement. Il ne prend donc pas en charge les métadonnées. Ainsi, Ras- daman se rapproche du paradigme des architectures hybrides, même si toutes les données sont stockées dans la même base de données. Cela se re ète dans le langage de requêtes inspiré de SQL qui semble très riche mais qui est limité aux MDD. Cela se re ète également dans les ltres de données qui ne gèrent pas vraiment les métadonnées. En particulier, l'aspect géographique des infor- mations est perdu.
Finalement, la gestion interne des rasters est complexe et Rasdaman n'ore pas d'outil d'aide à la conception ni de modélisateur de traitements.
Il est maintenant possible d'eectuer une comparaison partielle avec les cri- tères de validation. En ce qui concerne les fonctionnalités, Rasdaman répond à presque tous les critères obligatoires. Le point du catalogue de données sera rediscuté par la suite. Concernant les données, Rasdaman s'en sort a priori très bien celles qu'il peut gérer. En revanche, il ne gère pas du tout les métadonnées. Ce constat est le plus important désavantage de Rasdaman jusqu'à présent et va avoir un impact sur les traitements et les requêtes ; les requêtes sur les les métadonnées ne sont évidemment pas possibles, les projections cartographiques non plus. À l'inverse, les requêtes se limitant à la matrice de valeurs semblent possibles.
Nous allons maintenant passer au prototype pour tester réellement les capa- cités de Rasdaman.
Chapitre
5
Le prototype
Dans cette partie, nous allons concevoir et implémenter le prototype. Il s'agit donc de tester les capacités réelles de Rasdaman d'un point de vue qualitatif et quantitatif. Ce chapitre est divisé en quatres sections.
La première décrira l'environnement dans lequel le prototype a été déve- loppé ainsi que l'installation de Rasdaman et la manière dont seront évaluées les performances.
La seconde section s'intéressera aux données à insérer dans le serveur. Les données utilisées seront décrites et confrontées à celles mentionnées dans la liste des critères de validation (cfr. section 3.3). Elles seront alors chargées dans le serveur et les performances mesurées. Une dernière partie comparera les objectifs à ce qui a été réalisé.
La troisième section est consacrée aux traitements et aux requêtes. La liste de ceux à soumettre au prototype est dressée en rapport avec les critères de validation. Ces traitements et requêtes sont alors passés en revue et leur perfor- mance mesurée. La section se termine par une brève conclusion.
En n, la dernière section fait le point sur ce qui a pu être appris grâce au prototype.
5.1 Environnement de travail
Le prototype est réalisé sur un poste xe dans l'environnement suivant : ? Ordinateur AMD Athlon 64, 2 GHz et 1024 MB de mémoire vive. ? Système d'exploitation Linux Ubuntu Jaunty -9.04.
? Rasdaman version 8.0. ? PostgreSQL 8.3.12.
Une nouvelle version de Rasdaman est disponible depuis le 28 juillet 2011 mais n'apporte pas de modi cations majeures.
5.1.1 Installation
L'installation de PostgreSQL est bien documentée dans son manuel. Celle de Rasdaman est plus complexe. Deux manuels lui sont dédiés. Le premier est le manuel d'installaion à proprement parler. Le second est le manuel d'intégration
avec PostgreSQL. Les informations sont parfois contradictoires entre les deux manuels et le celui d'intégration n'est pas à jour.
Il est conseillé de créer un compte d'utilisateur au nom de rasdaman. Une fois PostgreSQL en place, il faut installer tous les paquets requis par Rasda- man. La liste de ceux-ci est présentée dans le manuel d'installation (qui précise qu'il vaut mieux aller voir la liste des paquets sur le site de Rasdaman). Une fois installés, il faut télécharger l'archive contenant Rasdaman. La procédure d'installation est décrite dans le manuel d'installation. Il s'agit de décompresser l'archive, compiler le programme et l'installer. Une fois l'opération réussie, reste à con gurer quelques variables d'environnement.
Il faut alors passer à l'intégration avec PostgreSQL. Là aussi, quelques va- riables d'environnement ont besoin d'être con gurées. Elles sont décrites dans le manuel d'intégration. Il faut alors con gurer PostgreSQL pour qu'il accepte les connexions TPC/IP. Le manuel d'intégration n'est pas à jour sur ce point. Il faut se reporter à la documentation de PostgreSQL. Les con gurations se font dans les chiers postgresql.conf et pg−hba.conf. Le premier chier per-
met d'autoriser les connections TCP/IP et le second permet de restreindre les utilisateurs accédant à la base de données.
À partir de là, on peut revenir au manuel d'installation pour initialiser la base de données. Le script create−db.shcrée une base de données du nom de
RASBASEet y charge les tables et les types par défaut.
Rasdaman est alors prêt pour fonctionner. Il faut d'abord lancer le médiateur (rasmgr) et puis démarrer les serveurs. Le script start−rasdaman.shest fourni
à cet eet.
5.1.2 Mesures de performances
Au vu des possibilités de Rasdaman, les mesures de performances seront réalisées avec la commande time de linux qui permet d'obtenir des informations sur le temps que prend une autre commande pour s'exécuter. La précision de la commande est de l'ordre du centième de second donc largement su sante dans le cadre de notre application.
Les requêtes seront exécutées via la commande rasql. C'est donc elle qui fait l'objet de la mesure. Celle-ci est légèrement biaisée du fait qu'elle ne porte pas seulement sur le temps de la requête mais sur tous les éléments suivants :
? La connexion entre le client et le médiateur.
? La redirection depuis le médiateur vers un rasserver et la connexion à ce dernier.
? L'envoie des données au rasserver.
? Le traitement de la requête à proprement parlé. ? Le renvoi du résultat.
Cette remarque avait pour vocation de résoudre une ambiguité de langage. Le biais en lui même ne pose pas de problème : toutes ces étapes doivent s'eectuer quelle que soit la requête. Les mesurer ne porte donc pas préjudice. De plus, les mesures s'eectuant en local, elles ne sont pas entâchées d'un bruit lié au réseau. Dès lors, quand on parlera de la mesure du temps des requêtes, nous ferons référence à toutes ces étapes.