Discussion :

[pcpdev]

Bonjour,

j'espère que ma question n'est pas hors de propos ici, j’aimerai pouvoir trouver des conseils car j'ai du mal à appréhender le problème du stockage de séries temporelles.

Je reçois quotidiennement des données sous forme de fichiers csv (7 colonnes et des dizaines de milliers de lignes). Les données contenues dans ces fichiers sont des relevés quotidiens de certains caractères de différents individus (ces individus sont identifiés par 2 ids et 5 variables sont relevés pour chaque individus).

Les données fluctuant chaque jour, je souhaiterai pouvoir conserver pour chaque date les valeurs de chaque variables afin de pouvoir analyser des séries temporelles.

Et c'est tout là mon problème, je n'ai pas la moindre idée de comment stocker efficacement des séries temporelles.

(Petite précision supplémentaire : Les individus observés d'un jour sur l'autre sont souvent les mêmes mais pas forcement, un individu X peut être observé le jour J sans ne jamais avoir été observé jusque là et sans être forcement observé les jours suivants. En plus d'une base observée assez régulièrement, de nouveaux individus apparaissent/disparaissent chaque jour.)

J'ai tout d'abord commencé par ce que je connais, une base de données relationnelle MySQL. J'ai essayé de normaliser mes données mais le schéma auquel j'ai abouti ne m'a pas vraiment convaincu, de plus le nombre élevé de jointures impactait fortement sur les performances.
Pour l'instant, vous bondirez peut être au plafond en me lisant, j'ai simplifié ma BD en créant une table pour chaque fichier, chaque table a pour nom la date des données. Cela me permet d’accéder aux données voulues (que je traite ensuite avec un logiciel de statistique) en requêtant les bonnes tables. En terme de "performance" ce n'est pas si mauvais sans pour autant que ce ne soit une bonne solution et j'ai l'impression de louper pas mal de choses notamment le NoSQL qui me fait un peu de l’œil.

Je souhaiterai donc explorer un peu cette piste. Pour l'instant j'ai déjà fait un bon nombre de lectures et j'en ai déduis que ce genre de solution pourrait être plus adaptée à mon problème qu'une BD relationnelle plus fortement structurée. J'ai plutôt bien compris les bases, néanmoins je n'ai pas suffisamment de connaissances pour pouvoir mieux cerner quel type de base de données NoSQL serait la plus adaptée. Il semble que la base orientée colonne, avec la possibilité de rajouter des colonnes dynamiquement (les nouvelles données quotidiennement par exemple) pourrait être une solution intéressante. Mais n'étant pas familier de cette technologie je n'arrive pas bien à y voir clair.


Avez vous déjà été confrontés à ce genre de problématique ? Avez des suggestions quant au type de BD NoSQL sur lequel je devrais me pencher pour mon problème ?

Merci d'avance !
Cordialement

[escartefigue]

a priori, je ne vois pas en quoi une BDDR classique ne pourrait pas satisfaire le besoin, mais il manque des infos

• combien d'études distinctes sont à stocker dans la base
• quelle est la durée totale de chaque étude
• quel est le nombre de personnes distinctes à étudier par étude
• combien y a -t- il de caractères distincts à étudier par personne (a priori 5)
• quelle est la durée de stockage des données d'une étude

Si l'échantillon pour une étude est de 2000 personnes (même si toutes n'ont pas des relevés tous les jours), que l'étude dure 3 ans et qu'il y a 5 caractéristiques maximum par individu, alors il faut traiter au maximum
2000 * 5 * 3 * 365 = 11 millions de lignes pour une étude, ce qui est assez peu, un SGDB R classique peut traiter sans souci en terme de volume et en terme de modélisation je ne vois pas non plus ce qui coince ?

[SQLpro]

Si votre problématique est l'intégration d'une forte volumétrie de données de différentes nature mais ayant toutes un marqueur de temps, alors il faut s'orienter vers une solution de CED (par exemple intégrer 1 millions d'événement par heure provenant de différents support : fichier texte, xml, flux http...). Par exemple StreamInsight.
Sinon orientez vous vers un SGBDR. La croyance populaire que le nombre de jointure tue les performances dans un SGBDR est une imbécilité hélas fortement répandue !
Lisez la réponse que j'ai donné ce matin même à ce sujet : http://www.developpez.net/forums/d15...s/#post8324785

A +

[GeoffreyOnRails]

Je vais reprendre ce qui a été dit plus haut, si tu as 10000 lignes par jour, une base de données classique fera très bien l'affaire. Si ça se trouve, un fichier plat ou même un fichier Excel pourrait presque suffire tellement la quantité de données est faible.
En revanche, tu as effectivement raison, l'idée de faire une table par fichier me fait bondir au plafond. La solution la plus classique est un schéma en étoile, avec une table de faits au centre et les informations concernant les individus dans des tables séparées.

Mais puisque ta question concerne le NoSQL, permet moi de t'orienter malgré tout vers cet ouvrage (assez court) : http://info.mapr.com/rs/mapr/images/..._Databases.pdf Tu y trouveras non seulement comment gérer les time series en NoSQL mais aussi en BDR classique.
Et puis surtout, tu te devrais te rendre compte que des bases de données spécifiquement conçues pour gérer des séries temporelles, ça existe en version "tout fait". Tu ne vas pas en recréer une par toi-même. Tu peux même en trouver une liste de solutions existantes sur wikipedia. https://en.wikipedia.org/wiki/Time_series_database