Stockage de données pour les données de séries chronologiques

Question

J'ai quelques données de mesure scientifiques qui devraient être stockées de manière permanente dans un magasin de données quelconque.

Je cherche un moyen de stocker des mesures à partir de 100 000 capteurs avec des données de mesure accumulées sur plusieurs années jusqu'à environ 1 000 000 de mesures par capteur. Chaque capteur produit une lecture une fois par minute ou moins fréquemment. Ainsi, le flux de données n'est pas très important (environ 200 mesures par seconde dans le système complet). Les capteurs ne sont pas synchronisés.

Les données elles-mêmes sont des flux de triplets: [horodatage] [numéro de capteur] [valeur], où tout peut être représenté comme une valeur de 32 bits.

Dans la forme la plus simple, ce flux serait stocké tel quel dans une seule table à trois colonnes. Ensuite, la requête serait:

SELECT timestamp,value 
    FROM Data 
    WHERE sensor=12345 AND timestamp BETWEEN '2013-04-15' AND '2013-05-12' 
    ORDER BY timestamp 

Malheureusement, DBMS basés sur des lignes cela donne une très mauvaise performance, comme la masse de données est grande, et les données que nous voulons est dispersée de façon presque égale en elle. (Essayer de sélectionner quelques centaines de milliers d'enregistrements à partir de milliards d'enregistrements.) Ce dont j'ai besoin est un temps de réponse raisonnable pour la consommation humaine (les données seront représentées graphiquement pour un utilisateur), c'est-à-dire quelques secondes plus le transfert de données.

Une autre approche consisterait à stocker les données d'un capteur dans une table. Ensuite, la requête deviendrait:

SELECT timestamp,value 
    FROM Data12345 
    WHERE timestamp BETWEEN '2013-04-15' AND '2013-05-12' 
    ORDER BY timestamp 

Cela donnerait une bonne performance de lecture, le résultat serait un certain nombre de lignes consécutives d'une table relativement faible (généralement moins d'un million de lignes). Cependant, le SGBDR doit contenir 100 000 tables qui sont utilisées en quelques minutes seulement. Cela ne semble pas possible avec les systèmes communs. D'autre part, le SGBDR ne semble pas être le bon outil, car il n'y a pas de relations dans les données.

Je suis en mesure de démontrer qu'un seul serveur peut faire face à la charge en utilisant le système de mickeymouse suivant:

1. Chaque capteur a son propre fichier dans le système de fichiers.
2. Lorsqu'une donnée arrive, son fichier est ouvert, les données sont ajoutées et le fichier est fermé.
3. Les requêtes ouvrent le fichier respectif, trouvent les points de début et de fin des données et lisent toutes les données intermédiaires.

Très peu de lignes de code. Les performances dépendent du système (type de stockage, système de fichiers, système d'exploitation), mais il ne semble pas y avoir de gros obstacles. Cependant, si j'abandonne cette voie, je finis par écrire mon propre code pour le partitionnement, la sauvegarde, le déplacement des données plus anciennes dans le stockage (cloud), etc. Ensuite, cela ressemble à mon propre SGBD, qui sonne comme réinventer la roue (encore).

Existe-t-il un moyen standard de stocker le type de données dont je dispose? Un astucieux astuce NoSQL?

Answer 1

Semble vraiment un problème assez facile. 100 milliards d'enregistrements, 12 octets par enregistrement -> 1,2 To ce n'est même pas un gros volume pour les disques durs modernes. En LMDB, j'utiliserais une sous-DB par capteur. Ensuite, votre clé/valeur est juste un horodatage 32 bits/lecture de capteur 32 bits, et toutes vos récupérations de données seront de simples balayages de plage sur la clé.Vous pouvez facilement récupérer de l'ordre de 50M enregistrements/sec avec LMDB. (Voir les gars de SkyDB faisant juste cela https://groups.google.com/forum/#!msg/skydb/CMKQSLf2WAw/zBO1X35alxcJ)