bonne base de données (noSQL?) Pour les mesures physiques

Question

Nous construisons un système de mesure qui comprendra éventuellement des milliers de stations de mesure. Chaque station économisera environ 500 millions de mesures comprenant 30 valeurs scalaires sur sa durée de vie. Ce seront des valeurs flottantes. Nous sommes maintenant demander comment enregistrer ces données sur chaque station, étant donné que nous allons construire une application web sur chaque station telle que

• nous voulons visualiser les données sur plusieurs échelles de temps (par exemple, des mesures d'une semaine, mois, année)
• nous avons besoin de construire des moyennes mobiles sur les données (par exemple, en moyenne plus d'un mois pour montrer dans un graphique de l'année)
• la base de données doit être collision résistant (coupures de courant)
• nous faisons seulement écrit et lit, pas de mise à jour ou de suppression sur les données

En outre, nous aimerions un serveur de plus qui peut afficher les données de, disons, 1000 stations de mesure. Ce serait ~ 50TB de données dans 500 milliards de mesures. Pour transmettre les données de la station de mesure au serveur, j'ai pensé qu'un certain type de réplication au niveau base de données serait un moyen propre et efficace.

Maintenant, je me demande si une solution noSQL pourrait être meilleure que mySQL à ces fins. Surtout couchDB, Cassandra et peut-être des magasins de valeur-clé comme Redis regarder attrayant pour moi. Laquelle de celles-ci conviendrait le mieux au modèle de données "série chronologique de mesure" selon vous? Qu'en est-il d'autres avantages tels que la sécurité en cas de panne et la réplication de la station de mesure au serveur principal?

Answer 1

Je pense que CouchDB est une excellente base de données - mais sa capacité à traiter de grandes quantités de données est discutable. L'objectif principal de CouchDB est la simplicité du développement et la réplication hors ligne, pas nécessairement sur les performances ou l'évolutivité. CouchDB lui-même ne prend pas en charge le partitionnement, vous serez donc limité par la taille maximale du nœud, sauf si vous utilisez BigCouch ou inventez votre propre schéma de partitionnement.

Aucune erreur, Redis est une base de données en mémoire. Il est extrêmement rapide et efficace pour obtenir des données dans et hors de la RAM. Il a la capacité d'utiliser le disque pour le stockage, mais ce n'est pas très bon. C'est idéal pour les quantités limitées de données qui changent fréquemment. Redis a une réplication, mais n'a pas de support intégré pour le partitionnement, encore une fois, vous serez seul ici.

Vous avez également mentionné Cassandra, qui je pense est plus sur la cible pour votre cas d'utilisation. Cassandra est bien adapté pour les bases de données qui se développent indéfiniment, essentiellement son cas d'utilisation original. Le partitionnement et la disponibilité sont cuits afin que vous n'ayez pas à vous en soucier beaucoup. Le modèle de données est également un peu plus flexible que le magasin de clés/valeurs moyen, en ajoutant une deuxième dimension de colonnes, et peut pratiquement accueillir des millions de colonnes par ligne. Cela permet aux données de séries chronologiques d'être "compartimentées" en lignes couvrant des plages de temps, par exemple. La distribution des données à travers le cluster (partitionnement) est effectuée au niveau de la ligne, de sorte qu'un seul nœud est nécessaire pour effectuer des opérations dans une ligne. Hadoop se connecte directement à Cassandra, avec des «drivers natifs» pour MapReduce, Pig et Hive, ce qui pourrait potentiellement être utilisé pour agréger les données collectées et matérialiser les moyennes en cours. La meilleure pratique consiste à façonner les données autour des requêtes, donc probablement vouloir stocker plusieurs copies des données dans le formulaire "dénormalisé", un pour chaque type de requête.

Vérifiez ce post à faire des séries chronologiques dans Cassandra:

http://rubyscale.com/2011/basic-time-series-with-cassandra/

Answer 2

Je tends à avoir peur des bases de données tous ensemble pour des données très structurées de cette nature (série temporelle de vecteurs de flotteur). La plupart des fonctionnalités d'une base de données ne sont pas très intéressantes; vous n'êtes fondamentalement pas intéressé par des choses comme l'atomicité ou la sémantique transactionnelle. La seule caractéristique que est souhaitable est la résilience à l'écrasement. Cette fonctionnalité, cependant, est trivialement facile à mettre en œuvre lorsque vous n'avez pas besoin de annuler une écriture (pas de mises à jour/suppressions), juste en ajoutant à un fichier. la récupération après un crash est simple; ouvrir un nouveau fichier avec un numéro de série incrémenté dans le nom de fichier.

Un format logique pour ceci est plaine-vieille csv. après chaque mesure, appelez flush() sur le file sous-jacent. Obtenir les données répliquées sur le serveur central est un travail efficacement résolu par rsync(1). Vous pouvez ensuite importer les données dans l'outil d'analyse de votre choix.

Answer 3

Je voudrais persisterally loin des fichiers "csv" et "texte en clair". Ils sont pratiques lorsque vous avez un faible volume et que vous souhaitez ignorer les outils pour regarder rapidement les données ou apporter de légères modifications aux données.

Quand vous parlez de "50Tb" de données, c'est beaucoup. Si une simple astuce réduit ce facteur d'un facteur de deux, cela se traduira par des coûts de stockage et des frais de bande passante.

Si les mesures sont prises régulièrement, cela signifie qu'au lieu de sauvegarder l'horodatage à chaque mesure, vous stockez l'heure et l'intervalle de début et enregistrez simplement les mesures.

Je choisirais un format de fichier qui a un petit en-tête et puis juste un tas de mesures en virgule flottante. Pour éviter que les fichiers deviennent très volumineux, choisissez une taille de fichier maximale. Si vous initialisez le fichier en l'écrivant entièrement avant de commencer à utiliser le fichier, il sera entièrement alloué sur le disque au moment où vous commencerez à l'utiliser. Maintenant, vous pouvez mmap le fichier et modifier les données. Si le courant diminue lorsque vous modifiez les données, il est tout simplement sur le disque ou pas.