Je crée un système qui interroge les périphériques pour des données sur des métriques variables telles que l'utilisation du processeur, l'utilisation du disque, la température, etc. à (probablement) 5 minutes d'intervalle en utilisant SNMP. Le but ultime est de fournir des visualisations à un utilisateur du système sous la forme de graphiques chronologiques.
J'ai envisagé d'utiliser RRDTool dans le passé, mais je l'ai rejeté car le stockage des données capturées indéfiniment est important pour mon projet, et je souhaite un accès de plus haut niveau et plus flexible aux données capturées. Donc ma question est vraiment:
Quoi de mieux, une base de données relationnelle (comme MySQL ou PostgreSQL) ou une base de données non relationnelle ou NoSQL (comme MongoDB ou Redis) en ce qui concerne les performances lors de l'interrogation des données pour la représentation graphique.
Relationnel
Étant donné une base de données relationnelle, j'utiliserais une data_instances
table dans laquelle serait stockée chaque instance de données capturées pour chaque métrique mesurée pour tous les appareils, avec les champs suivants:
Des champs: id
fk_to_device
fk_to_metric
metric_value
timestamp
Lorsque je veux dessiner un graphique pour une métrique particulière sur un appareil particulier, je dois interroger cette table singulière en filtrant les autres appareils et les autres métriques en cours d'analyse pour cet appareil:
SELECT metric_value, timestamp FROM data_instances
WHERE fk_to_device=1 AND fk_to_metric=2
Le nombre de lignes dans ce tableau serait:
d * m_d * f * t
où d
est le nombre d' appareils , m_d
est le nombre cumulé de métriques enregistrées pour tous les appareils, f
est la fréquence à laquelle les données sont interrogées et t
est la durée totale pendant laquelle le système a collecté des données.
Pour un utilisateur enregistrant 10 métriques pour 3 appareils toutes les 5 minutes pendant un an, nous aurions un peu moins de 5 millions d' enregistrements.
Index
Sans index fk_to_device
et sans fk_to_metric
analyse, cette table en expansion continue prendrait trop de temps. Ainsi, l'indexation des champs susmentionnés et également timestamp
(pour créer des graphiques avec des périodes localisées) est une exigence.
Non relationnel (NoSQL)
MongoDB a le concept d'une collection , contrairement aux tables, celles-ci peuvent être créées par programme sans configuration. Avec ces derniers, je pourrais partitionner le stockage des données pour chaque appareil, ou même chaque métrique enregistrée pour chaque appareil.
Je n'ai aucune expérience avec NoSQL et je ne sais pas s'ils fournissent des fonctionnalités améliorant les performances des requêtes telles que l'indexation, mais le paragraphe précédent propose de faire la plupart du travail de requête relationnelle traditionnel dans la structure par laquelle les données sont stockées sous NoSQL.
Indécis
Une solution relationnelle avec une indexation correcte se réduirait-elle à une exploration dans l'année? Ou la structure basée sur la collection des approches NoSQL (qui correspond à mon modèle mental des données stockées) offre-t-elle un avantage notable?
la source
Réponses:
Certainement relationnel. Flexibilité et expansion illimitées.
Deux corrections, à la fois dans le concept et dans l'application, suivies d'une élévation.
Correction
Il ne s'agit pas de "filtrer les données inutiles"; il ne sélectionne que les données nécessaires. Oui, bien sûr, si vous avez un index pour prendre en charge les colonnes identifiées dans la clause WHERE, c'est très rapide et la requête ne dépend pas de la taille de la table (saisir 1000 lignes d'une table de 16 milliards de lignes est instantané) .
Votre table a un obstacle sérieux. Compte tenu de votre description, le PK réel est (Device, Metric, DateTime). (Veuillez ne pas l'appeler TimeStamp, cela signifie autre chose, mais c'est un problème mineur.) L'unicité de la ligne est identifiée par:
La
Id
colonne ne fait rien, elle est totalement et totalement redondante.Id
colonne n'est jamais une clé (les lignes en double, qui sont interdites dans une base de données relationnelle, doivent être évitées par d'autres moyens).La
Id
colonne nécessite un index supplémentaire, ce qui entrave évidemment la vitesse deINSERT/DELETE
et ajoute à l'espace disque utilisé.Vous pouvez vous en débarrasser. S'il vous plaît.
Élévation
Maintenant que vous avez supprimé l'obstacle, vous ne l'avez peut-être pas reconnu, mais votre table est en sixième forme normale. Très haute vitesse, avec un seul index sur le PK. Pour comprendre, lisez cette réponse dans Qu'est-ce que la sixième forme normale? aller de l'avant.
(J'ai un seul index, pas trois; sur les non-SQL, vous aurez peut-être besoin de trois index).
J'ai exactement la même table (sans la
Id
"clé", bien sûr). J'ai une colonne supplémentaireServer
. J'assiste plusieurs clients à distance.(Server, Device, Metric, DateTime)
Le tableau peut être utilisé pour faire pivoter les données (c.-à-d. En
Devices
haut et enMetrics
bas sur le côté, ou pivoter) en utilisant exactement le même code SQL (oui, changer les cellules). J'utilise le tableau pour dresser une variété illimitée de graphiques et de tableaux pour les clients concernant les performances de leur serveur.Surveiller le modèle de données statistiques .
(Trop volumineux pour l'inline; certains navigateurs ne peuvent pas se charger en ligne; cliquez sur le lien. C'est également la version démo obsolète, pour des raisons évidentes, je ne peux pas vous montrer le produit commercial DM.)
Cela me permet de produire des graphiques comme celui-ci , six frappes après avoir reçu un fichier de statistiques de surveillance brutes du client, en utilisant une seule commande SELECT . Remarquez le mix-and-match; OS et serveur sur le même graphique; une variété de pivots. Bien sûr, il n'y a pas de limite au nombre de matrices de statistiques, et donc aux graphiques. (Utilisé avec l'aimable autorisation du client.)
Les lecteurs qui ne sont pas familiarisés avec la norme pour la modélisation des bases de données relationnelles peuvent trouver la notation IDEF1X utile.
Encore une chose
Enfin, SQL est une norme CEI / ISO / ANSI. Le logiciel gratuit est en fait non SQL; il est frauduleux d'utiliser le terme SQL s'ils ne fournissent pas la norme. Ils peuvent fournir des "extras", mais ils sont absents des bases.
la source
Id
colonnes sont utilisées, comme "clés". Comme conseillé par les "théoriciens".J'ai trouvé très intéressantes les réponses ci-dessus. Essayer d'ajouter quelques considérations supplémentaires ici.
1) Vieillissement des données
La gestion des séries chronologiques doit généralement créer des politiques de vieillissement. Un scénario typique (par ex. CPU du serveur de surveillance) nécessite de stocker:
Échantillons bruts d'une seconde pendant une courte période (par exemple pendant 24 heures)
Échantillons agrégés détaillés de 5 minutes pour une période moyenne (par exemple 1 semaine)
Détails d'une heure sur cela (par exemple jusqu'à 1 an)
Bien que les modèles relationnels permettent à coup sûr (mon entreprise a mis en œuvre des bases de données centralisées massives pour certains gros clients avec des dizaines de milliers de séries de données) de la gérer de manière appropriée, la nouvelle génération de magasins de données ajoute des fonctionnalités intéressantes à explorer comme:
purge automatisée des données (voir la commande EXPIRE de Redis)
agrégations multidimensionnelles (par exemple, les tâches de réduction de carte a-la-Splunk)
2) Collecte en temps réel
Plus important encore, certains magasins de données non relationnels sont intrinsèquement distribués et permettent une collecte de données en temps réel (ou quasi-réel) beaucoup plus efficace qui pourrait poser problème avec le SGBDR en raison de la création de hotspots (gestion de l'indexation lors de l'insertion dans une seule table). Ce problème dans l'espace SGBDR est généralement résolu en revenant aux procédures d'importation par lots (nous l'avons géré de cette manière dans le passé) tandis que les technologies no-sql ont réussi à collecter et à agréger massivement en temps réel (voir Splunk par exemple, mentionné dans les réponses précédentes) .
la source
Votre table contient des données dans une seule table. Donc, relationnel vs non relationnel n'est pas la question. Fondamentalement, vous devez lire beaucoup de données séquentielles. Maintenant, si vous avez suffisamment de RAM pour stocker des données valant des années, rien de tel que d'utiliser Redis / MongoDB, etc.
La plupart des bases de données NoSQL stockeront vos données au même emplacement sur le disque et sous forme compressée pour éviter les accès multiples au disque.
NoSQL fait la même chose que la création de l'index sur l'identifiant de l'appareil et l'identifiant de la métrique, mais à sa manière. Avec la base de données, même si vous faites cela, l'index et les données peuvent être à des endroits différents et il y aurait beaucoup d'E / S disque.
Des outils tels que Splunk utilisent des backends NoSQL pour stocker des données de séries chronologiques, puis utilisent la réduction de carte pour créer des agrégats (ce que vous voudrez peut-être plus tard). Donc, à mon avis, utiliser NoSQL est une option car les gens l'ont déjà essayé pour des cas d'utilisation similaires. Mais un million de lignes amèneront-elles la base de données à explorer (peut-être pas, avec un matériel décent et des configurations appropriées).
la source
Créez un fichier, nommez-le 1_2.data. idée bizarre? ce que vous obtenez:
=> Les requêtes par horodatage fonctionnent incroyablement vite car vous pouvez utiliser la recherche binaire pour trouver le bon endroit dans le fichier à lire.
si vous l'aimez encore plus optimisé, commencez à penser à diviser vos fichiers comme ça;
ou utilisez kdb + de http://kx.com car ils font tout cela pour vous :) orienté colonnes est ce qui peut vous aider.
Une solution orientée colonnes basée sur le cloud apparaît, vous pouvez donc jeter un œil à: http://timeseries.guru
la source
Si vous recherchez des packages GPL, RRDTool est un bon outil à examiner. C'est un bon outil pour stocker, extraire et représenter graphiquement des données chronologiques. Votre cas d'utilisation ressemble exactement à des données de séries chronologiques.
la source
C'est un problème que nous avons dû résoudre chez ApiAxle. Nous avons rédigé un article de blog sur la façon dont nous l'avons fait en utilisant Redis. Il n'existe pas depuis très longtemps, mais il s'avère efficace.
J'ai également utilisé RRDTool pour un autre projet qui était excellent.
la source
Je pense que la réponse à ce genre de question devrait principalement concerner la manière dont votre base de données utilise le stockage. Certains serveurs de base de données utilisent la RAM et le disque, certains utilisent uniquement la RAM (éventuellement le disque pour la persistance), etc. Les solutions SQL Database les plus courantes utilisent la mémoire + le stockage sur disque et écrivent les données dans une disposition basée sur les lignes (chaque brut inséré est écrit dans le même emplacement physique). Pour les magasins de séries temporelles, dans la plupart des cas, la charge de travail est quelque chose comme: Intervalle relativement faible de quantité massive d'insertions, tandis que les lectures sont basées sur des colonnes (dans la plupart des cas, vous voulez lire une plage de données à partir d'une colonne spécifique, représentant une métrique)
J'ai trouvé que les bases de données en colonnes (google it, vous trouverez MonetDB, InfoBright, parAccel, etc.) font un travail formidable pour les séries chronologiques.
Quant à votre question, qui personnellement je pense est quelque peu invalide (comme toutes les discussions utilisant le terme d'erreur NoSQL - IMO): vous pouvez utiliser un serveur de base de données qui peut parler SQL d'une part, ce qui vous simplifie la vie car tout le monde connaît SQL pour beaucoup ans et ce langage a été perfectionné à maintes reprises pour les requêtes de données; mais utilisez toujours la RAM, le cache du processeur et le disque de manière orientée colonnes, ce qui rend votre solution la mieux adaptée aux séries chronologiques
la source
5 millions de lignes ne sont rien pour les données torrentielles d'aujourd'hui. Attendez-vous à ce que les données soient dans le TB ou le PB dans quelques mois seulement. À ce stade, le SGBDR ne s'adapte pas à la tâche et nous avons besoin de l'évolutivité linéaire des bases de données NoSql. Les performances seraient atteintes pour la partition en colonnes utilisée pour stocker les données, en ajoutant plus de colonnes et moins de lignes de concept pour améliorer les performances. Tirez parti du travail Open TSDB effectué par-dessus HBASE ou MapR_DB, etc.
la source
Je suis régulièrement confronté à des exigences similaires et j'ai récemment commencé à utiliser Zabbix pour collecter et stocker ce type de données. Zabbix a sa propre capacité graphique, mais il est assez facile d'extraire les données de la base de données de Zabbix et de les traiter comme vous le souhaitez. Si vous n'avez pas encore vérifié Zabbix, cela vaut peut-être la peine de le faire.
la source
Vous devriez regarder dans la base de données de séries chronologiques . Il a été créé dans ce but.
Exemple populaire de base de données de séries chronologiques InfluxDB
la source