feat: Add CMN inputs, Khobs inputs, more context for glossary and data definitions
This commit is contained in:
parent
2843bbb3de
commit
8b86a50410
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 107 KiB After Width: | Height: | Size: 69 KiB |
@ -24,7 +24,7 @@ J'ai pu conclure ces trois premières années d'études à l'UHA 4.0 il y a deux
|
||||
|
||||
=== Le parcours master
|
||||
|
||||
Une année à l'UHA 4.0 du parcours "Master Informatique et Mobilité" se divise en deux parties dupliquées sur deux années. Dans un premier temps, l'étudiant doit réaliser, en groupe de trois ou quatres élèves, un "fil rouge". Ce projet a pour but de mettre en pratique les connaissances acquises durant les séances de cours assurées par des enseignants chercheurs ou autres intervenants. Les cours portent sur les technologies qui pourront et seront réutilisées durant le fil-rouge tel que l'Intelligence Artificielle, l'optimisation combinatoire, la fouille de données, etc. La seconde partie de l'année est une phase de neufs moins durant laquelle l'étudiant est dans une entreprise pour mettre en pratique, consolider et acquérir de nouvelles connaissances.
|
||||
Une année à l'UHA 4.0 du parcours "Master Informatique et Mobilité" se divise en deux parties dupliquées sur deux années. Dans un premier temps, l'étudiant doit réaliser, en groupe de trois ou quatres élèves, un "fil rouge". Ce projet a pour but de mettre en pratique les connaissances acquises durant les séances de cours assurées par des enseignants chercheurs ou autres intervenants. Les cours portent sur les technologies qui pourront et seront réutilisées durant le fil-rouge tel que l'Intelligence Artificielle, l'optimisation combinatoire, la fouille de données, etc. La seconde partie de l'année est une phase de neuf mois durant laquelle l'étudiant est dans une entreprise pour mettre en pratique, consolider et acquérir de nouvelles connaissances.
|
||||
|
||||
Lors de ma première année du parcours de master, nous avons eu comme sujet de fil rouge, la gestion et l'automatisation de l'arrosage des plantes. Le but était de pouvoir récolter des données environnementales liées à une plante, puis les réutiliser pour prendre des décisions à l'aide de divers outils.\
|
||||
Nous avons pu utiliser une sonde de température et un capteur d'humidité pour récolter les données puis les envoyer grâce à un microcontrôleur vers un serveur pour stocker et traiter les données.\
|
||||
@ -40,9 +40,9 @@ Mes deux années de master ont consécutivement été réalisées au sein de l'e
|
||||
== L'entreprise Unit solutions
|
||||
|
||||
Unit Solutions est une entreprise suisse, basée à Allschwil dans le canton de Bâle-Campagne. Fondée en 1986 premièrement sous le nom CADRZ, dédiée à la création d'un cadastre numérique pour la ville d'Allschwil, elle est aujourd'hui dirigée par M. Thierry MOEBEL.\
|
||||
La politique de développements de l'entreprise va par la suite changer pour finalement réaliser ses propres logiciels et en faire la maintenance. L'entreprise compte actuellement une vingtaine d'employés pour le développement des différentes solutions, le support et l'administratif@unit-solutions. Unit Solutions emploie un autre alternant en provenance de l'UHA 4.0, M. Tom Willemin, et un ancien étudiant maintenant en CDI, Thomas Fritsch. Les développeurs sont répartis entre les différents projets pour apporter leur contribution avec, pour chacun des projets, un responsable attitré.
|
||||
La politique de développement de l'entreprise va par la suite changer pour finalement réaliser ses propres logiciels et en faire la maintenance. L'entreprise compte actuellement une vingtaine d'employés pour le développement des différentes solutions, le support et l'administratif@unit-solutions. Unit Solutions emploie un autre alternant en provenance de l'UHA 4.0, M. Tom Willemin, et un ancien étudiant maintenant en CDI, Thomas Fritsch. Les développeurs sont répartis entre les différents projets pour apporter leur contribution avec, pour chacun des projets, un responsable attitré.
|
||||
|
||||
L'équipe du support de l'entreprise, en relation directe avec les clients, s'assure du bon fonctionnement des applications et fait permet de faire le lien entre le client et les chefs de projets pour remonter les problèmes potentiels.
|
||||
L'équipe du support de l'entreprise, en relation directe avec les clients, s'assure du bon fonctionnement des applications et permet de faire le lien entre le client et les chefs de projets pour remonter les problèmes potentiels.
|
||||
|
||||
Les développements au sein de l'entreprise reposent sur quatre gros projets:
|
||||
- Langsam Verkehr2 est une solution visant la gestion des sentiers de mobilité douce en Suisse. Cela comprend la gestion des sentiers de randonnée ou les pistes cyclables.
|
||||
|
||||
@ -5,15 +5,15 @@
|
||||
|
||||
== Présentation d'InfSuite
|
||||
|
||||
Début *2016*, les différents cantons suisses utilisaient 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 *1994*, UnitSolutions se charge des développements de l'application Kuba. Jusqu'à *2016* les différents cantons suisses utilisaient le client lourd Kuba, l'application mère d'InfSuite. Elle était dans un premier temps payé par l'#ref-glossary(term: "OFROU")[OFROU] à chaque canton pour permettre une meilleure gestion des infrastructures routières en Suisse.\
|
||||
Pour simplifier la gestion des licences et des coûts engendrés, une version centralisée de l'application est mise à disposition des cantons. L'application n'est alors plus installée indépendamment chez les clients, mais les clients accèdent à une instance commune unique de l'application. Les frais engendrés pas l'application étant conséquents, l'#ref-glossary(term: "OFROU")[OFROU] décide alors de maintenir sa version centralisée de l'application, mais de faire payer indépendamment les licences par les cantons clients.\
|
||||
L'application Kuba étant une application hautement complète et complexe, le budget n'était alors pas forcément adapté à tous les cas d'usages des différents cantons, certains ayant des besoins différents en termes de gestion. La pression budgétaire était alors relativement importante pour certains.
|
||||
|
||||
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 application hautement complète et complexe, le budget n'était alors pas forcément adapté à tous les cas d'usages des différents cantons, certains ayant des besoins différents en termes de gestion.
|
||||
|
||||
Unit Solutions a alors décidé de se lancer dans la conception d'une nouvelle solution nommée InfSuite, qui reprend le principe de l'application mère Kuba. La grande différence sur cette nouvelle application est le découpage plus fin des différentes fonctionnalités. Elle permet de proposer aux différents clients de ne leur octroyer l'accès à certaines fonctionnalités que s'ils en ont réellement besoin et permet ainsi de faire coller le budget au besoin.
|
||||
En *2017* Unit Solutions décide alors de se placer sur le marché avec sa propre alternative. L'entreprise décide de se lancer dans la conception d'une nouvelle solution nommée InfSuite, qui reprend le principe de l'application mère Kuba. La différence majeure de cette nouvelle application est le découpage plus fin des différentes fonctionnalités. Elle permet de proposer aux différents clients de ne leur octroyer l'accès à certaines fonctionnalités que s'ils en ont réellement l'utilité et ainsi permettre de faire coller le budget à leurs besoins.
|
||||
|
||||
Les principaux objectifs de l'application étaient donc:
|
||||
- De n'implémenter que les fonctionnalités que les cantons seraient susceptibles d'utiliser.
|
||||
- Vendre l'application à l'#ref-glossary(term: "OFROU")[OFROU] grâce à la refonte de l'application qui réduit les coûts de l'application.
|
||||
- Vendre l'application aux cantons utilisant Kuba grâce à la refonte de l'application qui réduit les coûts globaux.
|
||||
- Livrer une version utilisable au bout d'un an et demi maximum pour permettre aux cantons de tester l'application et de s'adapter au nouveau système.
|
||||
|
||||
Finalement adoptée 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 responsable de la préservation des ouvrages d'art vient faire des constatations à une certaine date d'un ouvrage, il enregistre toutes les informations et données relatives dans l'application.
|
||||
@ -55,21 +55,22 @@ Cette #ref-glossary(term: "API")[API] est le serveur #ref-glossary(term: "Back-E
|
||||
|
||||
Le dernier tiers correspond à la partie visible de l'application. Appelé #ref-glossary(term:"Front-End")[Front-End], 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, un langage surrensemble de JavaScript, et avec le framework #ref-glossary(term: "Angular")[Angular] pour permettre de créer une application dynamique et réactive.
|
||||
|
||||
Le dernier service complémentaire est un serveur #ref-glossary(term: "GIS")[GIS]. Ce serveur permet de fournir des informations cartographiques comme des adresses. Il permet aussi 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. Il n'est pas intégré dans le concept d'architecture trois tiers puisque, comme je l'ai indiqué, ce service est indépendant et n'est pas une dépendance du reste.
|
||||
Le dernier service complémentaire est un serveur #ref-glossary(term: "GIS")[GIS]. Ce serveur permet de délivrer des informations géographiques telles que des couches vectorielles (des routes, des frontières, des polygones, ...), des analyses spatiales (superposition de différentes couches d'information), etc.\
|
||||
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. Il n'est pas intégré dans le concept d'architecture trois tiers puisque, comme je l'ai indiqué, ce service est indépendant et n'est pas une dépendance du reste. Il reste cependant important dans notre application parce qu'il dépend des informations en base de données et de notre serveur #ref-glossary(term: "Back-End")[back-end] pour fonctionner.
|
||||
|
||||
Le schéma @three-tier-archi-diagram ci-dessous représente les trois tiers de l'application communicants ensemble. 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.
|
||||
|
||||
#figure(
|
||||
image("../assets/images/three-tier-archi-diagram.png"),
|
||||
image("../assets/images/three-tier-archi-diagram.png", height: 60%),
|
||||
caption: [Représentation de l'architecture trois tiers d'InfSuite]
|
||||
)<three-tier-archi-diagram>
|
||||
|
||||
#pagebreak(weak: true)
|
||||
== #ref-glossary(term: "PostgreSQL")[PostgreSQL], un système open source
|
||||
== PostgreSQL, un système open source
|
||||
|
||||
Ce document est axé sur le travail réalisé sur une base de données. L'application utilisant une base de données #ref-glossary(term: "PostgreSQL")[PostgreSQL], je présente dans cette section ce qu'est #ref-glossary(term: "PostgreSQL")[PostgreSQL], les avantages de cette technologie, les inconvénients et enfin une conclusion à cette section orientée.
|
||||
|
||||
=== Présentation de #ref-glossary(term: "PostgreSQL")[PostgreSQL]
|
||||
=== Présentation de PostgreSQL
|
||||
|
||||
#ref-glossary(term: "PostgreSQL")[PostgreSQL] est un système de gestion de base de données relationnelle (#ref-glossary(term: "SGBDR")[SGBDR]). Le projet est initié en 1986 par Michael Stonebraker et Andrew Yu à l'Université de Californie à Berkeley.
|
||||
|
||||
@ -92,9 +93,9 @@ Comme dit précédemment, #ref-glossary(term: "PostgreSQL")[PostgreSQL] est un #
|
||||
- Le partitionnement
|
||||
- La gestion du cache
|
||||
- Des notions de concurrence et d'isolation
|
||||
- De la réplication et du #ref-glossary(term: "Sharding")[Sharding].
|
||||
- De la réplication et du #ref-glossary(term: "Sharding")[sharding].
|
||||
|
||||
=== Les avantages de #ref-glossary(term: "PostgreSQL")[PostgreSQL]
|
||||
=== Les avantages de PostgreSQL
|
||||
|
||||
#ref-glossary(term: "PostgreSQL")[PostgreSQL] est un #ref-glossary(term: "SGBDR")[SGBDR] 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.
|
||||
@ -107,7 +108,7 @@ Il est également important de noter que #ref-glossary(term: "PostgreSQL")[Postg
|
||||
Cette gestion de données complexe permet une ouverture sur d'autres systèmes, particulièrement 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érentiels vecteurs, etc.
|
||||
|
||||
=== Les inconvénients de #ref-glossary(term: "PostgreSQL")[PostgreSQL]
|
||||
=== Les inconvénients de PostgreSQL
|
||||
|
||||
#ref-glossary(term: "PostgreSQL")[PostgreSQL] présente aussi quelques inconvénients qu'il faut prendre en compte:
|
||||
- Il peut être plus complexe à installer et à configurer que d'autres #ref-glossary(term: "SGBDR")[SGBDR], tels que MySQL ou SQLite.
|
||||
@ -129,9 +130,9 @@ Par exemple, dans le cas où Google déploierait des changements de code majeurs
|
||||
|
||||
La majorité des technologies utilisées par InfSuite suivent ce système de versionnement. Malheureusement, réaliser de nouveaux développements pour l'application tout en surveillant les mises à jour des composants externes, analyser leur impact, les intégrer à l'application dès que ces dernières sont disponibles, n'est clairement pas possible. La stratégie de mises à jour utilisée est donc d'effectuer occasionnellement ces mises à jour, soit lors de moments clés (de nouvelles fonctionnalités importantes, des mises à jour de sécurité, des gains de performances, etc.), soit spontanément pour maintenir l'environnement à jour.
|
||||
|
||||
Ce cas de figure est présent à toutes les couches de l'architecture logicielle d'InfSuite, front-end, back-end, bases de données. Depuis un certain temps, l'application InfSuite utilise la version 14 du #ref-glossary(term: "SGBDR")[SGBDR] #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Sortie en septembre 2021, cette version est maintenant dépréciée en faveur de la dernière version stable de l'application 16. Cependant, la version 14 a été adoptée très tôt par InfSuite et est restée depuis la version utilisée dans l'environnement InfSuite.
|
||||
Ce cas de figure est présent à toutes les couches de l'architecture logicielle d'InfSuite, front-end, back-end, bases de données. Depuis un certain temps, l'application InfSuite utilise la version 12 du #ref-glossary(term: "SGBDR")[SGBDR] #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Sortie en septembre 2019, cette version est maintenant dépréciée en faveur de la dernière version stable de l'application 16. Cependant, la version 12 a été adoptée très tôt par InfSuite et est restée depuis la version utilisée dans l'environnement InfSuite.
|
||||
|
||||
Pour suivre la stratégie de mise à jour de l'application, le sujet d'une mise à jour de la base de données d'InfSuite, de la version 14 vers la version stable la plus récente, a été mis sur la table. Le chef de projet en charge d'InfSuite a alors demandé une expertise pour la réalisation de cette migration pour s'assurer de la viabilité, mais également d'envisager, si possible, de réaliser cette migration en utilisant les nouveautés disponibles pour cette migration.
|
||||
Pour suivre la stratégie de mise à jour de l'application, le sujet d'une mise à jour de la base de données d'InfSuite, de la version 12 vers la version stable la plus récente, a été mis sur la table. Le chef de projet en charge d'InfSuite a alors demandé une expertise pour la réalisation de cette migration pour s'assurer de la viabilité, mais également d'envisager, si possible, de réaliser cette migration en utilisant les nouveautés disponibles pour cette migration.
|
||||
Je vais donc chercher à savoir quelles sont les étapes préliminaires pour s'assurer de la viabilité d'une telle migration, comment réaliser cette migration de manière optimale dans le contexte d'InfSuite et comment s'assurer de la qualité de la réalisation de cette dernière.
|
||||
|
||||
#pagebreak(weak: true)
|
||||
|
||||
@ -75,7 +75,7 @@ Si je souhaite par exemple mettre à jour un package dans le projet "Geometry",
|
||||
|
||||
=== Compatibilité et décision
|
||||
|
||||
La première étape est de valider la compatibilité entre la version 14 et 16 de #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Une première manière de valider cela est d'aller sur les notes de mise à jour sur le site officiel et de chercher les changements qui peuvent affecter la compatibilité entre les deux bases.
|
||||
La première étape est de valider la compatibilité entre la version 12 et 16 de #ref-glossary(term: "PostgreSQL")[PostgreSQL]. Une première manière de valider cela est d'aller sur les notes de mise à jour sur le site officiel et de chercher les changements qui peuvent affecter la compatibilité entre les deux bases.
|
||||
|
||||
Après avoir analysé en détail les changements, il y a trois grandes catégories. Il y a l'impact sur l'administration système, celui sur les requêtes SQL et celui sur l'incompatibilité des données. La partie administration système n'est pas gérée par les développeurs d'InfSuite, elle est gérée par d'autres employés de l'entreprise, je peux donc me concentrer sur la partie requêtes et données.
|
||||
|
||||
@ -130,47 +130,47 @@ La dernière étape permettant de valider cette étape de migration est de s'ass
|
||||
|
||||
Pour effectuer un test de performance, le système utilise une fonctionnalité gourmande en ressource, les groupes. Dans l'environnement InfSuite, il est possible d'afficher sur la carte les objets d'infrastructure. Par défaut tous les objets d'un DataOwner sont affichés. Pour permettre d'axer son travail sur des objets d'infrastructures particuliers, alors il est possible d'appliquer un filtre à toutes ces entités. Le mode "Groupe" de l'application permet de créer alors deux types différents de filtres.
|
||||
|
||||
Le premier type de filtres est un filtre statique. Peu gourmand en ressource et très simple d'utilisation, on peut y ajouter des entités manuellement et cela va permettre de n'afficher que les objets sélectionnés dans l'application. Fonctionnellement parlant ce n'est qu'une relation de base de données.
|
||||
Le premier type de filtre est un filtre statique. Peu gourmand en ressource et très simple d'utilisation, on peut y ajouter des entités manuellement et cela va permettre de n'afficher que les objets sélectionnés dans l'application. Fonctionnellement parlant ce n'est qu'une relation de base de données.
|
||||
|
||||
Le second type de filtre, plus complexe, est le filtre dynamique. Les filtres dynamiques permettent de gérer automatiquement les entités qui seront incluses ou exclues de l'affichage. Pour ce type de filtre, il est possible de créer des règles de filtrage avancées pour permettre à l'utilisateur plus de flexibilité.\
|
||||
Un peu à la manière d'une requête SQL, il est possible de construire une requête qui va être exécutée pour permettre de retrouver les entités à partir de critères. Il est par exemple possible de demander de filtrer les ouvrages par position géographique en ne prenant en compte que ceux au-dessus d'une certaine latitude et de rajouter à ce filtre uniquement les ouvrages qui contiennent un certain numéro dans leur nom.\
|
||||
Il est possible de créer des règles avec chaque propriété d'un objet d'infrastructure, d'appliquer un ordre pour les conditions, de faire des agrégats, des jointures... Les utilisateurs ont la liberté de créer leur propre requête, une requête pouvant devenir rapidement complexe, elle peut donc prendre plus de temps à filtrer les objets d'infrastructures pour les retourner à l'utilisateur.\
|
||||
Un peu à la manière d'une requête SQL, l'utilisateur peut construire une requête qui va être exécutée pour permettre de retrouver les entités à partir de critères. La requête offre la possibilité de filtrer les ouvrages par position géographique en ne prenant en compte que ceux au-dessus d'une certaine latitude et de rajouter à ce filtre uniquement les ouvrages qui contiennent un certain numéro dans leur nom.\
|
||||
Les règles peuvent être construites en utilisant chaque propriété d'un objet d'infrastructure, d'appliquer un ordre pour les conditions, de faire des agrégats, des jointures... Les utilisateurs ont la liberté de créer leur propre requête, une requête pouvant devenir rapidement complexe, elle peut donc prendre plus de temps à filtrer les objets d'infrastructures pour les retourner à l'utilisateur.\
|
||||
Étant utilisé par les services #ref-glossary(term: "GIS")[GIS] de l'application, s'assurer de la performance de ce système est primordial.
|
||||
|
||||
Ce que l'outil permet de tester est ce système de groupe/filtres. Il va chercher les différents filtres existants en base de données, peu importe le client qui a pu les créer, et les exécuter.\
|
||||
Cette méthode permet de connaître les performances réelles de la base dans un cas pratique spécifique à l'application et non pas d'avoir des performances théoriques fournies par les développeurs du #ref-glossary(term: "SGBDR")[SGBDR] qui peuvent être tournées en leur faveur. Nous cherchons donc à savoir si le chiffre de dix pourcents en gain de performances est réel ou non.
|
||||
|
||||
L'objectif est donc de comparer les performances de la base de production encore sous #ref-glossary(term: "PostgreSQL")[PostgreSQL] 14, avec les performances d'une base de développement installée pour l'occasion, elle, sous #ref-glossary(term: "PostgreSQL")[PostgreSQL] 16. Après avoir exécuté l'outil de benchmark sur les deux bases, je récupère les données brutes en sortie de programme pour les analyser. Ci-dessous un exemple de données de sorties fournies par le programme après exécution.
|
||||
L'objectif est donc de comparer les performances de la base de production encore sous #ref-glossary(term: "PostgreSQL")[PostgreSQL] 12, avec les performances d'une base de développement installée pour l'occasion, elle, sous #ref-glossary(term: "PostgreSQL")[PostgreSQL] 16. Après avoir exécuté l'outil de benchmark sur les deux bases, je récupère les données brutes en sortie de programme pour les analyser. Ci-dessous un exemple de données de sorties fournies par le programme après exécution.
|
||||
|
||||
#text(
|
||||
```csv
|
||||
eruid,description
|
||||
batman,uses technology
|
||||
superman,flies through the air
|
||||
spiderman,uses a web
|
||||
ghostrider, rides a motorcycle
|
||||
#GROUP_OBJECT_PROFILE#accessgroupGroupProfile
|
||||
cn,description
|
||||
daredevil,this group represents daredevils
|
||||
superhero,this group represents superheroes
|
||||
#GROUP_OBJECT_PROFILE#aixaccessgroupGroupProfile
|
||||
aixgroupadminlist,ibm-aixprojectnamelist
|
||||
eadmins,eadmingroup
|
||||
eguests,eguestgroup
|
||||
```
|
||||
Group_Id;Mandant;Group_Name;Count_Ios;Load_Duration_In_Ms;Load_Per_Io_In_Ms
|
||||
0000-00000-0000;CANTON_AG;1 Erhaltungsplanung Gesamt;995;946;0,950753769
|
||||
0000-00000-0000;CANTON_AG;2 Arbeitsplanung BT;184;159;0,864130435
|
||||
0000-00000-0000;CANTON_AG;3 Arbeitsplanung EM-KB;4739;139;0,029331083
|
||||
0000-00000-0000;CANTON_AG;4 Inspektionsplanung EM-KB;4739;113;0,023844693
|
||||
0000-00000-0000;CANTON_AG;5 Zustandsklassen;4739;115;0,024266723
|
||||
0000-00000-0000;CANTON_AG;6 Kontroll-Auswertungen;4739;116;0,024477738
|
||||
0000-00000-0000;CANTON_AG;ASTRA Kreuzungsobjekte;79;219;2,772151899
|
||||
0000-00000-0000;CANTON_AG;Bauwerke ohne Code und in Betrieb;0;166;166
|
||||
0000-00000-0000;CANTON_AG;Bauwerke ohne Eigentümer und in Betrieb;0;171;171
|
||||
0000-00000-0000;CANTON_AG;Bauwerke ohne Gemeinde und in Betrieb;0;148;148
|
||||
0000-00000-0000;CANTON_AG;Bauwerke ohne Status;35;225;6,428571429
|
||||
```)
|
||||
|
||||
Les données sont au format CSV, je peux ainsi les importer dans un logiciel tableur tel qu'Excel pour les manipuler et les comparer. L'application de production étant accessibles aux clients de manière continue, les données stockées peuvent changer très rapidement et présenter un delta avec les données sauvegardées à posteriori lors la mise en place de la base de développement.\
|
||||
Cette différence doit être prise en compte dans la comparaison des données puisque je dois alors utiliser des fonctions plus poussées d'Excel pour retrouver les données similaires entre les deux tables et en comparer les résultats.\
|
||||
|
||||
J'obtiens dans les données les informations d'identification des groupes testés, le client à qui ils appartiennent, le nombre d'ouvrages que les groupes contiennent après filtrage, le temps total d'exécution du groupe et le temps moyen calculée pour le chargement d'un objet d'infrastructure. L'unité de temps est donnée en millisecondes.
|
||||
|
||||
Pour comparer les performances de la base, je commence par récupérer les données globales des deux bases, à savoir le nombre total d'objets d'infrastructures qui ont étés traités et le temps global d'exécution de traitement. Pour connaître le temps total qu'a mis la base pour traiter tous les groupes, j'utilise la requête ``` =SUM(pg14[Load_Duration_In_Ms])``` qui fait une simple somme de tous les résultats de la colonne ``` Load_Duration_In_Ms```. Je fais la même chose pour les résultats des deux bases et pour la colonne ``` Count_Ios``` que je réutilise avec un simple calcul de différence dans la requête ``` =Total_Ios_Count_14 - Total_Ios_Count_16```. Comme le présente le tableau des résultats @result_sheet_benchmark_1, les données dans la base de production ont déjà changées, il faut donc que je tienne compte dans mes résultats.
|
||||
Pour comparer les performances de la base, je commence par récupérer les données globales des deux bases, à savoir le nombre total d'objets d'infrastructures qui ont étés traités et le temps global d'exécution de traitement. Pour connaître le temps total qu'a mis la base pour traiter tous les groupes, j'utilise la requête ``` =SUM(pg12[Load_Duration_In_Ms])``` qui fait une simple somme de tous les résultats de la colonne ``` Load_Duration_In_Ms```. Je fais la même chose pour les résultats des deux bases et pour la colonne ``` Count_Ios``` que je réutilise avec un simple calcul de différence dans la requête ``` =Total_Ios_Count_12 - Total_Ios_Count_16```. Comme le présente le tableau des résultats @result_sheet_benchmark_1, les données dans la base de production ont déjà changées, il faut donc que je tienne compte dans mes résultats.
|
||||
|
||||
#figure(
|
||||
caption: "Comparatif brut des performances entre les deux bases",
|
||||
table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: horizon,
|
||||
table.header([], [*Postgres_14*], [*Postgres_16*], [*Gap_From_14_To_16*]),
|
||||
table.header([], [*Postgres_12*], [*Postgres_16*], [*Gap_From_12_To_16*]),
|
||||
[*Total_Io_Count*], [323527], [318634], [-4893],
|
||||
[*Total_Duration*], [3577961], [3450208], [-127753],
|
||||
[*Identical_Ios_Duration*], [3499476], [3438261], [-61215],
|
||||
@ -179,18 +179,18 @@ Pour comparer les performances de la base, je commence par récupérer les donn
|
||||
)<result_sheet_benchmark_1>
|
||||
|
||||
Structure du tableau de résultats:
|
||||
- La colonne *``` Gap_From_14_To_16```* contient les résultats des comparaisons des données obtenues entre Postgres 14 et Postgres 16.
|
||||
- La colonne *``` Gap_From_12_To_16```* contient les résultats des comparaisons des données obtenues entre Postgres 12 et Postgres 16.
|
||||
- La ligne *``` Total_Io_Count```* indique le nombre total d'objets d'infrastructures qui ont été filtrés par les différents groupes traités.
|
||||
- La ligne *``` Total_Duration```* indique le temps total de traitement (en millisecondes) de tous les groupes.
|
||||
- La ligne *``` Identical_Ios_Duration```* indique le temps de traitement total (en millisecondes) uniquement pour les #ref-glossary(term: "OIs")[OIs] identiques entre les deux bases.
|
||||
- La ligne *``` Average_Ios_Load_Duration```* indique le temps de traitement moyen écoulé (en millisecondes) par objet d'infrastructure.
|
||||
|
||||
Dans les réultats obtenus, je remarque rapidement que le temps de traitement entre les deux bases n'est pas drastiquement différent. Pour le temps de traitement global des objets d'infrastructure identiques entre les deux bases, on ne gagne que 0.23 milliseconde après la migration. Pour filtrer mes résultats, j'utilise la méthode ``` =SUM(SUMIF(pg14[Group_Id]; VLOOKUP(pg14[Group_Id]; pg16[Group_Id]; 1;FALSE); pg14[Load_Duration_In_Ms]))``` qui va exclusivement récupérer les lignes pour lesquelles les groupes analysés sont présents dans les deux bases, puis faire la somme des résultats de performances.
|
||||
Dans les réultats obtenus, je remarque rapidement que le temps de traitement entre les deux bases n'est pas drastiquement différent. Pour le temps de traitement global des objets d'infrastructure identiques entre les deux bases, on ne gagne que 0.23 milliseconde après la migration. Pour filtrer mes résultats, j'utilise la méthode ``` =SUM(SUMIF(pg12[Group_Id]; VLOOKUP(pg12[Group_Id]; pg16[Group_Id]; 1;FALSE); pg12[Load_Duration_In_Ms]))``` qui va exclusivement récupérer les lignes pour lesquelles les groupes analysés sont présents dans les deux bases, puis faire la somme des résultats de performances.
|
||||
|
||||
Pour terminer mon analyse, je transforme les résultats en pourcentages dans le tableau @perf_gain_sheet_1. Avec ça je peux comparer les dix pourcents de performances annoncées avec les résultats réels obtenus.
|
||||
|
||||
#figure(
|
||||
caption: "Résultat des gains de performances entre PGSQL 14 et 16",
|
||||
caption: "Résultat des gains de performances entre PGSQL 12 et 16",
|
||||
table(
|
||||
columns: (auto, auto),
|
||||
align: horizon,
|
||||
@ -253,14 +253,14 @@ C'est en me rappelant cela que j'ai réalisé que les tests ont été réalisés
|
||||
|
||||
La mise en production étant un environnement sensible et n'ayant pas les compétences d'administrateur système nécessaires, je n'ai pas pu participer à la mise en place de la mise en production des changements. J'ai cependant pu vérifier que tout fonctionnait comme attendu en inspectant l'environnement de production.
|
||||
|
||||
Une fois le serveur de production mis à jour avec les nouveaux éléments, j'effectue un nouveau test de performance pour valider que le biais de différence de performance entre les environnements est bien la source du problème. Je conserve les données obtenues précédemment pour la base #ref-glossary(term: "PostgreSQL")[PostgreSQL] 14 et je récupère le résultat de l'outil de benchmark une fois exécuté sur la nouvelle base et sur le même environnement pour une comparaison correcte.
|
||||
Une fois le serveur de production mis à jour avec les nouveaux éléments, j'effectue un nouveau test de performance pour valider que le biais de différence de performance entre les environnements est bien la source du problème. Je conserve les données obtenues précédemment pour la base #ref-glossary(term: "PostgreSQL")[PostgreSQL] 12 et je récupère le résultat de l'outil de benchmark une fois exécuté sur la nouvelle base et sur le même environnement pour une comparaison correcte.
|
||||
|
||||
#figure(
|
||||
caption: "Nouveau comparatif brut des performances entre les deux bases",
|
||||
table(
|
||||
columns: (auto, auto, auto, auto),
|
||||
align: horizon,
|
||||
table.header([], [*Postgres_14*], [*Postgres_16*], [*Gap_From_14_To_16*]),
|
||||
table.header([], [*Postgres_12*], [*Postgres_16*], [*Gap_From_12_To_16*]),
|
||||
[*Total_Io_Count*], [323527], [346761], [23234],
|
||||
[*Total_Duration*], [3577961], [4025135], [-447174],
|
||||
[*Identical_Ios_Duration*], [3577257], [3980590], [403333],
|
||||
@ -271,7 +271,7 @@ Une fois le serveur de production mis à jour avec les nouveaux éléments, j'ef
|
||||
Dans le tableau @result_sheet_benchmark_2 les résultats bruts ne donnent pas forcément de gros indices sur les différences par rapport à la première analyse comportant potentiellement un biais. Je constate une inversion sur la quantité de données traitées, cette fois-ci la nouvelle base de données à eu plus d'#ref-glossary(term: "OIs")[OIs] à traiter et par conséquent les temps de traitements ont aussi augmenté. Une comparaison avancée me permet d'obtenir un comparatif plus explicite entre les deux bases.
|
||||
|
||||
#figure(
|
||||
caption: "Résultat des gains réels de performances entre PGSQL 14 et 16",
|
||||
caption: "Résultat des gains réels de performances entre PGSQL 12 et 16",
|
||||
table(
|
||||
columns: (auto, auto),
|
||||
align: horizon,
|
||||
|
||||
2
main.typ
2
main.typ
@ -74,7 +74,7 @@ L'histoire avec Julien continue donc chez Unit Solutions AG à partir d'octobre
|
||||
#set align(right)
|
||||
*M. Cédric Martin*, chef de projet de la suite logicielle « InfSuite »
|
||||
],
|
||||
abstract: [Ce document présente ma seconde et dernière année en tant qu'étudiant en master au sein de l'entreprise Unit Solutions. Il met en évidence ma participation à l'une des tâches à fort intérêt pour l'entreprise sur le sujet d'une migration de base de données au cours des neuf mois de mon immersion professionnelle. Ce rapport détaille les connaissances et les compétences, personnelles et professionnelles, acquise durant cette période. Il aborde les divers défis auxquels j'ai été confronté, ainsi que les différentes analyses et solutions que j'ai apportées pour les résoudre.],
|
||||
abstract: [Ce document présente ma seconde et dernière année en tant qu'étudiant en master au sein de l'entreprise Unit Solutions. Il met en évidence ma participation à l'une des tâches à fort intérêt pour l'entreprise sur le sujet d'une migration de base de données. Résultat d'une période de neuf mois d'immersion professionnelle, ce rapport détaille les connaissances et les compétences, personnelles et professionnelles, acquise durant cette période. Il aborde les divers défis auxquels j'ai été confronté, ainsi que les différentes analyses et solutions que j'ai apportées pour les résoudre.],
|
||||
keywords: (
|
||||
"Migration",
|
||||
"Base de données",
|
||||
|
||||
14
template.typ
14
template.typ
@ -1,4 +1,5 @@
|
||||
#import "@preview/acrostiche:0.2.0": *
|
||||
#import "@preview/colorful-boxes:1.3.1": *
|
||||
|
||||
#let section = state("section", none)
|
||||
#let glossary-terms = state("glossary", ( : ))
|
||||
@ -138,6 +139,17 @@
|
||||
|
||||
// Summary.
|
||||
outline(title: "Sommaire", depth: 2, indent: auto)
|
||||
[
|
||||
#colorbox(
|
||||
title: "Information",
|
||||
color: "blue",
|
||||
radius: 10pt,
|
||||
width: auto
|
||||
)[
|
||||
Ce document contient des termes techniques indiqués par le style suivant: #text("exemple", style: "italic", weight: "bold").
|
||||
Les définitions de ces termes techniques se trouvent dans la section *Glossaire* de ce document. En version numérique, un clic sur un terme renvoie directement à sa définition dans le *Glossaire*.
|
||||
]
|
||||
]
|
||||
pagebreak()
|
||||
|
||||
{
|
||||
@ -233,4 +245,4 @@
|
||||
]
|
||||
}
|
||||
|
||||
#let ref-glossary(term: "", body) = locate(loc => link(glossary-terms.final(loc).at(term), body))
|
||||
#let ref-glossary(term: "", body) = locate(loc => link(glossary-terms.final(loc).at(term), text(body, style: "italic", weight: "bold")))
|
||||
Loading…
Reference in New Issue
Block a user