memoire-master/chapters/etat-de-l_art.typ

146 lines
21 KiB
Plaintext

#import "../template.typ": *
#pagebreak(weak: true)
= Etat de l'art
== Présentation d'InfSuite
Début *2016*, les différents cantons Suisses étaient sur le client lourd Kuba, l'application mère d'InfSuite. Ce logiciel était payé par l'#ref-glossary(term: "OFROU")[OFROU] pour une meilleure gestion des infrastructures routières en Suisse.
En *2019*, elle lance un appel d'offres dans le but de réduire les coûts liés aux applications qu'elle utilise. L'application Kuba étant une apllication hautement complète et complexe, le budget n'était alors pas forcément adapté à tous les cas d'usages des différents cantons, certains yant des besoins différents en termes de gestion.
Unit Solutions décide alors de se lancer dans la conception d'une nouvelle solution nommée InfSuite, qui reprnd le principe de l'application mère Kuba. La grande différence sur cette nouvelles application , est le découpage plus fin des différentes fonctionnalités. elle permet de proposer aux différents clients de ne leur orctroyer l'accès à certaines fonctionnalités que s'ils en ont réellement besoin et permer ainsi de faire coller le budget au besoin.
Les principaux objetifs de l'application étaient donc:
- De n'implémenter que les fonctionnalités que les cantons seraient suceptibles d'utiliser.
- Vendre l'application à l'OFROU apuuyé par la nouvelle philosophie de l'application qui réduit les coûts de l'application.
- Livrer une version utilisable au bout d'une année et demi maxium pour permettre aux cantons de tester l'application et de s'adapter au nouveau système.
Finalement adopté par la suite par la majorité des cantons suisses, l'application InfSuite est une application géographique basée sur des technologies web récentes. Le but de l'application est de permettre de faire l'état et le suivi d'ouvrages d'art dans le temps. Lorsqu'un organisme résponable de la préservation des ouvrages d'art vient faire des constatations à une certaine date d'un ouvrage, il enregistres toutes les informations et données relatives dans l'application.\
Lorsqu'une expertise ulterieure est réalisée sur l'ouvrage, de nouvelles observation seront ajoutées et avec ces nouvelles données l'application fournira un résumé de l'évolution de cet ouvrage, si il a un comportement particulier, s'il faut planifier une intervention de conservation, etc.
Toutees ces données sont accessibles depuis n'importe quel terminal et depuis n'importe ou tant que le client possède une connexion internet et un compte ayant les droits requis pour accéder aux données.\
La suite logicielle InfSuite comprend plusieurs types d'outils, tous basés sur le même fonctionnement, mais avec des domaines d'application différents pour permettre d'effectuer des constatations plus spécifiques en fonction du domaine ciblé. Par exemple, sur l'outil InfAqua, il est possible de faire l'observation de cours d'eau (lit de rivières, berges...), InfRail des voies ferrées, InfVias de routes... Pour conserver la compréhensibilité de ce document, InfKuba sera l'outil de référence pour le fonctionnement technique de l'application.
L'application présente de manière simplifiées les données relatives aux différentes constatations sur une carte. Elle représente sous forme de pastilles colotées la note moyenne des ouvrages par zones géographiques lorsque plusieurs ouvrages se trouvent très proches les uns des autres comme le montre la // TODO : Image InfKuba
En fonction du niveau de zoom, les différents ouvrages se séparent les uns des autres et permettent de voir la dernière note calculée pour l'ouvrage sous forme d'une petite épingle qui représente l'objet d'infrastructure. La couleur varie du vert au rouge indiquant respectivement que l'ouvrage est en bon état ou qu'il faut
intervenir le plus rapidement possible. En ouvrant les détails de l'objet on peut retrouver un onglet regroupant les informations relatives à l'ouvrage d'art. On y retrouve des données basiques comme son nom, le canton propriétaire de l'ouvrage, ses dimensions, des commentaires, sa position géographique, des photos, etc.
D'autres onglets permettent de retrouver des informations plus précises telles que les observations de l'ouvrage, des graphiques sur l'évolution de l'ouvrage dans le temps, visualiser l'ouvrage en 3D (si fourni par le client) …
Chaque ouvrage appartient à un canton, mais il peut être prêté à d'autres cantons, comme dans le cas où un pont serait partagé entre deux cantons par exemple. Un autre exemple d'ouvrage partagé est lorsque la gestion est déléguée à une ville plutôt qu'au canton. À ce moment, dans l'application, l'ouvrage appartient au canton et est « prêté » à la ville qui en est chargé. Chaque donnée générée à partir de l'application, est rattachée au client qui en est à l'origine, ce qui permet d'avoir un historique en cas de problème. Pour permettre de rendre l'application plus légère, l'application est basée sur une architecture trois tiers.
Le premier tiers de l'application correspond à la base de données. Cette base de données est une base PostgreSql. C'est ici que toutes les données sont stockées ainsi que les relations entre chaque donnée existante. Je détaillerais les particularités techniques de cette base de données qui peuvent expliquer la pertinence de sont utilisation dans ce contexte plus loins dans ce rapport.
Le second tiers de l'application correspond à l'API. Une API web, est une interface de programmation qui permet à des applications informatiques de communiquer entre elles via Internet. Elle définit les règles et les formats de données pour faciliter l'échange d'informations entre les différentes applications.
Cette API est le serveur back-end qui permet de faire la relation entre le monde extérieur et les données brutes stockées en base de données. Le serveur est développé en C\# avec l'ORM Entity Framework. Cette interface permet notamment de mettre en forme les données pour qu'elles correspondent aux besoins du troisième et dernier tiers.
Le dernier tiers correspond à la partie visible de l'application. Appelé frontend, il met à disposition de manière visuelle et simplifiée les données. Ce dernier tiers permet également à l'utilisateur de créer, modifier ou effacer des données. Il est développé en TypeScript avec le framework Angular pour permettre de créer une application dynamique et réactive.
Le dernier service complémentaire est un serveur GIS. Ce serveur permet de fournir des informations cartographiques comme des adresses. Il permet également de délivrer les fonds de cartes. Ils peuvent être hébergés et entretenus par Unit Solutions, ou alors par d'autres entreprises comme le fond de carte Open Street Map appartenant à la fondation du même nom.
Le schéma ci-dessous représente les trois tiers de l'application communiquant ensemble et le serveur GIS permettant de fournir des informations complémentaires. L'application propose à l'utilisateur de personnaliser toute l'application. Cela comprend par exemple quel fond de carte afficher, quelles données afficher, personnaliser l'affichage de ces données tel que le type d'affichage des épingles… Ces configurations sont propres à l'utilisateur et sont sauvegardées en base de données, en parallèle de toutes les autres données de l'application.
== PostgreSQL, un système open source
=== Présentation de PostgreSQL
PostgreSQL est un système de gestion de base de données relationnelle (SGBDR#footnote("Système de gestion de base de données relationnelle")<SGBDR_def>). Le projet est initié en 1986 par Michael Stonebraker et Andrew Yu à l'Université de Californie à Berkley.
L'une des force majeur de ce système est d'être OpenSource, ce qui signifie qu'il est développé et maintenu par la communauté en plus des développements apportés par la société mère PostgreSQL.
PostgreSQL tient sa réputation de sa fiabilité, sa robustesse et sa richesse fonctionnelle que je détaillerais juste après.
=== Les principes de base
Comme dit précédement, PostgreSQL est un SGBDR@SGBDR_def. Il utilise le language SQL#footnote("Structured Query Language")<SQL_def> pour chercher ou manipuler les données stockées. Le système met à disposition une serie de fonctions pour permettre ces interactions, à savoir:
- Les transactions: un ensemble d'une ou de plusieures opérations regroupées en une seule opération atomique.
- Les vues: table virtuelle qui sélectionne et affiche des données à partir d'une ou plusieurs tables réelles.
- Les contraintes d'inrégrité: règles qui garantissent la validité et la cohérence des données dans une base de données.
- Les procédures stockées: programme écrit en SQL qui est stocké dans une base de données et peut être exécuté à la demande.
- Les triggers: procédure stockée qui est automatiquement exécutée en réponse à un événement spécifique sur une table.
- Les fonctions utilisateurs: procédure stockée qui renvoie une valeur et peut être utilisée dans une requête SQL comme une fonction intégrée.
PostgreSQL à également l'avantage d'être multiplateforme. Il peut ainsi fonctionner sur des environnements variés avec des systèmes d'exploitations différents, comme par exemple Windows, Linux, Mac,... L'une des forces de ce système de gestion de base de données réside dans sa capacité à gérer des volumes importants de données allant jusqu'à plusieurs Terraoctets. Cette gestion passe par différents points clefs, à savoir:
- L'indexation
- Le partitionnement
- La gestion du cache
- Des notions de concurrence et d'isolation
- De la réplication et du sharding#footnote("Alié à la réplication il permet de répartir la charge sur plusieures instances d'un même serveur.").
=== Les avantages de PostgreSQL
PostgreSQL est un SGBDR@SGBDR_def très populaire pour plusieurs raisons:
- Il est open source, ce qui signifie qu'il est gratuit et que son code source est disponible pour tous. Cela permet à la communauté de développeurs de contribuer à son amélioration et de créer des extensions pour ajouter des fonctionnalités supplémentaires.
- Il est très fiable et robuste, ce qui en fait un choix idéal pour les applications critiques et les environnements de production.
- Comme vu précédement il est très performant, grâce à son moteur de stockage et son optimiseur de requêtes. Il est capable de gérer de gros volumes de données et de supporter des charges de travail élevées.
- Le système au complet est très flexible, grâce à son architecture modulaire et à son support des extensions. Il peut s'adapter à de nombreux types d'applications et de besoins, notement pour des applications géographiques avec des besoins plus complets.
- De pars sa nature open source, il est compatible avec de nombreux langages de programmation, tels que Python, Java, C++, Ruby, PHP, etc.
Il est également important de noter que PostgreSQL tient sa popularité, au delà de ses performances et fonctionnalités déjà complètes, de par sa capacité à gérer des types de données bien plus complexes. Il propose la gestion de modèles de données complexes tel que des données géographiques et des données attributaires, mais permet surtout de gérer les relations entre ces données.\
Cette gestions de données complexe permet une ouverture sur d'autre système, notamment QGIS, un système d'informations géographiques, et ainsi d'étendre les fonctionnalités proposées par ce système.\
En type de fichiers volumineux, on peut par exemple citer les fichiers MAJICS, RPG, référetiels vecteurs, ...
=== Les inconvénients de PostgreSQL
PostgreSQL présente également quelques inconvénients qu'il faut prendre en compte:
- Il peut être plus complexe à installer et à configurer que d'autres SGBDR@SGBDR_def, tels que MySQL ou SQLite.
- Il peut nécessiter plus de ressources matérielles (mémoire, CPU, espace disque) que d'autres SGBDR@SGBDR_def pour fonctionner de manière optimale.
- Il peut être moins performant que d'autres SGBDR@SGBDR_def pour certaines tâches spécifiques, telles que les requêtes de type OLAP (Online Analytical Processing).
"PostgreSQL 12 - Guide de l'administrateur" de Guillaume Lelarge et Stéphane Schildknecht, éditions Eyrolles, 2020.
"PostgreSQL - Maîtrisez les fondamentaux du SGBD open source" de Régis Montoya, éditions ENI, 2019.
"PostgreSQL - Le guide complet de l'administrateur et du développeur" de Joshua D. Drake et Peter Eisentraut, éditions Pearson, 2018.
=== Conclusion
PostgreSQL est un SGBDR@SGBDR_def open source très populaire, grâce à sa fiabilité, sa robustesse, sa richesse fonctionnelle et sa flexibilité. Il est utilisé dans de nombreux domaines, tels que la finance, la santé, l'éducation, le gouvernement, etc. Il est également compatible avec de nombreux langages de programmation et de nombreux systèmes d'exploitation. Cependant, il peut être plus complexe à installer et à configurer que d'autres SGBDR@SGBDR_def et nécessiter plus de ressources matérielles. Malgré ces inconvénients, PostgreSQL reste un choix idéal pour de nombreuses applications critiques et environnements complexes.
== Problématique
== Existants
Effectuer une migration de base de données n'est pas une tâche anodine. Cela demande du travail en amont, il faut analyser les différents scénarios possibles, estimer un budget pour une telle tâche, réaliser de potentiels développements, s'assurer de la fiabilités avant de mettre tout ça en pratique et enfin la réalisation de l'étape cruciale sur les environnements sensibles.
Pour faire une migration de base de données il existes de nombreuses solutions, certaines plus couteuse, d'autre plus fiables, encore d'autres des plus spécialisées, ... Il faut donc dans un premier temps trouvers différents outils pour comparer les avantages et leur faiblesses.\
=== Les outils
On peut dans un premier temps penser à effectuer cette migration grâce à des outils spécialisés qui se chargent de faire la migration automatiquement et de s'assurer de la pérennité entre les données de l'ancienne base et les données insérée dans la nouvelle.\
En prenant pour exemple l'outil Oracle Data Dump fournit par l'entreprise Oracle, ce logiciel permet de sauvegarder et restaurer des données et des métadonnées pour les bases Oracle.\
Il est rapide et fiable, on peut ainsi lui fournir un fichier #ref-glossary(term: "Dump")[dump] de la base source et l'outil va se charger, grâce à ce fichier, d'intégrer les données dans la base cible.\
Microsoft propose sa solution alternative SSMA pour importer les types de bases Access, DB2, MySQL, Oracle, SAP ASE vers leurs différents SGBDR@SGBDR_def propriétaires (à savoir les suites SQL Server).\
Sur le même principe les outils MySQL workbench, AWS Database Migration Service (DMS) et PgAdmin permettent de réaliser le même type de migration vers leurs systèmes propriétaires à savoir respectivement MySQL, AWS et PostgreSQL.
Les principaux désavantages de ce genre de solutions sont:
- L'import des données reste assez stricte et ne permet pas de flexibilité, si les données ne sont pas compatiblé, il faut passer du temps à travailler le modèle de données pour essayer de palier aux incompatibilités.
- Ils peuvent également rendre les migrations onnéreuses avec certaines solutions qui coutent jusqu'à plusieures centaines d'euros pour les entreprises.
- Les logiciels proposés peuvent parfois être complexes et demander un certain temps d'adaptation avant de réellement pouvoir effectuer la tâche de migration.
=== Les types de migrations
Il est possible, comme vu précédement, d'effectuer une migration *à partir d'outils automatiques*. L'avantage est de déléguer la majorité de la complexité à une application qui va se charger d'effectuer la tâche cruciale et de réduire les risques d'erreurs pour de grosses applications. On retrouve en général des outils plus poussés pour offrir une plus grande précision et une meilleurs cohérence dans la migration des données.
Il faut principalement noter, pour ce genre d'outils, qu'ils sont en général à déstination d'un certain type de base précis et qu'ils peuvent donc manquer de compatibilié. Ils peuvent également ne pas prendre en charge tous les types de bases de données ou tous les scénarios de migration, ce qui peut limiter leur utilité dans certains cas.\
Enfin le cout réel de ces outils peut être élevé autant par leur prix réel fixé par l'éditeur, mais aussi puisque la majorité du temps ils necessitent une expertise pour être pris en main avant de pouvoir être réellement utilisé.
Une alternative à prendre en compte est la migration *manuelle*. Cette solution est interessante pour les petites bases de données sans trop de complexité. Le but est d'exporter un fichier #ref-glossary(term: "Dump")[dump] de la base source et de l'importer dans la base cible si possible, ou d'exporter les données sous un autre format pour l'importer simplement. Les couts de cette techniques sont faibles voir nuls et permet une flexibilité lors de la migration. Cependant le temps de migration peut se révéler très long, apporte un gros facteur de risque d'erreurs et devient complexe voir inaproprié dans le cadre de bases avec de gros volumes.
Une autre technique consiste elle à effectuer la migration *via des scripts*. Le but est de développer un processus qui va récupérer les données de la base source, effectuer si besoin des opérations sur les différentes données pour les copier dans la base cible pas la suite.\
Quasiement tous les languages de programmation permettent de créer des scripts pour effectuer ce genre de migration, il suffit qu'un driver pour les bases utilisées soit disponible pour le language souhaités.\
L'avantage de ce type de migration réside dans la flexibilité totale pour personnaliser le processus de migration. Il est également possibe de migrer des bases de données plus grandes et plus complexes avec des incompatibilités entre elles, puisqu'il est possible d'agir sur les données avant de les transférer vers la nouvelle base, ce qui confère un contrôle total sur la migration.\
Cependant il faut noter que les couts de la migration peuvent également devenir élevés puisqu'il faut développer un script, donc payer un développeur. Il faut également prendre en compte que le temps de migration peut être long puisqu'il faut développer la solutions en amont et qu'il faut en général s'assurer de la qualité de code avant de l'utiliser sur les environnements sensibles.\
Même en essayant de prévenir les différents cas d'erreurs possibles, il se peut que certaines arrivent à se glisser, dans ce cas, le risque d'erreur humaines n'est pas négligeable.
Enfin, une solution peut se porter sur *la migration en temps réelle*. La migration en temps réel est une technique qui permet de répliquer les données de la base source vers la base sible en temps réel, sans interropre les opérations sur la base source. Elle est souvent utilisée pour minimiser le temps d'arrêt lors de la migration de bases de données critiques (sceteur de la santé, du commerce, de la sécurité,...).\
Ce processus de migration en temps réel implique les même couts qu'une migration par script ou par outil automatiques puisqu'elle va se reposer sur l'un de ces deux pilier. Elle va cependant permettre de minimiser l'impact sur le service actif puisqu'elle ne requiert généralement pas de mettre le service à l'arret.\
Il faut cependant noter que lors de la migration, l'impact des erreurs pouvant se glisser durant le processus de migratiuon, deviendrait rapidement beaucoup plus important puisque les données sont consommées à l'instant ou elles sont migrées.\
La migration ene temps réel n'est donc réellement interessante que dans le cas ou, la relation entre une application qui ne peut pas avoir de temps d'inactivité avec les données de la bases, est critique.
== Conclusion
Il existe de nombreux outils pour effectuer des migrations de données à partir de bases de données. Cependant il faut prendre en compte différents critères, comme la complexité de la migration, le budget aloué, les système source et cibles, mais aussi la philosophie à appliquer lors de cette étape. Par exemple dans un cas le temps de aloué à la migration peut être ignoré si ce qui compte est d'effectuer la migration sans arrêter le service, dans un autre cas le temps d'arrêt est moins important que la fiabilité de la migration.\
Il faut donc réfléchir en amont à la manière d'effectuer cette étape mais surtout à la pertinence de cette tâche pour éviter des couts supplémentaires qui pourraient se révéler inutiles.\
Toutes ces questions permettent de cibler besoin et donc le type de migration souhaité pour, par la suite, transférer ses données entre deux système.