Reprise du message précédent :

Ah si si, ça fait des années qu'il lui répond sur ses différents topics
 

 
1 blabla en 5 ans sur ce topic (Gatsu s'en souvient encore), je pense pas avoir besoin d'assistant, même si vous mériteriez une bonne fessée parfois
Depuis le début, il est admis que ce topic  sert de défouloir, et ce malgré les demandes de modération farfelues (suivez mon regard https://forum-images.hardware.fr/im [...] -12999.jpg  )

Il y a défouloir et il y a des propos publics contraires à la loi pour leurs contenus sexistes, racistes, xénophobes ou diffamatoires, même si l'individu a un rôle de modérateur.
 
Machine modo ça serait quand même autre chose  

Méwé

Petite question gestion de données.
 
Vous avez des time series diverses et variées (par exemple des températures, des événements style ouverture/fermeture de vanne, etc), et vous voulez récupérer toutes les données à un timestamp donné, pour pouvoir reconstituer l'état du système à cet instant.
 
Comment vous vous y prendriez au niveau organisation des données pour une récupération efficace et souple ?

Est-ce que tout ce que tu dois collecter comme données, c'est un type d'événement et une valeur numérique ?

Je mets tout dans Log Parser pis voilà https://techcommunity.microsoft.com [...] dio/601131

Demande de changement de modo = TT

Ajout    
 
On a encore fourmip  

N tables, indexées par timestamp, et on lit dans chaque table séparément ; ou si t'as aucun respect pour toi-même, une seule table avec l'état global mais bon à ce compte là on fait pas genre on se soucie de la gestion des données.

Vous avez connaissance d'un bon outil pour un diff qui analyserait la ligne de droite à gauche ? (sans appeler rev ou autre pour juste renverser le texte) Ça serait pratique pour chercher la première diff en partant de la fin mais je trouve rien... comment on fait pour diff deux txt en arabe en fait...

S'il part sur un SGBDR, une seule table avec un champ indiquant le type d'événement, le timestramp et la valeur numérique, la table étant partitionnée sur le type, par ex, ça peut le faire.
Sinon, un stockage dans du NoSQL.
Faut voir aussi le volume et les traitements qu'il veut faire.

y'a une partie un peu chiante, parce que pour l'état du système à un instant T, il faut collecter les évènements utiles qui ont eu lieu avant (genre la dernière fois que la vanne a bougé avant T).
 
 
La méthode la plus naïve : tu stocke les évènements dans l'ordre du temps et quand tu fais une analyse, tu va chercher le point temporel de ton analyse, et tu remontes le temps en complétant les dimensions de l'état du système. Tu arrête de remonter quand l'état est complet.
 
Ensuite il faut adapter aux circonstances : Est-ce qu'il y a une tonne de dimensions dans l'état du système ? Est-ce que le système bouge beaucoup ? Est-ce que tu peux fragmenter l'état du systèmes avec des dimensions qui bougent beaucoup et des dimensions qui bougent moins vite.

Toi t'as jamais travaillé dans une ESN on dirait, une telle expertise c'est direct un poste de Tech Lead senior

Il est encore vivant  fourmip ?
Sinon y'a Gilou aussi, et Elmo

 
C'est sûrement très intéressant. Un lien ?

Et oui, bon rétablissement à ton paternel.

On sait bien que tu es dans le même EHPAD que Gilou    
Et Elmo il agit et sanctionne les propos irresponsables de Flaie, il a conservé un peu de culture  

tu t'éparpilles un petit peu je trouve

Oui, je comptais partir sur quelque chose comme ça. Des time series avec pas/ très peu de clefs étrangères, et indexées sur le timestamp.

Oui, c'est l'idée.
L'autre idée, c'est de conserver tout l'état du système en RAM et de tout écrire à intervalles réguliers dans une seule transaction.L'avantage est que c'est assez simple à implémenter et très rapide en requête, l'inconvénient étant que ça génère une quantité de données bien plus importante que nécessaire (j'ai aucun respect pour moi-même ).

Comme tu dis, si je fragmente en ordre de grandeurs, je peux faire ça. Par exemple toute les données qui se mettent à jour toutes les secondes ou sub secondes dans un sub-état, toutes celles qui se mettent à jour toutes les 1mn à 10mn dans un autre sub-état, toutes celles de l'ordre de l'heure ou plus dans un 3e sub-état.De sorte que je limite les duplications de données, et je n'ai que 3 requêtes à faire pour récupérer les 3 sub-états et reconstituer l'état complet à l'instant T.

https://youtu.be/_u3mul4gaPE?si=Yn_ [...] Sqx&t=1047
here you go, 40min sur une possible épidémie de peste au néolitique.

tu as aussi des manières de présenter les choses, si tu enregistre des fragements d'état à intervalle régulier (des checkpoints), tu peux les garder sous forme de cache ou de vue matérialisée, et pour le consommateur de l'API, c'est régularisé. ça permet d'introduire des fonctions style "butte le cache" ou "donne-moi l'état à telle date sans utiliser de cache" si les utilisateurs perdent confiance dans la dénormalisation.

Non mais si tu pars par là, stop tout de suite. Tu as deux solutions : soit tu veux faire un truc propre et robuste dans le temps, et tu crées une base de données normalisées ; soit tu es confiant que ça ne va pas exploser au point d'être un problème, et tu veux gagner un peu de temps et tu stockes l'état global à chaque changement. Si tu sais déjà que tu as besoin de hacks pour faire marcher la seconde solutions, c'est que tu n'en veux pas.

Dans ce cas pourquoi pas utiliser une BDD optimisée pour ça?
Selon ce que tu veux faire exactement: TimescaleDB, InfluxDB, Prometheus, VictoriaMetrics... voire ClickHouse.

 
Quel est le problème avec la solution que je propose ?

 
Je vais examiner ce genre de solution aussi.

Elle est trop compliquée, sans aucune nécessité.

 
Ben si, parce que la base va probablement être requêtée en mode OLAP. Donc une normalisée ne sera pas super pour ça.

Car bon, entre l'IoT et les douzaines d'outils d'observation et collecte de métriques, c'est vraiment un domaine complètement saturé, ça m'étonnerait que tes besoins soient si spéciaux qu'il faille réinventer la roue.
 
Perso avec le volume et la quantité de time series qu'on gère on fait tout en streaming avec Kafka et S3, mais plus pour une question d'interfaçage avec les autres équipes qu'une vraie contrainte technique.
 
J'ai pas essayé ClickHouse dans mon cas mais je pense qu'on serait très loin d'arriver à le mettre à mal.
Même si c'est pas spécialement fait pour des time series, ils ont un peu tué le game en OLAP, à moins d'arriver à des volumes où il faut se tourner vers du vrai data warehousing.

Tu peux élaborer ?

 
Parmi les applications dont les data analysts peuvent avoir besoin, il y a l'évolution du système dans le temps, sur une plage de temps indéterminée. Par exemple l'évolution d'un  nuage à N dimensions. Tu veux soit avoir toutes les données en mémoire pour cela, ou faire des requêtes rapides en temps réel (ou quasi réel).

C'est la proposition de départ (sauf pour S3 of course), mais il n'empêche que même avec ces solutions, il faut être un minimum intelligent dans le stockage des données.

https://www.ohrg.org/cycling-typing
 
ah enfin une bonne raison d'utiliser un split keyboard !

J'vais scier mon MS 4000 en 2  

À ce stade là, passer sur un chorded semble une bonne idée.

 
   
 
Donne mois tes recos Youtube, je te dirai qui tu es.

Avoir des données normalisées n'est contradictoire ni avec le fait de les garder en mémoire (au contraire, si c'est normalisé c'est optimisé pour l'espace), ni avec le fait de faire des requêtes rapides.

ah mias je suis pas d'accord non plus. Je trouve que c'est du foutage de gueule, particulièrement après avoir augmenté Premium
 

 
+1 avec nraynaud : stocker en plusieurs tables ou pas ça change pas le fait que dans l'exemple que donne Much, la température va varier probablement en fonction du temps depuis la dernière ouverture / fermeture de vanne.
Ma première question serait : comment tu vas utiliser ces données ? si tu cherches à faire un algo de régulation, l'algo va dicter comment tes données doivent être structurées. L'autres question c'est : quelles questions tu vas avoir pour ces données ?
 
Si c'est juste du reporting je dénormaliserais le truc : table des temperatures avec des colonnes en plus indiquant l'étant du système (valve ouverte ou fermée, voir la duration depuis le dernier changement d'état, ou delta de temperature depuis le dernier changement. Encore une fois t'es pas obligé de stocker ça (tu peux garder une table par type d'évènement), mais tu vas vouloir l'avoir en mémoire pour faciliter tes analysers.

Aaaaaaaaaaah mais pourquoi ?!? Et pourquoi changer la façon dont on les stocke en fonction de la façon dont on les utilise ? Les données ne changent pas, les usages, si, en plus il peut y en avoir plusieurs ! C'est de la premature over engineering optimization, TNVPEAB.

Je maintiens qu'il y a pas 36 solutions pour le stockage des données (à moins d'exigences hyper pointues, on n'est manifestement pas dans ce cas-là). Il doit être trivial à comprendre et à utiliser, donc soit c'est normalisé, soit c'est complétement dénormalisé mais c'est certainement pas un truc hybride pour soit-disant avoir le meilleur des deux mondes en rejetant la complexité sur la couche la plus profonde.

T'as deux fois du budget et deux achievements

 
1/  
- d'accord pour le besoin, d'où mes questions à Much. En effet si tout ce qu'il doit faire c'est afficher les données / faire un graph des temperatures, aucun besoin
- dénormaliser c'est un gain de place, ou de réutilisabilité. Sur des time series c'est pas évident que tu vas beaucoup compresser, et pour lea réutilisabilité ça dépend de plein de facteurs. Prouve moi que tu vas devoir normaliser
- tu peux aussi optimiser ton stockage pour la lecture, ou pour cacher des calculs intermédiaires.
2/ si comme ça semble etre le cas d'après les infos de Much, on veut résonner sur l'état d'un système dans le temps, ou voir l'effet d'une action X sur une variable Y, tu vas sans arrêt devoir recalculer des trucs genre delta de temps depuis la dernière action de type X. Ces deltas ne vont pas changer dans le temps, donc ça fait sens de les cacher.
 
Je ne dispute pas le fait que tu puisses les stocker comme tu veux, y compris de façon normalisée. Par contre tu peux vouloir stocker une représentation intermédiaire avec ces calcules de delta déjà fait. Idéalement si le système qui fait les logs de température a accès à l'état des trucs genre valve, etc... tu peux meme calculer ces trucs en mode stream.