Choix d'une base de données pour un flux continu de données [Résolu]

[achraf.b.a]

bonjour a tous ,

je travaille sur un projet de real time monitoring , je cherche à afficher les données envoyées par des capteurs qui sont placés sur des poutres pour mesurer la contrainte en MPa sur une interface web en utilisant une chart en javascript .
N'étant pas informaticien de formation j'ai opté pour la solution php +javascript vu la disponibilité de formation et de tutoriaux.

Côté base de données et vu que mes données seront générées en continu (je n'ai pas encore décidé si ça sera en continu ou à intervalles réguliers) je me demande si je doit utiliser mysql pour mes données statiques comme le numéro de la poutre et son emplacement, et utiliser une autre base de données comme une base xml native pour mes données dynamiques ou je dois coupler les 2 ?!

si mes données sont générées avec un intervalle de moins d'une seconde et que mysql ne prend pas en charge les millisecondes y a-t-il une solution pour contourner ça ou je dois choisir une autre base que mysql ?

merci d'avance pour votre aide !

[CinePhil]

Un SGBD est capable de traiter de nombreuses requêtes par seconde.

Tu dis que les données arrivent en continu mais le continu réel n'existe pas. Tu vas avoir un programme qui va lire les données envoyées par les capteurs puis les envoyer au SGBD pour le stockage. Le temps de cycle de cette opération sera le temps mini entre deux relevés de mesures.

Tu as deux processus possibles.

1) Lecture de tous les capteurs et stockage dans un tableau puis envoi en masse en une seule requête vers le SGBD.

2) Lecture d'un capteur, envoi au SGBD puis capteur suivant.

La première solution est à mon avis meilleure car cela limite le nombre de transactions vers le SGBD et il y a de fortes chances que la durée des opération de lecture et de stockage dans un tableau puis de construction de la requête soit plus rapide que le transfert vers le SGBD et le traitement de la requête par le SGBD, surtout avec l'augmentation du volume de données.

Pour que ce soit le plus rapide possible, porte une grande attention à la modélisation des données.

Bon courage.

[achraf.b.a]

Merci Cinephil pour vos suggestions

je suis dans la phase de modélisation je cherche maintenant d'investiguer sur tous les points qui peuvent me rencontrer pour ne pas avoir de mauvaises surprise
quand je commence la réalisation de mon projet ,comme début je vais me contenter d'un seul capteur mais je dois préparer l'infrastructure complète pour ajouter d'autres capteurs après .

-Vous avez mentionné que un sgbd peut faire plusieurs requêtes par seconde ,mais d’après ce que j'ai lu dans le forum mysql ne prend pas en charge les millisecondes ,
par exemple est-il possible de demander plusieurs valeurs d'une contrainte dans 1 seconde (t1=0.23 s ,t2=0.5s ....).

-Concernant le format des données qui sera envoyé à la base de données elle sera en quoi ?
est-il possible que la chart que je vais utiliser aura accès directement au données sans passer par la base de données ?


Merci infiniment

[CinePhil]

Envoyé par achraf.b.a

-Vous avez mentionnes que un sgbs peut faire plusieurs requêtes par seconde ,mais d’après ce que j'ai lu dans le forum mysql ne prend pas en charge les millisecondes ,
par exemple est il possible de demander plusieurs valeur d'une contrainte dans 1 seconde (t1=0.23 s ,t2=0.5s ....).

Effectivement, il semble que MySQL tronque les fractions de secondes (vraiment pas bon ce SGBD !).
Il faudra probablement stocker ces fractions de seconde dans une colonne séparée.
mesure (msr_id, msr_id_capteur, msr_date_heure, msr_fraction_de_seconde, msr_valeur)
Pourtant, dans la doc de MySQL sur les fonctions de date et heure, on y voit la notion de MICROSECOND !

-Concernant la format des données qui sera envoyer a la base de données elle sera en quoi ?

Tu enregistreras les données grâce à une requête SQL de ce type :

Code :

1
2
3
4
5
6
7
8
INSERT INTO mesure (msr_id_capteur, msr_date_heure, msr_fraction_de_seconde, msr_valeur)
VALUES 
	(1, '2011-11-19 09:04:00', 0, 825.12),
	(2, '2011-11-19 09:04:00', 0, 512.20),
	(3, '2011-11-19 09:04:00', 0, 748.35),
	(1, '2011-11-19 09:04:00', 25, 825.20),
	(2, '2011-11-19 09:04:00', 25, 512.08),
	(3, '2011-11-19 09:04:00', 25, 748.30)

Au programme qui génère la requête de préparer la requête avec le bon format de données.

est il possible que la chart que je vais utiliser aura accès directement au donnes sans passer par la base de données ?

Euh... la "chart" ? Je ne comprends pas la question.
Puisque les données seront enregistrées dans la BDD, il faudra un programme pour extraire les données de la BDD. Ce programme préparera des requêtes SELECT et les enverra au SGBD puis récupérera un jeu de résultats et le traitera.

Par exemple, quelles sont les valeurs mesurées de la poutre 1 entre 9h et 10h le 19 novembre 2011 ?

Code :

1
2
3
4
5
SELECT CONCAT(EXTRACT(HOUR_SECOND FROM msr_date_heure)) AS date_heure, msr_valeur
FROM mesure
WHERE msr_id_poutre = 1
        AND msr_date_heure BETWEEN '2011-11-19 09:00:00' AND '2011-11-19 09:59:59'
	AND msr_fraction_de_seconde BETWEEN 0 AND 999

[achraf.b.a]

Merci Cinephil encore une fois ,

vous m'avez donné une grande idée ,mais je suis loin de comprendre tout pour le moment .
je voulais dire par la chart , la bibliothèque graphique en javascript qui affichera mes données sous formes d'un graphe dynamique Highchart

[SQLpro]

Si vos données doivent être insérées en continu et que vous n'avez pas de moyen de rétention des données à insérer il faut penser à utiliser un mécanisme de haute disponibilité du serveur afin d'assurer un service continu des données, même en cas de panne. Il faut donc un système fonctionnant 24h/24 7j/7 avec un temps de dispo de 99.999% soit au plus 5 minutes par an d'indisponibilité...
Pour cela il faut disposer de fonction de clusterisation physique ou bien de mirroring avec basculement automatique.
Il faut en sus que toutes les opérations de maintenance puissent être fait à chaud et sans blocage.
Ceci exclu donc MySQL qui ne sait même pas faire des sauvegarde consistantes à chaud et même PostGreSQL dans lequel certains opérations de maintenance (notamment celle concernant les index) sont bloquantes.

Reste donc MS SQL Server, IBM DB2, Sybase ASE et Oracle. Le moins cher étant de loin MS SQL Server.

A +

[achraf.b.a]

Envoyé par SQLpro

Si vos données doivent être insérées en continu et que vous n'avez pas de moyen de rétention des données à insérer

Merci SQLpro

si ce n'est pas le cas et que j'ai un moyen de rétention de données est ce que ça me facilitera la tache ? en stockant les données sous forme xml par exemple et la base mysql se mettra a jour via ce fichier xml .

merci

[SQLpro]

Envoyé par achraf.b.a

si ce n'est pas le cas et que j'ai un moyen de rétention de données est ce que ça me facilitera la tache ?

Soyez sur que votre moyen soit fiable... C'est rarement le cas des fichiers (corruption aisées). Alors que l'avantage des SGBDR est d'être beaucoup plus fiable du fait de la journalisation des transactions et des outils de reconstruction des données corrompues, donc des moyens de récupérer vos données même en cas de panne sévères...
Bien entendu ceci n'existe quasiement pas sous MySQL qui est un ersatz de SGBDR. A lire sur le sujet : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

[achraf.b.a]

Merci bien pour vos suggestions