Je recherche un moyen de stocker des données avec un horodatage.
Chaque horodatage peut avoir 1 à 10 champs de données. p>
puis-je stocker des données comme Il stockera Environ 10 points de données avec max autour de 10 champs par seconde. Et les données peuvent être collectées aussi longtemps que 10 ans, agrégant facilement des enregistrements Il devrait être capable de gérer une fréquence d'écriture lourde, ~ 100 par seconde (OK, ce n'est pas si élevé, mais toujours ..), Dans le même temps, être capable de gérer les requêtes qui renvoient environ un million d'enregistrements (peut-être encore plus) p> Data Soi est très simple, ce ne sont que des mesures électroniques. Certains doivent être mesurés avec une fréquence élevée (environ 100 millisecondes) et d'autres tous les 1 minute environ. P> Peut-être que quiconque a utilisé quelque chose comme ce commentaire sur les plus et les minus de la méthode qu'ils utilisaient? (évidemment, il s'agit d'un scénario très spécifique, donc cela n'est donc pas destiné à se transformer en quelle est la meilleure solution de base de données de base de données). p> échantillon Data: P> (heure, clé, valeur) code> à l'aide d'une solution de données simple ou de SQL? Comment cela se comparerait-il à la solution NosqL comme Mongo, où je peux stocker {TIME: .., Key1: ..., Key2: ...} code>? P> { _id: Date(2013-05-08 18:48:40.078554),
V_in: 2.44,
I_in: .00988,
I_max: 0.11,
},
{_id: Date(2013-05-08 18:48:40.078325),
I_max: 0.100,
},
{ _id: Date(2001-08-09 23:48:43.083454),
V_out: 2.44,
I_in: .00988,
I_max: 0.11,
},
3 Réponses :
Pour la simplicité, je ferais simplement une table d'horodatage avec une colonne pour chaque point de mesure et une clé primaire entière serait techniquement redondante puisque l'horodatage identifie de manière unique un point de mesure, mais il est plus facile de faire référence à une rangée particulière par nombre que par horodatage. Vous aurez des nuls pour tout paramètre mesuré qui n'a pas été pris pendant cet horodatage, qui prendra quelques bits supplémentaires par rangée (base de journal 2 du nombre de colonnes, arrondi), mais vous n'aurez pas non plus à faire de jointures. . Il est vrai que si vous décidez que vous souhaitez ajouter des colonnes plus tard, mais ce n'est pas vraiment trop difficile, et vous pourriez simplement faire une autre table séparée qui clavier sur celui-ci.
S'il vous plaît voir ici pour un exemple avec vos données: http: //www.sqlfiddle. com / #! 2 / E967C / 4
Je recommanderais de faire quelques bases de données factices de grande taille pour vous assurer que toute la structure que vous utilisez est toujours suffisamment utilisée.
Le (heure, clé, valeur) suggestion sent comme EAV , que j'éviterais si vous envisagez de mettre l'accent.
Découvrez quelques bases de données de la série TIME:
logiciel installé
services
Autres qui pourraient valoir un look:
Vos points de mesure ont-ils des relations? Les horodatages sont-ils uniques à la mesure ou de multiples mesures (de différents paramètres) ont-ils exactement le même horodatage? Quelle est la résolution de l'horodatage requis (millisecondes, microsecondes, etc.)?
freq. OF TIMESTAMP ~ 100MILLIS, et la planification d'utilisation d'horodatage comme ID unique si possible (NOSQL) Je vais mettre à jour la question.