Discussion :

[mouna1984]

Bonjour,
J ai une application qui mesure des valeurs chaque milliseconde et les enregistre. J ai besoin de temps en temps de contrôler les mesures des 10 dernières minutes donc j ai besoin de mettre a jour les données chaque milliseconde.
La structure de chaque ligne est la suivante

2024-05-07 08:02:44.253;False;True;False;12;37.6;7;START;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0

En total j ai 600000 lignes en total.
Je cherche une solution optimale en temps d execution et en consommation de mémoire.
Si j enregistre ces données dans un fichier csv alors la suppression de la premiere ligne enregistre coute beaucoup de temps.
la deuxième solution est d utiliser ring buffer mais ca sera un peu couteuse si on utilise la liste chainee pour 600000 elements.
SVP y a t il d autres idees ou bien y a t il une optimisation sur ce que je proposee.
Bien cordialement

[umfred]

Bonjour,
J ai une application qui mesure des valeurs chaque milliseconde et les enregistre.

Elles sont enregistrées où, comment?

ton problème c'est la consultation des 10 dernières minutes de données ?

Il me semble que tu peux interroger un fichier csv via une requête sql si ça peut aider

[mouna1984]

Pour le moment ils sont enregistre dans un fichier CSV mais le problème est que je peux pas ajouter des lignes en haut du fichier et supprimer celles en bas. Autrement dit, si je commence l enregistrement de ces valeurs a 9:00:00.000 ,après 10 minutes, c est a dire a 9:10:00.001, j ai besoin d ajouter une ligne a cet instant en haut du fichier et supprimer la ligne qui contient 9:00:00.000.
Pour cette raison, j ai besoin d avoir une solution optimale de sauvegarde de ces valeurs qui permet d ajouter et supprimer des lignes chaque milliseconde.
Base de données ou bien ring buffer ou bien s il y a d autre méthode plus optimale

[umfred]

Dans ta réponse, j'ai l'impression que tu ne parles que des données des 10 dernières minutes.
Moi dans mon interrogation, je parle de la sauvegarde que je suppose pérenne et continue des mesures (donc pas uniquement celles concernant ta problématique des 10 dernières minutes).

Et pour ta problématique, il faut interroger cette sauvegarde afin d'en extraire les données dont tu as besoin.

[mouna1984]

J ai pas besoin d archiver des valeurs au dela des 10 minutes. Ma question n est pas comment extraire des valeurs de ce fichier mais comment je peux avoir seulement les 10 dernieres minutes donc a chaque milliseconde j ai besoin d ajouter des lignes et supprimer d autre en meme temps

[popo]

Ce que tu cherches à faire s'appelle du Roll Log ou du Rolling log.
Il existe des tonnes d'exemples sur le net.
Comme celui-ci :

Bien sûr il va falloir adapter.
Calculer la taille du fichier pour correspondre à tes 10 minutes.
Supprimer les fichiers dont tu n'as plus besoin.

[mouna1984]

Je vous remercie énormément pour votre réponse. C est une nouvelle information le roll log mais ce n est pas ca ce que je cherche. EN fait le roll log permet a un certain taille de créer un autre fichier et de poursuivre l ajout du log.
Dans mon cas si je commence l écriture a 9:00:00.000 alors une première fichier va être crée a cet instant. A 9:10:00.001, un autre fichier va être crée. Par exemple a l instant 9:13:00.000 je veux consulter les valeurs des dix dernières minutes alors les données se trouvent dans deux fichiers. J ai besoin de prendre les 7 derniers minutes du premier fichier et ajouter les 3 autres minutes de l autre fichier. Dans mon cas je veux avoir seulement un seul fichier que je peux le consulter et avoir les dix dernières minutes a n importe quel instant. Y a t il une façon d avoir toutes ces informations dans le meme fichier

[umfred]

ça fait partie des adaptations à faire.
par exemple, lecture du fichier par ReadAllLines pour avoir une liste de lignes, insérer la nouvelle mesure à la fin, supprimer la 1ère si nombre de lignes >=10, écraser le fichier avec les données.

En terme de rapidité, peut-être passer par une Queue (pile en français)(à voir côté utilisation mémoire) (on remplit la pile des mesures et si on dépasse le nombre attendu, on dépile une fois)
https://learn.microsoft.com/fr-fr/do...1?view=net-8.0

[StringBuilder]

Bonjour,
Je ne comprends pas trop la logique du truc.
Passer par le disque, c'est en soit une aberration.
En effet, les temps d'accès disque sont de l'ordre des "quelques" millisecondes, donc supérieurs à la vitesse de collecte des données.
Cela implique doit une architecture onéreuse pour pas grand chose, soit un programme qui va marcher quand il a le temps.
Dans tous les cas, cela implique une sollicitation matérielle et un gaspillage absurde des ressources.

Donc si le but est de n'avoir que 10 minutes d'historique, on reste sur un volume restreint : quelques dizaines ou centaines de Mo.

Qui plus est, serialiser en CSV (et deserialiser à la relecture) est franchement coûteux pour un programme qui doit avoir le temps de travailler toutes les ms.

Enfin, relire le fichier CSV pour ensuite faire des traitements sur cet histoirique va probablement se traduire par un chargement en mémoire de l'ensemble du fichier + la deserialisarion on multiplie par deux l'espacee mémoire nécessaire...

Donc deux solutions :
- si t'es pas sur de l'embarqué avec une mémoire ultra limitée, garde tes données dans un simple array, et boucle sur un index modulo la nombre de l'historique nécessaire
- si la mémoire est limitée, il faut passer par un serveur de données distant, par exemple un SGBD qui sait travailler avec des tables inmemory. Il sera probablement plus performant lors des interrogations que ton programme. Attention tout de même à la latence réseau...

[Noxen]

ça fait partie des adaptations à faire.
par exemple, lecture du fichier par ReadAllLines pour avoir une liste de lignes, insérer la nouvelle mesure à la fin, supprimer la 1ère si nombre de lignes >=10, écraser le fichier avec les données.

En terme de rapidité, peut-être passer par une Queue (pile en français)(à voir côté utilisation mémoire) (on remplit la pile des mesures et si on dépasse le nombre attendu, on dépile une fois)
https://learn.microsoft.com/fr-fr/do...1?view=net-8.0

Queue c'est file (comme une file d'attente), la pile c'est stack.

[Pol63]

...

ce n'est pas parce qu'un disque dur a une latence qu'il ne convient pas pour enregistrer beaucoup de trucs à la seconde, windows gère un cache et tant qu'il n'écrit pas 100Mo/s ca suivra (c'est asynchrone)
quant à remplacer ça par du réseau, qui peut avoir une latence plus élevée qu'un disque dur dans certaines entreprises ... !?

la seule question est y a t il un besoin de persistance (ne serait ce que pendant ces 10 minutes)

[StringBuilder]

la seule question est y a t il un besoin de persistance (ne serait ce que pendant ces 10 minutes)

La question est déjà répondue : ils ne souhaite conserver que les 10 dernières minutes.
Donc si sauvegarde sur disque (ou autre) il doit y avoir, ce sera plutôt à la fermeture du programme qu'au fil de l'eau.

Ensuite, pour les écritures toutes les ms, oui, il y a du cache, mais à moins de faire un développement couteux en multithreadé, avec gestion d'un buffer, le programme va de toute façon être arrêté lorsque le cache devra être flushé, et surtout lorsqu'on devrait relire tout le fichier afin de faire des stats dessus.

J'ai un PC, certes très pourri, mais malgré un SSD NVME le programme bloque les écritures plusieurs dizaines de ms dès que je relis le fichier. C'est absolument logique. On peut aussi dire à .NET de ne pas poser le moindre verrou sur le fichier, mais ça risque d'être rapidement la fête du slip si des traitements écrivent et lisent en même temps dans le fichier... d'autant plus si c'est un CSV !
Et si au final, c'est pour bosser avec un cache de la taille du fichier pour se libérer de ce goulot d'étranglement, ça me semble totalement inutile d'enregisrter sur le disque au fil de l'eau, puisqu'au final on ne fait rien du fichier physique !

Le seul intérêt éventuel, c'est d'avoir une image des stats au moment d'un crash du logiciel. Ca me semble relativement limité. Et dans tous les cas Windows et .NET disposent de tous les outils pour faire un dump mémoire en cas de plantage, pas la peine de le gérer (bien plus mal) soit-même.

Enfin, l'idée du SBGD in Memory, c'est surtout pour la relecture/consolidation des données. Selon la nature des statistiques à produire sur ces 600000 lignes, le faire soit-même avec des algos "simplistes" peut s'avérer bien plus lent que si on laisse faire à un SGBD. Après, je suis d'accord que si on ajoute la latence réseau, c'est pas sûr qu'on y gagne quelque chose... Mise à part les quelques Mo de mémoire nécessaire à gérer les données en local.

J'ai tenté de mon côté de remplacer le CSV par un fichier de "records" mais même avec ce type de fichier (qui permet de faire des lectures/écritures en // sans risque) le programme n'arrive pas à tenir la cadence d'un enregistrement par ms. D'où ma remarque sur les besoin aberrants en termes de matériel et ressources par rapport au besoin.

[Edit]
Accessoirement, je viens de refaire des tests, avec certes pas forcément la meilleure architecture, mais... Même avec un traitement exclusivement en mémoire, ça tiens pas les 1 ms. Dans le meilleur des cas, j'arrive à faire une écriture toutes les 2 ms.
Quant à la relecture des données pour faire les stats dessus... bah... on est très loin de la ms, donc pendant ce temps pas d'accès possible à l'objet pour écrire...

Deux questions se posent :
- quel est l'intérêt de garder le détail à la ms si l'analyse est sur 10 minutes ? pourquoi ne pas faire une aggrégation des données à la seconde par exemple, ce qui est déjà très fin pour une analyse sur 10 minutes
- une architecture à base de multithread et des buffers dédiés à chaque tâche me semble obligatoire afin de ne pas bloquer la collecte des données par les calculs statistiques. l'effort en vaut-il la chandelle ?

Une troisième subsidiaire : ne serait-ce pas plus logique de travailler directement en C ou même en ASM afin de faire des accès direct en mémoire plutôt que de passer par les objets managés (et donc de facto bien plus lourds) de .NET ?

Enfin, sous quelle forme arrivent les mesures ? J'ai fait tous mes tests à base de tableau d'objets (construits à la volée avec des valeurs random). En soit c'est super lent d'instancier de nouveaux objets pour chaque mesure. Si on récupères les données brutes sous forme d'un byte[] par exemple, alors il vaut mieux travailler avec plutôt que de tenter de le structurer au moment du log.

[umfred]

Queue c'est file (comme une file d'attente), la pile c'est stack.

au temps pour moi, pour l'erreur de vocabulaire (c'est vrai dans la file d'attente c'est du FIFO, et la pile du LIFO)