Discussion :

[pusse]

Bonjour,

je vais tenté de vous expliquer mon "dilemme".

J'ai prévu de récupérer un quantité importante de données dans un but d'étude statistiques.
Je pense faire mes études via excel ou tout logiciel similaire permettant notamment la création de graph....
Est-il à votre avis préférable, lors de la récupération de ces données, de les stocker en BDD et de générer un excel depuis les données qui m’intéressent (donc de faire la sélection avant l'ouverture dans le logiciel choisi) ou de récupérer mes données directement dans un énorme fichier json ou xml (que je mettrai à jour au fur et à mesure) qu'il me suffirait d'ouvrir ensuite directement en excel ? Je tiens à préciser que je n'ai aucun problème avec la programmation. Mon problème viens plus du fait de savoir comment traiter cette importante masse de données.

Suis-je assez clair dans ma demande ? J'avoue que c'est pas facile à expliquer.

Je suis bien sûr preneur de toutes remarques, idées ...

Merci d'avance

[foetus]

Je suis fan des bases de données donc pour moi c'est évident

Sinon

• le XML est déjà très verbeux. Donc je pense qu'il faut oublier ce langage.
• Avec le json, je pense que tu vas trainer un arbre en mémoire: donc surveiller ta consommation mémoire et s'attendre à avoir certains traitements assez long.
• Avec la base de données, c'est le temps de programmation qui va être plus long.

Tiens tu n'as pas pensé à la solution NoSQL , qui d'après ce que j'ai compris (et que les grosses sociétés comme Amazon ne disent pas), que c'est surtout fait pour des données qui sont beaucoup lues, mais très peu écrites.

[bretus]

Bonjour,

1) Base de données + interface + export CSV

Mon tableur préféré est PostgreSQL avec l'interface pgadmin : Tu as de la marge avant d'atteindre la limite du nombre de ligne.

Quand tu veux repasser dans Excel ou OpenOffice pour faire des graphiques, tu peux faire un export en CSV. Sinon, tu peux toujours faire du PHP/HTML/JavaScript avec des outils du type Google Graph.

2) CSV ou abstraction sur les données entrées

Après, si le programme de calcul de statistique est velu, j'aurais tendance à prendre en entrée du CSV (ou faire une abstraction sur la source de données : RowIterator) car on arrive facilement à fabriquer un fichier CSV.

3) ETL

Utiliser un ETL du type Pethaho PDI peut être particulièrement efficace.

PS : NoSQL est un buzz word qui cache de nombreuses technologies (des bases orientées clé/valeurs, des bases orientées documents, des bases orientées graphes, etc.)

[pusse]

Tout ceci confirme bien mon premier choix (BDD + export des données nécessaires en csv).

Y'a plus qu'à coder tout ça.

Merci en tout cas pour vos réponse et à bientôt

[dev_ggy]

Bonjour à tous,

Je vais nuancer les propos en rapport avec mon expérience sur l’analyse de la données. Concernant le choix entre une base de données, Excel et des fichiers. Cela dépend de l’utilisation ainsi que la masse de données que tu as. La simplicité et la facilité d’utilisation d’Excel ou Libre Office fondent un privilège pour ce type de solution quand on traite des données plutôt que d’utiliser une base de données qui peut être longue à mettre en place comparativement à des feuilles Excel. Mais si le volume dépasse plus du million de lignes Excel ou Libre Office ne supportent pas ce type de volumétrie. Dans ce cas la question du fichier et/ou de la base de données se pose. Pour faire rapide, l’intérêt de la base de données sur le système de fichier est la possibilité d’index si tu en as besoin. Sinon le fichier convient très bien.

Concernant ton utilisation de tes données pour faire des graphes. Je ne sais pas de quels graphes tu as besoin, mais il est difficile d’en faire sur de grosse volumétrie de données. Tu auras peut-être besoin d’agréger tes données et donc te retrouver sous Excel. Dans le cas où tu as fait le choix de la base de données. Concernant l’expérience que j’ai des outils pour les graphes. Les données sont toutes mises en cache à l’aide de matrice ou de relation qui peuvent nécessiter des volumes très importants de mémoire. Du moins de très gros volumes de données peuvent devoir être traités en cache.

PS : Avec Excel tu as les tableaux croisés dynamiques qui sont essentiels pour traiter la donnée.

Cordialement.

[pusse]

Je me permets de revenir vers vous car après réflexion, j’arrive pas à me décider sur le choix d'une BDD (SQL ou noSQL). Je vais essayer de vous expliquer plus en détails.

Concernant les données à traiter, je récupère un json ou un csv (scrappy permet d'exporter les 2 formats). Il va s'agir de données sportives. Pour donner un exemple, un club de foot avec des joueurs, un entraineur, un stade, des matchs, des données météo suivant le match, le résultat....

Le but de tout ça est de faire des études de stats pour un match à venir. Comparaison des équipes suivant la météo, le stade (domicile ou extérieur), l'entraineur qui a changé, les performances sur les derniers matchs , la date dans la saison... Je peux avoir aussi envie de voir tout ce qu'a fait un entraineur (tous ces matchs tout club confondus), idem pour un joueur, pour un type de temps donnée...

Globalement, je vais avoir bcp de données, toutes structurées de la même manière (quasiment ?: ), que j'ai besoin d'écrire une seule fois mais de lire plusieurs fois (extraction vers mon excel).

Je tiens à préciser que je suis dans la vie développeur php/mysql/css. J'ai donc des connaissances en SQL mais aucune en NoSQL.

Qu'est ce qui d'après-vous serait le plus logique ? Apprendre le NoSQL car je risque d'avoir rapidement bcp de données ? Passer du temps à structurer mes tables parfaitement et parser mes json ou csv avant insertion. Insérer le json directement dans une table NoSQL orientée documents ? orientée graphe ?....

Merci à tous pour vos pistes de réflexion

ps : si vous pensez que ce serait mieux que j'ouvre un autre topic, n'hésitez pas.

[dev_ggy]

Bonjour,

Je choisirais une base PostgreSQL ou MySQL.

Pour les deux raisons suivantes*:

Données structurées.
Volumétrie faible tout de même et malgré ton impression.

Mais pour mieux te répondre et parce que je peux me tromper. À quelle base NoSQL penses-tu*?
As-tu une idée du nombre de Gigas ou de Tera que ta base peut faire*?

Cordialement.

[pusse]

Après réflexion , je pensais effectivement passer sur du mysql. Le volume de données devrait pouvoir suivre même si je n'en ai aucune idée pour le moment .

En tout cas merci de ta réponse

[zaza576]

Bonjour,

pour te répondre, je suis actuellement dans une problématique similaire. Je joue avec 10 Go de données textuelles sur base de données SQL (cela représente environ 200 millions de tuples).
La base de données commence à atteindre ses limites et les performances sont très vite dégradées. Du coup, je fais une étude pour m'orienter vers :
- une base de données NoSQL (y a des chances que l'orienté document, ou l'orienté column me soient utiles)
- une base de données NewSQL (tout nouveau pour moi)

As-tu une volumétrie très importante et quelle est le taux de montée en charge de ta base (combien d'éléments insérés par jour par exemple ?)