Discussion :

[petitours]

Bonjour

Je travaille sur un système où des cartes électronique doivent rapatrier sur un serveur distant via ethernet ou internet des données issues de différents capteurs. Aujourd'hui ces données sont transférées toutes les heures ou tous les jours par FTP et exploitées lot par lot à réception avec un soft d'analyse de ma fabrication fait à l'origine pour traiter des fichiers du même type à l'issu de campagnes de mesure ponctuelles, sans transfert distant et sans cette notion de petit bout ajoutés petits à petit.

Les fichiers binaires utilisés correspondent à un capteur avec une date (double) puis une valeur (double) puis une date, puis une valeur...
Le soft me permet de visualiser, zoomer dans tous les sens et faire différentes analyses à fond la caisse (quelques fractions de seconde de traitement pour zoomer sur 25 millions de points de mesure et ce sans limite de taille de fichier à priori)
mais pour un flux de données accumulé sur longtemps avec un apport de données périodique il me manque la gestion de la liaison entre les fichiers et je crains que cela soit un vrai casse tête à gérer, je n'ai pas encore trouvé de bonne manière pour faire sur le papier.

C'est là que je me dis base de donnée peut être ???

Là la plus grosse question, totalement bloquante avec ce que je connais des bases de données : Comment mes cartes électroniques peuvent avoir accès à la base de donnée (ethernet et/ou internet) pour la remplir en toute sécurité ?
Les seuls systèmes que je connais de ce type disposent d'un serveur qui interroge les cartes électroniques ( de simples passerelles) or là il me faut absolument 3 choses :
1) Les cartes enregistrent en local et stockent sur serveur quand le réseau le permet. Le réseau n'est pas critique et pas de trou dans les données en cas de coupure réseau.
2) les données ne restent pas sur les cartes électroniques. La lecture dessus serait trop lente et leur capacité insuffisante.
3) Pas de serveur qui tourne pour faire vivre la collecte de donnée (le point 1 enlèverait de toute manière pas mal d’intérêt à la chose)

Merci de m'avoir lu jusqu'au bout et merci p pour vos idées sur la question

Une solution pour utiliser une base donnée quand même ?
Un avis sur le système de fichiers binaires actuel ?

Je pose la question dans C# par ce que je code avec et parce que ma question n'a à mes yeux pas sa place dans la rubrique "accès aux données" qui traite de bdd.

[ivery07]

Le soft d'analyse est écrit en quel langage ?

[petitours]

Bonjour

Le soft est actuellement en C#

[theMonz31]

petitsours, si je comprends bien les données sont envoyées par FTP sur un serveur.

Donc, j'imagine que tu peux très bien avoir un bout de soft qui scrute le répertoire FTP et qui, à partir de là, va pouvoir remplir ta base de données.

Comme ça, tu gardes ton système via FTP... et c'est simplement coté "serveur" que tu mets en place un traitement.

Après, ça dépend pourquoi tu veux utiliser une base de données...(ça, je ne l'ai pas bien compris)

Si tu veux juste faire une "association" fichier, heure... autant utiliser un fichier type XML pour faire une telle association.

L'intérêt d'une base de données est ailleurs...
Peut-être que de la base NoSQL peut aussi t'apporter une réponse... (à voir, dans certains cas comme un "gros" dictionnaire

[petitours]

Bonjour et merci pour la réponse

Je ne veux pas particulièrement utiliser une base de donnée. Pour dire vrai ça me fait même un peu peur pour 2 raisons
1) la perf : vais je réussir à être aussi rapide en lecture avec une base de données
2) le fait d'avoir à déployer (et maintenir) un serveur de bdd chez le client

Aujourd'hui je ne connais les bases de données qu'à travers Access que j'ai beaucoup utilisé par le passé et qui m'offre encore aujourd’hui quelques outils persos
Je vois donc très mal ce que peut m'apporter une base de donnée, sauf le fait d'avoir une seule et unique source de donnée à lire avec l'outil d'analyse.

Là je vois :
-soit laisser les fichiers journaliers sur le serveur et adapter le soft pour qu'il sache lire et mettre bout à bout les fichiers (éventuellement en gérant trous et redondances dans les données)
-soit que le soft mouline et recompile tous les fichiers en 1 seul (ça simplifierait la lecture ensuite mais je crains pour la fiabilité du truc à terme)
-soit que le soft mouline et charge une bdd comme vous venez de l'évoquer.

Si vous ne comprenez pas bien pourquoi je parle de bdd c'est peut être qu'il n'y a pas d’intérêt ! Vous en pensez quoi des avantages de ces 3 options ?

Il y a peut être une 4eme solution avec votre histoire du fichier XML, mais je n'ai pas compris l'idée qui se cache derrière.

Merci

[DotNetMatt]

Si vous ne comprenez pas bien pourquoi je parle de bdd c'est peut être qu'il n'y a pas d’intérêt !

Le SGBDR est fait pour analyser des données relationnelles (ayant un ou plusieurs liens entre elles). On peut aussi étendre ce postulat pour faire de la pure analyse de données, en mode entrepôt de données (datawarehouse). Personne ne sait faire cela mieux que lui, donc l'avantage principal c'est que tu vas potentiellement avoir un gain de performances notable.

En gros, si tu prends tes fichiers et que tu les intègres dans une base de données, le gain de performances sera notoire comparé à une solution où tu prends tes fichiers un par un, les charge en mémoire, reconstruit les liaisons puis réalise des opérations dessus...

Après, il faut prendre des pincettes : ca dépend de quel volume de données on parle. Si tu es sur de faibles volumes, je pense que tu peux te contenter de lire tes fichiers en mémoire. Par contre si on parle de volumes conséquents, ca peut valoir le coup de mettre une base de données.

Autre avantage de la base de données, pas besoin de reconstruire les liaisons tout le temps.

[theMonz31]

après, ça peut être "interessant" de fusionner tes fichiers pour travailler sur une journée et donc avoir un fichier par journée (si celà à un sens)...

Après, si tu as des "millions" de données, tu peux les mettre dans une base de données mais bon, le traitement sera relativement lourd et si, de plus, tu veux éviter
l'installation d'un serveur de bdd chez le client, autant partir sur une solution de fusion des données...

Et rien ne t'empêche d'avoir un fichier xml ou text (si tu veux) qui contiendrait un couple genre :

21/01/2016; Nom de ton fichier pour ce jour là,
22/01/2016; Nom de ton fichier pour ce jour là,
etc...

[petitours]

Merci pour les éléments

Je comprends vite mais il faut m'expliquer doucement !
là dedans je ne comprends pas ien

Le SGBDR est fait pour analyser des données relationnelles (ayant un ou plusieurs liens entre elles). On peut aussi étendre ce postulat pour faire de la pure analyse de données, en mode entrepôt de données (datawarehouse). Personne ne sait faire cela mieux que lui, donc l'avantage principal c'est que tu vas potentiellement avoir un gain de performances notable.

D'un coté je lis données relationnelles

(ayant un ou plusieurs liens entre elles)

or dans mon cas je n'ai pas de relation à priori puisque le but est justement de collecter des données qui seront analysées et confrontées à des modèles qui progresseront de jour en jour. Je n'ai pas de relation à priori entre mes fichiers de données, je sais juste que ce que je mesure et où ca se trouve, par exemple dans l'arborescence d'un réseau (je mesure un débit en tête puis dans la sous branche 2 puis à un autre endroit sous la branche 2...)

De l'autre coté je lis

pure analyse de données, en mode entrepôt de données (datawarehouse). Personne ne sait faire cela mieux que lui

et là je retrouve le sourire on me parle d'analyse et c'est ça que je veux faire ! :-P

J'ai du mal à percevoir cet contrainte/apport entre le relationnel et l'analyse de donnée.

La base de donnée je la connais pour ses liaisons entre un ensemble et un autre, l'entreprise qui peut être associée à plusieurs salariés sans avoir à définir plusieurs fois l’entreprise...

Pour décrire un peu mieux ce que j'ai comme donnée, un exemple simple
Je vais mesure des températures à différents points, des nombres de pièces qui passent au même endroit où à d'autres endroits.
Et je vais rechercher des corrélations entre tous ces paramètre grâce à des outils statistiques, corrélations que je suis incapable de prédire entre telle ou telle variable à priori.
On pourrait imaginer qu'à terme des modèles soient trouvés et qu'une structure dans les données soit établie mais au départ, et pour plusieurs années, les données sont explorées sans à priori.

[petitours]

après, ça peut être "interessant" de fusionner tes fichiers pour travailler sur une journée et donc avoir un fichier par journée (si celà à un sens)...

Après, si tu as des "millions" de données, tu peux les mettre dans une base de données mais bon, le traitement sera relativement lourd et si, de plus, tu veux éviter
l'installation d'un serveur de bdd chez le client, autant partir sur une solution de fusion des données...

Et rien ne t'empêche d'avoir un fichier xml ou text (si tu veux) qui contiendrait un couple genre :

21/01/2016; Nom de ton fichier pour ce jour là,
22/01/2016; Nom de ton fichier pour ce jour là,
etc...

Il y aura surement plus gros mais un dossier "classique" va avoir 30 points enregistrés toutes les 30s en moyenne soit (avec 16o par point dans mes fichiers binaires)
-31 million de points par an
-481Mo de fichiers
-10950 fichiers (1 par jour et par point)
Les années suivante on peut imaginer une baisse des périodicité (disons 2 ou 3 x moins de points mais toujours autant de fichiers)

aujourd'hui ça tourne sur 2 "protos" et les fichiers utilisés ont un nom comme ca
2016-01-25-NomDuPoint.data
La carte électronique crée un fichier par jour et le stocke sur le serveur une fois le fichier du lendemain commencé.
Ce que vous décrivez pour un fichier XML me semble être de fait défini par la structure des fichiers et leur noms.

[DotNetMatt]

De l'autre coté je lis et là je retrouve le sourire on me parle d'analyse et c'est ça que je veux faire ! :-P

J'ai du mal à percevoir cet contrainte/apport entre le relationnel et l'analyse de donnée.

La base de donnée je la connais pour ses liaisons entre un ensemble et un autre, l'entreprise qui peut être associée à plusieurs salariés sans avoir à définir plusieurs fois l’entreprise...

On va faire simple, quand tu modélises tes salariés, tu crées une base de données normalisée (je te renvoie aux Formes Normales). Cela a pour but d'éviter les redondances dans les données, d'améliorer les performances, etc.

Quand on crée un data warehouse, la normalisation reste importante, mais elle passe au second plan. On modélise alors un/des schémas en forme d'étoile ou de flocon. Ces formes induisent une certaine dénormalisation, car avec un data warehouse, l'objectif n'est pas réellement les performances, mais de pouvoir aggréger les données comme on le souhaite, même si c'est au prix de données redondantes.

Pour revenir à des concepts basiques en IT, quand on fait de la normalisation, généralement on travaille pour du transactionnel (OLTP). Il faut que les performances soient au top, c'est vital par exemple pour une application Web, ou encore pour une application de trading.
Quand on modélise en étoile/flocon, on travaille pour de l'analytique (OLAP). Les performances passent alors au second plan, car l'objectif est de fournir du reporting, des analyses de données. Il y a des techniques qui permettent de pré-générer des rapports pour qu'ils s'affichent instantanément à l'utilisateur, même si derrière il y a plusieurs heures/jours de calculs.

Dans ton cas, tu cherches à faire des analyses de données, donc tu peux très bien partir sur un data warehouse. Au-dessus de cette base de données, tu peux (ou non, ce n'est pas obligatoire) créer un cube OLAP dans lequel tu vas pouvoir gérer tes calculs et préparer les données pour qu'elles puissent être affichées correctement dans un rapport. Le cube permet d'effectuer des calculs avancés, du drilldown, du filtrage, etc. bref c'est assez puissant. Si tes calculs restent relativement simplistes, tu peux te passer du cube et créer de "simples" requêtes SQL qui se chargeront de préparer les données.

L'intérêt de la base de données, c'est aussi que tu vas pouvoir conserver l'historique sur plusieurs années, et potentiellement comparer d'une année à l'autre, etc. (à voir si c'est pertinent ou pas dans ton cas).

[petitours]

Je découvre une notion, il va me falloir quelques jour pour digérer l'info...
Dans ce cas je vais partir de fichiers plats comme j'ai aujourd’hui et je vais avoir un "truc" qui va standardiser les data collectée pour les rentrer dans l’entrepôt.

Faut que je comprenne à quoi ressemble physiquement l’entrepôt et comment on gère le cube, ça à l'air intéressant et il existe peut être des outils informatiques d'analyse qui pourraient me servir, compatible avec ce genre de chose.

Dans mon projet j'aurais à intégrer des données déjà pressentent dans l’entreprise (des quantité produites , des données de planning) si je comprends bien ces entrepôts de données normalisent le comment on introduit ces données.
Je ne suis pas sorti du sable !

Merci

[DotNetMatt]

Oui il faut que tu étudies la chose avant de te lancer, car si ca se trouve c'est comme sortir un bazooka pour tuer une mouche

Tu peux commencer par ici : Conception d'un entrepôt de données (Data Warehouse). Dans ton cas un "Fait" (aussi appelé "Mesure" ou "Fact" en Anglais) on peut imaginer que ca soit une mesure faite par un capteur. Autour de ce Fact, tu auras donc des dimensions comme par exemple la date, le capteur, etc.

Ensuite il te suffira de charger toutes tes données dans la table de Fait, en ayant bien sûr chargé les dimensions au préalable. En théorie le chargement se fait via un ETL (Extract, Transform, Load) comme par exemple SQL Server Integration Services (SSIS), mais c'est en théorie, si tu veux vraiment industrialiser le bousin. Tu peux aussi très bien avoir un simple programme C# qui s'occupe de ca.

Pour ce qui est du cube, tu peux regarder par exemple SQL Server Analysis Services (SSAS) qui est fourni avec SQL Server.

Voilà après encore une fois, à toi de voir si c'est intéressant et jusqu'à quel point...