Suggestions de base de données pour les séries chronologiques d'événements

Question

Pour l'un de mes projets, je dois entrer une grande collection d'événements dans une base de données pour traitement ultérieur et j'essaie de déterminer quel SGBD serait le mieux adapté à mon objectif.

J'ai:

• À propos 400000000 événements discrets au moment

• Environ 600 Go de données qui seront stockées dans la DB

Ces événements viennent dans une variété de formats, mais j'estime le nombre d'attributs individuels à environ 5000. La plupart des événements contiennent uniquement des valeurs pour environ 100 attributs chacun. Les valeurs d'attribut doivent être traitées comme des chaînes arbitraires et, dans certains cas, des entiers.

Les événements seront éventuellement consolidés en une seule série chronologique. Bien qu'ils aient une structure interne, il n'y a aucune référence à d'autres événements, ce qui - je crois - signifie que je n'ai pas besoin d'un DB objet ou d'un système ORM.

Mes besoins:

• licence open source - je dois ruser un peu.

• Évolutivité en étant capable de s'étendre à plusieurs serveurs, même si un seul système sera utilisé au début.

• Requêtes rapides - les mises à jour ne sont pas si critiques.

• Pilotes/fixations matures pour C/C++, Java et Python. Préférentiellement avec une licence qui joue bien avec les autres - je préfère ne pas m'engager à quelque chose à cause d'une décision technique. Je pense que la plupart des drivers DB n'ont pas de problème ici, mais il faut quand même le mentionner.

• Disponibilité pour Linux.

• Ce serait bien, mais pas nécessaire, si elle était également disponible pour Windows

Mon DB idéal pour cela me permettra de récupérer tous les événements d'une période de temps spécifiée avec une seule requête .

Ce que j'ai trouvé/considéré jusqu'à présent:

• Postgresql avec une taille de page accrue peut apparemment avoir jusqu'à 6000 colonnes dans chaque tableau. Si mon estimation du nombre d'attributs n'est pas désactivée, cela pourrait le faire.

• MySQL semble avoir une limite de 4000 colonnes par table. Je pourrait utiliser plusieurs tables avec un peu de SQL-fu, mais je préfère ne pas.

• MongoDB est ce que je suis actuellement pencher vers. Cela me permettrait de préserver la structure interne des événements, tout en étant capable de les interroger. Son API semble également assez simple.Je n'ai aucune idée de la qualité des performances, du moins sur un seul serveur. Et son cadre de collecte de métriques semble intéressant.Je pourrais utiliser une seule série chronologique pour chaque attribut (ce qui pourrait aider avec un peu de mon traitement), avoir la valeur de l'attribut comme une étiquette et en plus marquer les entrées pour les associer à un événement spécifique. Il a probablement une courbe de préparation plus raide que les trois ci-dessus, à la fois d'un point de vue administrateur et un programmeur d'applications. Aucune idée de sa performance.

• Utilisez directement HBase. Cela pourrait mieux répondre à mes exigences que OpenTSDB, bien que - d'après mon expérience passée avec hadoop - les frais généraux d'administration sont probablement encore plus élevés que les trois premières options.

Il y a probablement d'autres bases de données qui pourraient le faire, alors ne hésitez pas à me le faire savoir - Je vous serais reconnaissant toute suggestion ou commentaire qui pourrait me aider. PS: J'ai seulement une expérience minimale en tant qu'administrateur DB, donc je m'excuse pour toute idée fausse.

Answer 1

L'utilisation de tables avec des milliers de colonnes est une folie. Surtout quand la plupart d'entre eux sont à zéro comme vous l'avez dit.

Vous devez d'abord regarder dans la conversion de votre structure de données de cette:

table_1 
------- 
event_id 
attribute_1 
attribute_2 
[...] 
attribute_5000 

en quelque chose comme ceci:

table_1   event_values    attributes 
--------   ------------    ---------- 
event_id   event_id     attribute_id 
       attribute_id    attribute_type 
       attribute_value 

qui peut être utilisé avec tous les SGBDR (votre seule contrainte serait alors la taille totale de la base de données et la performance)

Answer 2

Il est probablement très tard pour une réponse, mais voici ce que je fais. J'utilise HDF5 comme référentiel de séries chronologiques. Il a un certain nombre de styles de compression efficaces et rapides qui peuvent être mélangés et assortis. Il peut être utilisé avec un certain nombre de langages de programmation différents. Il est disponible sur Windows ainsi que Linux. J'utilise boost :: date_time pour le champ de l'horodatage

Cela permet une grande variété de calculs basés sur la date et l'heure.

Dans le domaine financier, je crée alors des structures de données spécifiques pour chacune des barres, les tiques, les métiers, citations, ...

J'ai créé un certain nombre d'itérateurs personnalisés et utilisé des algorithmes de bibliothèque de modèle standard pour pouvoir rechercher efficacement des valeurs spécifiques ou des plages d'enregistrements temporels. Les sélections peuvent ensuite être chargées en mémoire.