Stockage de données de séries temporelles, relationnel ou non ?

Question

Je suis en train de créer un système qui interroge les périphériques pour obtenir des données sur diverses métriques telles que l'utilisation du CPU, l'utilisation du disque, la température, etc. à des intervalles de 5 minutes (probablement) en utilisant SNMP. Le but ultime est de fournir des visualisations à un utilisateur du système sous la forme de graphiques de séries temporelles.

J'ai envisagé d'utiliser RRDTool dans le passé, mais je l'ai rejeté car le stockage indéfini des données capturées est important pour mon projet, et je veux un accès de plus haut niveau et plus souple aux données capturées. Ma question est donc la suivante :

Qu'est-ce qui est le 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 de données pour la création de graphiques.

Relationnel

Dans le cas d'une base de données relationnelle, j'utiliserais un fichier data_instances dans lequel serait stocké chaque instance de données capturées pour chaque métrique mesurée pour tous les dispositifs, avec les champs suivants :

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 filtrage les autres appareils, et les autres paramètres analysés 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

donde d est le nombre de dispositifs , m_d est le cumulatif nombre de mesures en cours d'enregistrement pour tous les appareils, f est le fréquence à laquelle les données sont recherchées et t est le montant total de temps le système a collecté des données.

Pour un utilisateur enregistrant 10 mesures pour 3 appareils toutes les 5 minutes pendant un an, nous aurions un peu moins de 5 millions les dossiers.

Indices

Sans index sur fk_to_device y fk_to_metric Le balayage de ce tableau en constante expansion prendrait trop de temps. Ainsi, l'indexation des champs mentionnés ci-dessus et aussi timestamp (pour créer des graphiques avec des périodes localisées) est une exigence.

Non-rationnel (NoSQL)

MongoDB a le concept d'un collection Contrairement aux tables, celles-ci peuvent être créées par programme, sans configuration. Avec ceux-ci, 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 des systèmes NoSQL et je ne sais pas s'ils offrent des fonctions d'amélioration de la performance des requêtes telles que l'indexation, mais le paragraphe précédent propose de faire la plupart du travail traditionnel de requête relationnelle 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 à l'état d'un crawl dans l'année ? Ou la structure basée sur les collections des approches NoSQL (qui correspond à mon modèle mental des données stockées) offre-t-elle un avantage notable ?

Answer 1

Définitivement relationnel. Flexibilité et expansion illimitées.

Deux corrections, tant au niveau du concept que de l'application, suivies d'une élévation.

Correction

1. Il ne s'agit pas de "filtrer les données inutiles", mais de en sélectionnant uniquement 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 1 000 lignes dans une table de 16 milliards de lignes est instantané).

2. Votre table a un sérieux empêchement. D'après votre description, le PK réel est (Device, Metric, DateTime). (Ne l'appelez pas TimeStamp, cela signifie autre chose, mais c'est un problème mineur). L'unicité de la rangée est identifié par :

      (Device, Metric, DateTime)

   • El Id La colonne ne fait rien, elle est totalement et complètement redondante.

     • Un site Id n'est jamais une clé (les lignes dupliquées, qui sont interdites dans une base de données relationnelle, doivent être empêchées par d'autres moyens).

     • El Id nécessite un index supplémentaire, ce qui entrave évidemment la rapidité d'exécution de l'opération. INSERT/DELETE et s'ajoute à l'espace disque utilisé.

     • Vous pouvez vous en débarrasser. S'il vous plaît.

Élévation

1. Maintenant que vous avez supprimé l'obstacle, vous ne l'avez peut-être pas reconnu, mais votre table est en forme de Sixième Normale. Une vitesse très élevée, avec un seul index sur le PK. Pour comprendre, lisez cette réponse de la Qu'est-ce que la sixième forme normale ? en cours.

   • (Je n'ai qu'un seul index, pas trois ; sur les Non-SQLs vous pouvez avoir besoin de trois index).

   • J'ai exactement le même tableau (sans le Id "clé", bien sûr). J'ai une colonne supplémentaire Server . Je soutiens plusieurs clients à distance.

     (Server, Device, Metric, DateTime)

   Le tableau peut être utilisé pour faire pivoter les données (c'est-à-dire que le tableau peut être utilisé pour faire pivoter les données). Devices en haut et Metrics sur le côté, ou pivoté) en utilisant exactement le même code SQL (oui, permutez les cellules). J'utilise le tableau pour créer une variété illimitée de graphiques et de diagrammes pour les clients concernant les performances de leur serveur.

   • Modèle de données des statistiques du moniteur .
     (Trop grand pour être affiché en ligne ; certains navigateurs ne peuvent pas le charger en ligne ; cliquez sur le lien. Il s'agit également de la version de démonstration obsolète, pour des raisons évidentes, je ne peux pas vous montrer le produit commercial DM).

   • Il me permet de produire Des graphiques comme celui-ci six frappes après avoir reçu un fichier de statistiques de surveillance brut du client, en utilisant un logiciel de gestion des données. commande SELECT unique . Remarquez le mélange des genres ; 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 de graphiques. (Utilisé avec l'aimable autorisation du client).

   • Les lecteurs qui ne sont pas familiers avec la Norme de modélisation des bases de données relationnelles peuvent trouver que la Notation IDEF1X utile.

Une dernière chose

Enfin et surtout, SQL est une norme IEC/ISO/ANSI. Les logiciels gratuits sont en fait des logiciels 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.

Answer 2

J'ai trouvé très intéressantes les réponses ci-dessus. J'essaie d'ajouter quelques considérations supplémentaires ici.

1) Vieillissement des données

La gestion des séries chronologiques nécessite généralement de créer des politiques de vieillissement. Un scénario typique (par exemple, la surveillance du CPU d'un serveur) nécessite de stocker :

• 1 seconde échantillons bruts pendant une courte période (par exemple pendant 24 heures)

• 5 minutes détailler les échantillons d'agrégats pour une période moyenne (par exemple 1 semaine)

• 1 heure détail au-delà (par exemple, jusqu'à 1 an)

Bien que les modèles relationnels permettent à coup sûr (ma société a mis en place des bases de données centralisées massives pour certains gros clients avec des dizaines de milliers de séries de données) de gérer ces données de manière appropriée, la nouvelle race de magasins de données ajoute des fonctionnalités intéressantes à explorer, comme par exemple :

• purge automatique des données (voir la commande EXPIRE de Redis)

• agrégations multidimensionnelles (par exemple, tâches map-reduce à 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, ce qui pourrait poser problème avec les SGBDR en raison de la création de points chauds (gestion de l'indexation tout en insérant dans une seule table). Ce problème dans l'espace SGBDR est généralement résolu en revenant à des procédures d'importation par lots (nous l'avons géré de cette façon dans le passé), alors que les technologies non SQL ont réussi à collecter et à agréger massivement des données en temps réel (voir Splunk par exemple, mentionné dans les réponses précédentes).

Answer 3

Votre table a des données dans une seule table. Donc, relationnel ou non relationnel n'est pas la question. Fondamentalement, vous avez besoin de lire un grand nombre de données séquentielles. Maintenant, si vous avez assez de RAM pour stocker des données valant des années, alors rien ne vaut l'utilisation de Redis/MongoDB, etc.

La plupart des bases de données NoSQL stockent vos données au même endroit sur le disque et sous forme compressée pour éviter les accès multiples au disque.

NoSQL fait la même chose que de créer l'index sur l'id du dispositif et l'id de la métrique, mais à sa manière. Avec une base de données, même si vous faites cela, l'index et les données peuvent se trouver à des endroits différents et il y aurait beaucoup d'entrées-sorties sur le disque.

Des outils comme Splunk utilisent des backends NoSQL pour stocker des données de séries temporelles et utilisent ensuite map reduce pour créer des agrégats (ce qui pourrait être ce que vous voulez plus tard). Donc, à mon avis, l'utilisation de NoSQL est une option car des gens l'ont déjà essayé pour des cas d'utilisation similaires. Mais est-ce qu'un million de lignes va faire ramper la base de données (peut-être pas, avec un matériel décent et des configurations appropriées).

Answer 4

Si vous cherchez des paquets GPL, RRDTool est un bon point de vue. Il s'agit d'un bon outil pour le stockage, l'extraction et la représentation graphique de données de séries chronologiques. Votre cas d'utilisation ressemble exactement à des données de séries temporelles.

Answer 5

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. Ce système n'existe pas depuis très longtemps, mais il s'avère efficace.

J'ai aussi utilisé RRDTool pour un autre projet qui était excellent.