Depuis des décennies maintenant, le stockage était réservé principalement aux bases de données (ou SGBDR) permettant de tirer des informations « relationnelles » avec des capacités « statistiques » complexes, c’est un outil très pratique.
Alors pourquoi ajouter un système de stockage à ces bases de données qui ont fait leurs preuves, l’informatique étant friande de nouvelles technologies pour des raisons de modes alors ?
En fait, l’information « relationnelle » à un coût important dans la manière de gérer une simple donnée, il faut l’indexer, gérer ses contraintes d’unicité, etc. Ce qui pose de sérieuses pertes de performances de lecture dès que celles-ci ont atteint des volumes relativement modestes à partir de 50 à 100 Go et bien plus encore.
Dans l’informatique technique, il n’est pas rare d’enregistrer de façon plus ou moins normale à une fréquence rapide d’une seconde pour le suivi particulier d’une machine ou d’un équipement en cours de démarrage (pic de consommation ou de tension par exemple). Ce qui produit d’énormes quantités de données en quelques mois / années. Cela même si un bon produit logiciel doit proposer de façon native des règles de stockage fortement optimisées (bande morte, statistique Min/Max, calcul d’intégral à la volée) permettant d’éviter des enregistrements inutiles ou évitables.
Alors, certaines sociétés connues d’internet comme Google, Yahoo, etc. ont eu à gérer de très gros volumes de données non structurées. Impossible de faire attendre un internaute quelques secondes de plus !
Les bases de données relationnelles (SQL server, Oracle, MySQL, Firebird, etc.) ont toutes montré leurs limites à ce niveau.
Il fallait être moins relationnel, et être plus rapide, plus compressé et surtout resté être stable quel que soit le volume à absorber, donc inventer un nouveau système pour être très performant !
Cette problématique s’est retrouvé dans l’informatique « technique » qui avait dans des objectifs similaires liés aux installations de plus en plus grosses et ayant plus en plus de capteurs. Aujourd’hui, cette problématique est plus réelle que jamais, les fameux IOT (l’internet des objets comme LORA) commencent à être déployés en masse, produisant beaucoup d’historique.
La méthode d’archivage NOSQL (Not Only SQL) a été créée pour répondre à toutes ces questions : rapidité d’écriture, de lecture, standard de format et compression maximum.
Il n’y a pas de réponse toute faite, c’est surtout l’usage et les moyens qui vont déterminer le bon choix.
Il existe des solutions technologiques commerciales ou open source, on peut citer quelques noms dans ce domaine NOSQL : Cassandra, MongoDB, HBase , … pour la partie stockage pure (ou système de fichier si vous préférez) avec des principes (clé=valeur, document indexé, graphe) différents suivant les modèles.
La philosophie étant différente de la BDD relationnelle, ceci implique une remise en question complète du modèle (ou schéma) d’organisation des données. Vouloir remplacer entièrement des applications métiers existantes par cette nouvelle technologie, n’est pas à mon avis envisageable.
Il est préférable de faire cohabiter les deux solutions afin de tirer le meilleur de chacune.
Nous avons choisi le mode document indexé pour une bonne cohabitation et résoudre un certain nombre de contraintes liées aux archivages longue durée (voir ci-dessous le chapitre archive).
Pour ce qui est de la partie exploitation des données « les usages », a ce niveau tout est possible en fonction des besoins de l’entreprise au travers d’applications métiers (ou spécifiques) qui existent ou qui restent à inventer.
Dans notre cas, nous avons une activité de stockage de données techniques et énergétiques, les usages sont en parti déjà connus, ils découlent naturellement dans notre métier en fournissant de façon transparente aux utilisateurs des gains de performance (>10 fois en vitesse et compression) sur certaines données brutes. En d’autres termes le BIGDATA est transparent pour les utilisateurs depuis nos outils d’analyse pour certaines tâches, d’autres restant dans le domaine classique de la base de données relationnelle quand il s’agit d’agrégations, de synthèse en matrice, de calculs spéciaux et de gestion temporelle poussée. Il permet de futures opportunités d’échanges ou traitements spéciaux.
Nous pouvons répondre de façon simple, sans langage technologique complexe que le fait d’avoir une certaine profondeur dans les données (au sens échantillonnage rapide et ou en durée d’historique) permet de mieux comparer des situations plus nombreuses afin d’effectuer des calculs sur du plus long terme plus rapidement. Citant ainsi le vieil adage « si l’on mesure mieux, on analyse mieux (et on décide mieux) ».
De là, vous pouvez prendre plus facilement des décisions sur des investissements ou effectuer des actions de réglages si les données parlent mieux, l’efficacité sera grandement améliorée, encore faut-il avoir un bon produit logiciel, sans être obligé de lancer des développements spéciaux complémentaires.
La phase d’intégration concerne bien entendu l’installation du logiciel choisi et de son interfaçage avec les autres équipements de l’entreprise (les producteurs de données).
Dans le cas qui nous intéresse, c’est la bonne nouvelle puisque les installations techniques ont déjà des capteurs, rien ne change dans l’infrastructure, aucun investissement n’est à prévoir. C’est seulement au niveau du système central que les choses peuvent changer ou évoluer (taille des disques, puissance CPU ou RAM).
Dans notre cas, la mise en place d’un système de BIGDATA est réalisable en 2h chrono sur un projet existant MIV (constaté en projets réels), il faut simplement prévoir des manipulations si les historiques DB doivent être réintégrées dans le nouveau système BIGDATA et dans ce cas quelques heures suffiront pour lancer un process automatique qui pourra ensuite durer pour convertir les anciennes données vers le nouveau format.
Du côté exploitation, c’est à l’application métier de proposer l’utilisation des données. Dans notre cas, « l’exploitation » est native et disponible en quelques minutes. L’interface peut évoluer en fonction du profil pour exploiter et tirer les bénéfices du BIGDATA. Les gens de métiers (technicien de maintenance, Energy manager, bureau d’audit, Intégrateur, etc.) auront la possibilité de prendre de nouvelles décisions.
Le fait de produire de la donnée, de l’écrire sur un support est une forme d’archivage, ce qui est conceptuellement vrai.
D’autres questions sous-jacentes doivent pourtant être posées quand on parle d’archivage longue durée.
Comment un produit qui stocke en BIGDATA dans un format propriétaire pourra me servir dans 5,10,15 ans ? sur quel serveur ? avec quel OS ?
Si je suis en mode SAAS, comment je récupère mes données si je change de prestataire ? dans quel format ?
Est-ce que je peux transporter partiellement mes archives afin de faciliter les échanges avec une entreprise externe (calculs spéciaux à faire par un BE spécialisé, simulateur, courbe pour un fabricant de moteur, etc.) alors qu’il ne possède pas mon infrastructure ?
A ces questions légitimes, nous avons orienté le choix vers un modèle « NOSql document indexé » donc transportable et sécable, auquel nous avons ajouté une couche de compatibilité dans un format qui peut être lu avec des outils standards sans notre système (local ou cloud) offrant la garantie à très long terme que les archivages seront exploitables, même sans plus d’intervention de notre part.
Le système BIGDATA apporte à un produit métier de nouvelles performances (volume, vitesse), ce n’est pas une révolution, c’est à voir comme une extension des modèles existants qui ont fait leur preuve.
Le coût dépend du secteur d’activité et des fonctionnalités attendues.
Cette technologie ne remplace pas les bases de données classiques, nous croyons plus à une cohabitation intelligente en fonction et besoins.
Là où MIV est intéressant dans sa démarche, c’est de proposer cette dernière technologie sans pour autant être informaticien chevronné, c’est même totalement transparent avec une mise en exploitation en quelques minutes. Les usages peuvent associer des mesures de process (pression, froid, température, air comprimé), et suivre également la consommation énergétique (de bâtiment, machines, lignes, par produit, etc.) disposant des interfaces dans le même produit.
©MIV SOFT 2024 Tous droits réservés