Reprise du message précédent :

 
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.

après hepha était assez rigide sur une table/dimension, et ce principe scale automatiquement avec la vitesse d'évolution de l'état du système. l'état du système est la dernière ligne de chaque table.
l'inconvénient, c'est un arbre de tri par dimension.

Il y aura plusieurs usages complètement différents par des équipes différentes:
1) monitoring et alerting temps réel
2) historisation sur 10 ans du cycle de vie du matériel, de données de manufacturing, et d'exploitation en data centers (notamment pannes de matériels, calcul de coûts d'exploitation, dépense d'énergie, etc)
3) data mining dans ces données pour détecter par exemple des optimisations possibles ou des pannes systémiques dues à du matériel défaillant, estimation de MTBF, etc

Bref le genre de truc donc vous avez l'expertise, mais nous à une échelle 3 ordres de grandeur plus bas.

Ah non, normaliser c'est pas pour optimiser la place, c'est parce que c'est la seule façon de stocker les données sans aucun risque d'ambiguïté ou d'incohérence. C'est le plus facile à faire correctement.

Cependant, je vois un intérêt à la dénormalisation totale, j'ai édité mon message. J'aime pas ça, mais ok. Mais j'aime pas ça.

Mais avant de cacher ou d'optimiser des calculs (4 lookups et une soustraction ? wow tu as fait une demande de TPU on risque d'être un peu short Q12025), faut voir ce qu'ils coûtent, non ?

Et ces optimisations peuvent très bien se faire par dessus des données normalisées, je pense que c'est presque toujours une erreur d'adapter le stockage au métier.

Oui, normaliser, ça permet de garder les données parfaitement cohérentes en évitant d'avoir ç gérer des doublons dans diverses tables.
Mais là en l'occurence, ce sont des données de sources différences, temporelles, et qui ne seront pas supprimées (à moins de faire des suppressions du style "toutes les données plus anciennes que..." ), donc il n'y aura pas de doublons ou de risque d'incohérences.

 
 
Ta Nébuleuse Vision Produit des Efforts Accrus et Bancals  

famous last words, mais aussi c'est pas le seul but, le but premier (dans ce cas) c'est la simplicité. On comprend immédiatement ce qui se passe avec des données normalisées, chaque entrée correspond à un évènement réel, on n'a pas besoin de vérifier quoi que ce soit.

 
Tu Ne Vas Pas En Avoir Besoin (YAGNI).

Pas compris. Dans des time series aussi, chaque ligne correspond à un événement réel. D'ailleurs c'est comme ça qu'on va les conceptualiser: chaque ligne correspond à un événement dans le temps et "l'espace" (défini par un ID unique SAP).

(mais je te rassure, ce seront bien des tables séparées par entité, on ne va pas faire ce qu'a suggéré rufo)

Qu'est-ce qui est dénormalisé dans cette histoire ? Je croyais que tu voulais faire des table avec des signaux aggrégés ?

En l'occurence dans ton cas, il n'y a pas de relation entre les différentes données (autre que temporelle), la normalisation c'est juste qu'au lieu de stocker [t1: {s1, s2, s3}, t2: {s1', s2, s3}, t3: {s1', s2, s3'}], on stocke [t1: s1, t2: s1'], [t1: s2], [t1: s3, t3: s3']. Les deux sont bien, mais la seconde est mieux à mon avis (et tu sembles partir là-dessus, c'est tout à ton honneur ). L'idée que je suis à peu près sûr est bien trop maline pour être bonne, c'est de stocker des sous-états.

il y a taich qui a écrit un truc : https://guillaume.techene.net/2024/ [...] efinition/

Six ans plus tard, heureusement qu’on est dans une industrie qui n’avance pas bien vite  

et the onion qui rachete infowar. C'est vraiment du popcorn taille xxl

Encore des gauchiasses qui infiltrent les médias pour leurs guerres d'influence  

 
https://theonion.com/heres-why-i-de [...] -infowars/  

c'est clairement un truc de gauchiste de profiter des plateformes pour vendre des services en plus  
https://france.representation.ec.eu [...] refLang=en

Notre surtaxe exceptionnelle sur les entreprises américaines fonctionne toujours
 
Les producteurs de frometon et de vinasse vont prendre cher  

Ca ressemble quand même beaucoup à des logs d'une certaine façon. Il me semblait avoir vu que maintenant, on passait par une BD NoSQL (souvent de type document) car c'était plus performant pour le stockage et le traitement qu'un SGBDR quand il y avait des gros volumes.

Oui il y a des ressemblances: données immutables timestampées insérées en append only.
De toute façon, je viens de passer le sujet à l'équipe data dont c'est la spécialité. Ils m'ont dit que les time series et applis du genre qu'on demande étaient déjà dans leurs cordes, donc c'est un soucis en moins pour nous.
On se contentera de balancer Kafka dedans, et ils s'occupent du reste.
Ca me va très bien.

Perdre la structure des données en foutant tout dans la même table, ce serait dommage, à moins de payer notre fournisseur au nombre de tables. C'est pas de simple logs, précisément parce que ce sont des données structurées.
 
Du NoSQL, pourquoi pas, mais en terme de techno DDT en a mentionné quelques-unes plus adaptées au besoin (et un SGBDR c'est sans doute quand même la bonne solution s'il y en a déjà un en place, à moins qu'on ait de bonnes raisons de penser que la différence de performance est un problème).

Il y a quand même des choix audacieux  

c'est quoi cette UI degueulasse ? c'est linux ?

 
Bonjour Vulcan,
 
Je me permets de vous contacter suite à votre parcours impressionnant et à vos compétences dans le domaine de la tarification. Nous pensons que votre expérience pourrait être en parfaite adéquation avec un poste de Pricing Manager que nous avons actuellement ouvert chez ChienDonnées.
 
Chez ChienDonnées, nous sommes engagés et nous recherchons des talents comme le vôtre pour nous aider à atteindre nos objectifs ambitieux. En parcourant votre profil, j’ai particulièrement apprécié votre expérience en Pricing Management qui serait un atout précieux pour notre équipe.
 
Nous aimerions beaucoup vous en dire plus sur cette opportunité et discuter avec vous de votre parcours, de vos aspirations, et de la façon dont vous pourriez contribuer à nos projets actuels et futurs. Seriez-vous disponible pour un échange téléphonique ou une rencontre virtuelle dans les jours qui viennent ?
 
N’hésitez pas à me proposer un créneau qui vous conviendrait, ou je peux également m'adapter à vos disponibilités.
 
Dans l’attente de vous lire, je reste à votre disposition pour toute question et espère pouvoir vous en dire davantage sur cette opportunité prometteuse chez ChienDonnées.
 
Bien cordialement,

Ayant peu d'infos sur la nature et le volume des données, pas facile de faire une réponse pertinente. Si une équipe de ta boîte sait faire et s'en charge, c'est parfait.
 
L'idée de la table unique, c'était dans le cas où tu as une liste d'événements bien identifiés et que chacun à le même nb de valeurs associées et de même nature (je t'avais posé la question mais tu ne m'as pas répondu). Ca permet d'avoir une structure unique où chaque type d'événement à un ID. Ainsi, si tu as de nouveaux événements par la suite, suffit de créer un nouvel ID et c'est tout, pas besoin de faire évoluer le code. Suivant la volumétrie et les traitements à faire dessus, tu peux partitionner la table unique sur le timestamp ou l'ID des événements (ou autre) afin de pas plomber les perfs.
 
Si les données sont de nature très différentes et en gros volume, du NoSQL peut avoir un intérêt, notamment si après, y'a une volonté de faire de la data analyse. Y'a pas mal d'outils orienté data mining qui travaillent avec du NoSQL en particulier pour le calcul distribué (Hive, HBase, Spark et tout ce qui tourne autour de Hadoop).

Non mais tu n'es pas loin, tu as du reconnaitre la patte GPL :

 
Hint: il bosse chez Google, la boîte qui a inventé ce type de bases de données.

 
Ne dis pas de mal de MPC-HC, c'est très bien MPC-HC.

C'est un variant, et c'est rarement une bonne idée, parce que ça fait porter le travail d'interprétation du type au consommateur. Bien sûr qu'il faut faire évoluer le code quand on rajoute un type, ce qui n'évolue pas c'est la couche de stockage. Ça peut être valable si il y a beaucoup en commun entre les différents types d'événements, et que les consommateurs s'en tiennent en général à la partie commune. C'est toujours un risque en termes d'évolution.

Oui après je ne suis pas un expert du tout. Mais justement en tant que non expert j'ai eu l'occasion de constater que c'est très dur d'atteindre les limites du gestionnaire de bases de données relationnel maison. Le choix n'est en pratique presque jamais sur la performance. Et typiquement pour un cas comme celui décrit ici, où on veut utiliser des données de plusieurs façons différentes pour moi le choix serait immédiat (Spanner, le MySql maison).

On utilise leveldb chez Plamcorps et putain quelle merde. Le temps perdu quand tu streams même 200000 entrées. Bon chaque entrée peut peser lourd chez nous. Mais c'etait pas le meilleur choix pour stocker des données clients. Surtout quand tu grossis à mort. La moindre recherche prend un temps fou.

C'était pratique au départ (après c'était pas mon idée, j'y suis pour rien ), mais c'est clair que c'est plus du tout adapté à la taille actuelle

Je me permets un petit lien vers mon dernier message dans la catégorie SQL/NoSQL, dans lequel je me pose la question de normaliser toutes les données que je fais entrer en BDD ou plutôt de stocker "en vrac", quitte à ne structurer "à la volée" que ce qui sera utile lorsque l'utilisateur en aura besoin :  
 
https://forum.hardware.fr/hfr/Progr [...] 8609_1.htm
 
Je suis presque sûr qu'il a été lu par quelques personnes d'ici, mais pas de réponse pour le moment (et la problématique est claire dans ma tête, mais pas évidente à expliquer, du coup n'hésitez pas si vous avez des questions).
 
Merci !

1/ Je suis d’accord pour les bénéfices de la normalisation
 
2/ ça va dépendre des volumes et de la patate du serveur. Tout le monde n’a pas Spanner  
 
3/ on est d’accord c’est ce que je disais au dessus d’ailleurs
 
 

 
Ça c’est parce que tu bosses sur des petits datasets
Selon comment les subqueries pour trouver la dernière fermeture de valve avant le timestamp x ça peut être lent, et ça devient vite sale si tu dois combiner plusieurs requêtes / avoir une logique pour calculer l’état actuel
 
Mais +1, j’utiliserais aussi Spanner, et vu que c’est la fête du slip je stockerais normalisé + cache des calculs, mais pour une boîte qui a un budget moins Lolilol ça me choquerait pas

de notre côté il y a du redis et du leveldb
le nombre de fois ou on charge tout en mémoire pour faire la moindre recherche

edit : en fait la majeur partie des objets ne vivent qu'en mémoire (chaque VM, chaque stat, chaque disque ,.. )

https://vm.tiktok.com/ZGdFyveJN/
 
Un Haka en pleine assemblée ça ça a de la gueule

C'est pas une question d'avoir Spanner, c'est que c'est certain qu'il existe des systèmes de stockage qui gèrent ce genre de problème sans aucune difficulté. Spanner n'est pas le seul, il y a vraisemblablement moins cher qui fait le job (j'ai aucune idée de comment se positionne Spanner en termes de coût). Après si tu me prouves que c'est moins cher d'utiliser un nosql, pourquoi pas mais là on part sur des considérations encore bien différentes, on n'a rien qui indique que ce soit significatif. On n'est pas des animaux, si on a des données structurées, on les stocke en gardant la structure !

Mais bordel, il s'arrête jamais avec ses vidéos lui. Un coup à nous pourrir les recommandations

@ratibus t'es loin de figeac ?

Tu te trompes de personne, j’ai jamais parlé de nosql?

Entre 1h et 1h30.

Ça m'étonne  
Je veux dire, à part Flaie , je n'ai pas vu de facho ici