Est-ce que tu auras besoin de tes données brutes par la suite ? Si non, ça n'a pas d'intérêt de les garder.
Par ailleurs, si ta condition de tri est connue est stable, tu pourras directement stocker les valeurs "clean" (par ex: pas besoin d'enregistrer la valeur "999999" et de la supprimer si tu sais que ce n'est pas pertinent)
Après, ce n'est pas vraiment couteux de conserver les données brutes. Ça pourra servir à re-filtrer par la suite, s'il y avait des valeurs que tu aurais supprimées par erreur, ou bien pour faire des analyses spécifiques sur les valeurs incorrectes.
Et dans ce cas, comme tu ne les utiliseras probablement pas souvent, tu peux simplement les stocker en forme de log, plus portable, plus léger, et exploitable avec d'autres outils (mais ça demande d'avoir des compétences différentes).
Est-ce une bonne pratique d'avoir des tables temporaires pour un service IoT ?
il y a 4 ans
par
VincentLe
Ma première question Skiller ! Et je commence par une question précise d'architecture logicielle.
Je vais développer une API web dans laquelle des objets connectés vont verser des données, via une requête HTTP.
Ces données ne seront pas "propres" et je vais devoir les trier et en supprimer certaines.
Question : est-ce une bonne pratique de prévoir une table temporaire qui reçoit les données, ou bien dois-je tout faire sur une seule base.
Illustrons ça par des capteurs de température.
Scénario 1 :
Table_Temperatures_TMP
10
7.8
9.1
9999999
0.1
8
Puis calcul pour obtenir
Table_Temperatures_CLEAN
10
7.8
9.1
8
Scénario 2 :
Table_Temperatures
10
7.8
9.1
9999999
0.1
8
Avec une routine qui la met à jour :
Table_Temperatures
10
7.8
9.1
8
4
2
2 réponses
Si tu es sur du gros volume, je te recommande de les stocker dans un format "brut" genre hadoop/NoSQL. L'avantage de cette architecture, c'est qu'elle est facilement "scalable" et si tu récupères ce genre d'information, m'est avis que ton architecture doit être capable de monter rapidement en puissance/volume.
Ensuite, une fois que tu as stocké ça, rien n'empêche que tu les retravailles dans une base ... soit identique en nature (hadoop/NoSQL donc) ou bien dans une base de données relationnelle. Tout dépend si tu restes sur des volumes identiques ET donc devant avoir une capacité de monter en puissance/volume rapidement.
Ensuite si tu ne peux pas te permettre de "gaspiller" des données, autrement dit d'en perdre, alors il vaut mieux dissocier "matière brute" de "traitement".
Donc avoir deux bases, *résilientes et non temporaires*, l'une pour recevoir de la donnée brute, "timestampée" et dans une architecture facilement scalable (si qqn a un mot français je suis preneur !) et l'autre pour récupérer le résultat d'un traitement de ces données brute. La base "propre" si elle doit contenir le même volume de données devra être aussi dans un format "scalable".
Ensuite, une fois que tu as stocké ça, rien n'empêche que tu les retravailles dans une base ... soit identique en nature (hadoop/NoSQL donc) ou bien dans une base de données relationnelle. Tout dépend si tu restes sur des volumes identiques ET donc devant avoir une capacité de monter en puissance/volume rapidement.
Ensuite si tu ne peux pas te permettre de "gaspiller" des données, autrement dit d'en perdre, alors il vaut mieux dissocier "matière brute" de "traitement".
Donc avoir deux bases, *résilientes et non temporaires*, l'une pour recevoir de la donnée brute, "timestampée" et dans une architecture facilement scalable (si qqn a un mot français je suis preneur !) et l'autre pour récupérer le résultat d'un traitement de ces données brute. La base "propre" si elle doit contenir le même volume de données devra être aussi dans un format "scalable".
Nice! J'aime bien cette idée de garder une "couche" NoSQL séparée. Par contre je n'ai absolument aucune idée de comment le faire. Aurais-tu un lien sur les bases du NoSQL ? Un conseil sur la techno à utiliser ? Voire un exemple de NoSQL+WebAPI ?
@VincentLe : je ne vais pas faire original : en.wikipedia.org/wiki/NoSQL
Mais c'est une bonne entrée en matière sur ce qu'est le NoSQL, sa scalabilité dans ses différentes saveurs technologiques, qui les utilise voir les a créé. Suis les liens notamment sélectionne bien la plateforme qui te correspondra le plus.
Quant à mes informations, les technos les plus utilisées pour les base NoSQL sont MongoDB, Cassandra et HBase. Ce sont des produits /conçus et/ou utilisés par facebook, Google, etc...
Si tu es sur Toulouse, le 1er octobre, Orsys organise une conférence en après-midi sur le Big Data où sera abordé sous toutes ses formes : www.orsys.fr/mail/Web/Toulouse151001.html je sais qu'ils en organisent d'autres ailleurs. Vois sur leur site :)
Mais c'est une bonne entrée en matière sur ce qu'est le NoSQL, sa scalabilité dans ses différentes saveurs technologiques, qui les utilise voir les a créé. Suis les liens notamment sélectionne bien la plateforme qui te correspondra le plus.
Quant à mes informations, les technos les plus utilisées pour les base NoSQL sont MongoDB, Cassandra et HBase. Ce sont des produits /conçus et/ou utilisés par facebook, Google, etc...
Si tu es sur Toulouse, le 1er octobre, Orsys organise une conférence en après-midi sur le Big Data où sera abordé sous toutes ses formes : www.orsys.fr/mail/Web/Toulouse151001.html je sais qu'ils en organisent d'autres ailleurs. Vois sur leur site :)
Fascinant ce NoSQL, mais je vais peut être le garder pour plus tard, l'urgence est le prototype.
J'ai encore deux questions pêle-mêle :
1- As-tu une idée pour sécuriser mes requêtes venant de mes capteurs ? (juste pour éviter qu'un bad guy envoie une fausse température, ou m'envoie un million de températures)
2- Est-ce que Skiller a une fonction "fermeture de discussion" pour repérer les problèmes résolus ?
(je ne suis pas Toulousain)
J'ai encore deux questions pêle-mêle :
1- As-tu une idée pour sécuriser mes requêtes venant de mes capteurs ? (juste pour éviter qu'un bad guy envoie une fausse température, ou m'envoie un million de températures)
2- Est-ce que Skiller a une fonction "fermeture de discussion" pour repérer les problèmes résolus ?
(je ne suis pas Toulousain)
@VincentLe : la sécurisation passe par plusieurs choses :
1. HTTPS : un certificat pour la sécurisation de la transmission
2. un login/pwd : ben comme ça au moins tu es sûr.
3. un système de clé publique/clé privé à la PGP (Pretty Good Privacy) et autres....
4. ton service IoT reste local (sur un réseau local) et n'est pas ouvert vers internet ;)
Sur le fait de "fermer" une question, pourquoi faire ? si quelqu'un de plus compétent ou de plus expert ou ayant des solutions pertinentes, mais un peu plus tard, a envie de réalimenter les réponses, c'est mieux non ?
1. HTTPS : un certificat pour la sécurisation de la transmission
2. un login/pwd : ben comme ça au moins tu es sûr.
3. un système de clé publique/clé privé à la PGP (Pretty Good Privacy) et autres....
4. ton service IoT reste local (sur un réseau local) et n'est pas ouvert vers internet ;)
Sur le fait de "fermer" une question, pourquoi faire ? si quelqu'un de plus compétent ou de plus expert ou ayant des solutions pertinentes, mais un peu plus tard, a envie de réalimenter les réponses, c'est mieux non ?
Je me permet de mettre un petit bémol à cette réponse.
Les problématiques de "gros volume" sont très rarement atteintes dans la réalité.
Pour justifier l'emploi d'une techno comme Hadoop, il faut au moins quelques TO de données, ce qui représente généralement plusieurs centaines de milliards de lignes en base de données.
Alors, effectivement, ça scale (dans certains cas), et ça fonctionne, donc on pourrait très bien mettre ça en place, comme on pourrait faire de la livraison de sushi avec un 35 tonnes, en se disant que si jamais on a énormément de clients, on pourra scaler.
Le problème, c'est que Hadoop est beaucoup plus compliqué à utiliser que des technos "classiques" comme SQL. Du coup, partir sur une techno de ce genre va considérablement augmenter le cout du projet (les experts Hadoop sont chers, et ils passent (parfois beaucoup) plus de temps à mettre en place des fonctionalités relativement simples.
Plus d'infos (en anglais, par un Data Scientist qui connait bien Hadoop): www.chrisstucchio.com/blog/2013/hadoop_hatred....
Par ailleurs, des sites comme YouTube et Facebook utilisent toujours MySQL en stockage principal (il me semble). Une société pour laquelle je travaillais avec un volume d'environ 100 milliards de requêtes/mois utilisait MS SQL Server. Les techniques d'optimisation et de scaling sont souvent assez basiques (calcul de tables temporaires, cache...).
Un autre bémol, plus petit toute fois, concernant le NoSQL.
C'est une approche très intéressante, qui effectivement de stocker de grandes quantités de données efficacement, et qui offre une souplesse de part son absence de schéma (pour la plupart).
En revanche, le changement de paradigme est assez fort pour quelqu'un qui a l'habitude de tables SQL. Notamment sur l'absence de liaisons, le besoin de redondance, et les problématiques de maintenance que ça implique, notamment dans le cas de données absentes/altérées.
Donc je ne démarrerais pas un projet en NoSQL si je n'avais pas d'expérience de mise en place de cette techno. En fait, si, je l'ai fait... et j'en ai payé les conséquences : problèmes de performances liés à une utilisation inefficace des liaisons entre des collections, nombreuses migrations pour ajouter de la redondance et avoir accès à ce qu'on veut,...
D'ailleurs si la plupart des projets sont réalisables en NoSQL, certains se retrouvent vraiment bloqués par le principe. Voici un exemple très intéressant (en anglais): www.sarahmei.com/blog/2013/11/11/why-you-should...
Encore plus grave, dans le sens "ne pas utiliser quelque chose qu'on ne connait pas", le cas de Flexcoin qui s'est fait hacker 896 bitcoins parce qu'ils ne maitrisaient pas l'aspect "sécurité" de MongoDB: hackingdistributed.com/2014/04/06/another-one-b...
Et enfin, avoir une "couche" qui utilise une techno différente, ça veut dire une configuration supplémentaire du serveur, de la RAM, du CPU une logique différente à avoir en tête,.... alors que l'on a déjà une techno qui fait le boulot (SQL ou logs).
Les problématiques de "gros volume" sont très rarement atteintes dans la réalité.
Pour justifier l'emploi d'une techno comme Hadoop, il faut au moins quelques TO de données, ce qui représente généralement plusieurs centaines de milliards de lignes en base de données.
Alors, effectivement, ça scale (dans certains cas), et ça fonctionne, donc on pourrait très bien mettre ça en place, comme on pourrait faire de la livraison de sushi avec un 35 tonnes, en se disant que si jamais on a énormément de clients, on pourra scaler.
Le problème, c'est que Hadoop est beaucoup plus compliqué à utiliser que des technos "classiques" comme SQL. Du coup, partir sur une techno de ce genre va considérablement augmenter le cout du projet (les experts Hadoop sont chers, et ils passent (parfois beaucoup) plus de temps à mettre en place des fonctionalités relativement simples.
Plus d'infos (en anglais, par un Data Scientist qui connait bien Hadoop): www.chrisstucchio.com/blog/2013/hadoop_hatred....
Par ailleurs, des sites comme YouTube et Facebook utilisent toujours MySQL en stockage principal (il me semble). Une société pour laquelle je travaillais avec un volume d'environ 100 milliards de requêtes/mois utilisait MS SQL Server. Les techniques d'optimisation et de scaling sont souvent assez basiques (calcul de tables temporaires, cache...).
Un autre bémol, plus petit toute fois, concernant le NoSQL.
C'est une approche très intéressante, qui effectivement de stocker de grandes quantités de données efficacement, et qui offre une souplesse de part son absence de schéma (pour la plupart).
En revanche, le changement de paradigme est assez fort pour quelqu'un qui a l'habitude de tables SQL. Notamment sur l'absence de liaisons, le besoin de redondance, et les problématiques de maintenance que ça implique, notamment dans le cas de données absentes/altérées.
Donc je ne démarrerais pas un projet en NoSQL si je n'avais pas d'expérience de mise en place de cette techno. En fait, si, je l'ai fait... et j'en ai payé les conséquences : problèmes de performances liés à une utilisation inefficace des liaisons entre des collections, nombreuses migrations pour ajouter de la redondance et avoir accès à ce qu'on veut,...
D'ailleurs si la plupart des projets sont réalisables en NoSQL, certains se retrouvent vraiment bloqués par le principe. Voici un exemple très intéressant (en anglais): www.sarahmei.com/blog/2013/11/11/why-you-should...
Encore plus grave, dans le sens "ne pas utiliser quelque chose qu'on ne connait pas", le cas de Flexcoin qui s'est fait hacker 896 bitcoins parce qu'ils ne maitrisaient pas l'aspect "sécurité" de MongoDB: hackingdistributed.com/2014/04/06/another-one-b...
Et enfin, avoir une "couche" qui utilise une techno différente, ça veut dire une configuration supplémentaire du serveur, de la RAM, du CPU une logique différente à avoir en tête,.... alors que l'on a déjà une techno qui fait le boulot (SQL ou logs).
@JulienStoeffler Merci pour ces précisions ! tu as entièrement raison. Mais n'ayant pas plus d'infos, que le IoT est souvent synonyme de GROS volumes... Mais tu as raison sur les mises en garde relatives à ces techno du Hadoop et NoSQL. Merci :)
@VincentLe : là, tu as un large spectre des possibilités et limites/contraintes :)
@VincentLe : là, tu as un large spectre des possibilités et limites/contraintes :)
@VincentLe concernant tes deux autres questions :
1- Sécurisation des requêtes: Ça dépend pas mal du contrôle que tu as: est-ce que tu maitrises le protocol de l'objet? Ou est-ce que tu passes par un réseau type Sigfox/FitBit/Nest,... ? Si tu maitrises, tu peux identifier l'objet comme tu le souhaites (PGP,...). Par contre ça n'empêcherait pas un "bad guy" de remplir ta base s'il a un objet valide. Pour se protéger de ça, tu peux limiter le nombre de requêtes/seconde, si tu sais qu'un objet renvoie la température toutes les secondes, tu peux facilement éliminer un objet qui en envoie 10 par seconde ou plus. Ensuite, tu peux aussi et surtout identifier les utilisateurs par compte (MDP/Password,...). Si tu passes par un réseau, tu auras probablement un système de sécurité à mettre en place, tu pourras t'assurer par ex que la requête vient bien de ce serveur.
Pour une réponse plus précise, il faudrait savoir ce que tu as à ta disposition, et qui sont tes acteurs (qui fabrique les objets, qui héberge les services,...). Tu peux poser une nouvelle question dans ce cas :)
2- Fermeture d'une question sur Skiller: une question reste toujours ouverte, au cas où quelqu'un aurait des éléments à apporter.
1- Sécurisation des requêtes: Ça dépend pas mal du contrôle que tu as: est-ce que tu maitrises le protocol de l'objet? Ou est-ce que tu passes par un réseau type Sigfox/FitBit/Nest,... ? Si tu maitrises, tu peux identifier l'objet comme tu le souhaites (PGP,...). Par contre ça n'empêcherait pas un "bad guy" de remplir ta base s'il a un objet valide. Pour se protéger de ça, tu peux limiter le nombre de requêtes/seconde, si tu sais qu'un objet renvoie la température toutes les secondes, tu peux facilement éliminer un objet qui en envoie 10 par seconde ou plus. Ensuite, tu peux aussi et surtout identifier les utilisateurs par compte (MDP/Password,...). Si tu passes par un réseau, tu auras probablement un système de sécurité à mettre en place, tu pourras t'assurer par ex que la requête vient bien de ce serveur.
Pour une réponse plus précise, il faudrait savoir ce que tu as à ta disposition, et qui sont tes acteurs (qui fabrique les objets, qui héberge les services,...). Tu peux poser une nouvelle question dans ce cas :)
2- Fermeture d'une question sur Skiller: une question reste toujours ouverte, au cas où quelqu'un aurait des éléments à apporter.
> architecture facilement scalable (si qqn a un mot français je suis preneur !)
Redimensionnable :)
Redimensionnable :)