Reprise du message précédent :

Ba disons que c'est un peu le plan aussi, oui. Je sais pas au niveau optim et indexage, mais ne serait-ce que d'un point de vue temps de traitement, je me vois pas me taper les données au tick près pour aggréger sur une TF horaire.

Ba des traders intraday y en a, spa rare. J'aimerais pouvoir gérer ce cas-là.
Après, le budget, je m'en fous un peu ; stun truc perso, je fais ça essentiellement pour apprendre certaines technos. Mais pour l'optim, pour avoir vu ce qui se faisait dans les grosses banques françaises... comment dire J'ai vu des fermes de calcul de machines virtuelles avec des cons de process monothreadés, des trucs bloatés jusqu'à la moëlle pour faire 3 calculs de pricing à la con, franchement ça m'a fait mal. Justement, je pense que si je peux montrer ce que donne une appli pas trop con faite en "hobby" par un gars tout seul, ça peut m'aider par la suite
'fin comme je disais, c'est plus pour moi que pour répondre à un réel besoin
Sinon, tu parles d'import/export Dans quel cadre ? Oui, pour importer les données de l'utilisateur y a un vrai boulot, mais encore faut-il savoir commnt stocker le bordel ensuite Si je pars sur une DB plutôt que du fichier plat, ou vers du NoSQL, le mécanisme sera nettement différent.

Disons que quand tu commences à avoir bcp de volume, t'essaies de gratter sur l'espace disque pour limiter les i/o disque.
Du coup ça peut être + intéressant de transformer des champs texte en numérique avec une référence.
Là effectivement les codes ont l'air courts, c'est pas forcément pertinent.

Premierement 350M de lignes c'etait bcp il y a 10 ans, maintenant c'est presque normal comme volume. Pas besoin de se casser la tete de trop, ici on a des tables de volume equivalent (date, ID, 4 float) qui font 80M de lignes par jour (la table fait 1.1miliard) et ca tourne sur un petit server de dev sans aucun impact.
 
Deuxiemement la RAM c pas cher, mangez-en, te limite pas a 8Go quand tu peux avoir 64Go (ou le max de la carte mere) sans depenser un pont.
 
Sinon virer le varchar et utiliser un format de date numerique c'est tres important, meme si tu gagnes quasi rien, c'est quasi rien x 350M. C'est de l'optimisation pas cher et facile, donc pourquoi ne pas le faire?
Ca evite aussi les prolemes d'import, de corruption et d'integrité.
Si c'est correctement utilisé tu n'as pas d'impact négatif.
 
Le seul vrai probleme que je vois c'est que tu veux rester dans le gratuit ou le pas cher en SGBD et ca veut dire que tu vas de voir bosser un peu plus dur pour avoir le meme genre de perf que sur du payant (Oracle/SQL Server), maintenant c'est pas un trop gros probleme, ca peut meme etre un super exercice mais c'est pas toujours super facil a installer/configurer pour un client lambda.
 
Tu pourrais aussi peut etre offrir un service au lieu d'une appli toute faite, et tu host les server quelque part, comme ca t'a qu'une fois les données pour tout le monde avec eventuellement les calculs les plus commun déjà calculé.

Le truc, comme je l'ai dit plusieurs fois plus haut, c'est que je contrôle pas la config sur laquelle l'appli va tourner. C'est l'utilisateur qui choisit quelles données utiliser sur sa propre machine, donc s'il veut faire des volumes importants (350M c'est peut-être pas "beaucoup" aujourd'hui mais c'est pas non plus super courant) sur son core 2 duo avec 4 Go de RAM, ba faut que j'arrive à faire tourner l'appli Pas forcément faire des perfs de dingue et tout, mais au moins tourner le bordel sans exploser.

Oui, c'est ce dont je me suis rendu compte en lisant les réactions plus haut. Je pense aussi partir là-dessus, même si je ne sais pas encore trop comment.

Honnêtement, ça je demande à voir. Comparer les perfs à config égale entre SQL Server/Oracle/SQLite, je suis pas sûr que SQLite soit perdant (au contraire, même). Si on prend vraiment le cas de 350M de lignes de 2 varchars + 4 floats, je suis quasi-certain que SQLite enfonce les 2 autres.
Sans compter, comme tu le dis, les problématiques de déploiement.

J'y ai pensé mais ça va pas trop le faire. Déjà parce que "les calculs les plus courants" c'est pas facile à définir mais aussi parce que le calcul en soi n'est pas une mauvaise chose. Faire bosser le CPU sur quelques additions, même 350M de fois, tu t'en sors presque plus vite qu'en requêtant en base (SQLite, j'ai pas testé autre chose). Si en plus tu mets le GPU à contribution, je pense que ça ira encore plus vite (mais faut que je débroussaille tout ce sujet avant de m'avancer).
Après oui, ça peut être un service supplémentaire intéressant, mais pour l'instant je regarde l'appli lourde pour faire mumuse

Non mais tu peux garder un client lourd si tu veux et hoster les DB dans une infra en ligne que tu maîtrises.
Se pose alors les problématiques de droits de redistribution de ces données.

Vala
Nan mais je pense que c'est faisable pour la partie "serveur de données" mais doit y avoir des royalties à payer ou machin... je pense que je le ferai un jour pour moi, pour voir techniquement, mais je le mettrai pas à dispo. Déjà que l'appli lourde je suis pas sûr de la rendre publique...

 
A mon avis ca se finira plus en un histoire d'optimisation de queries, quoique dans un cas comme ici tu as probablement raison, mais mon idée c'était plutot de dire qu'avec du SQLServer/Oracle tu auras plus d'options pour le future, parceque bon, une appli ca evolue toujours et tu ajouteras vite d'autres options, services, etc...
Et la avoir de la compression/encryption/replication/partition/reporting/etl/etc... ca deviens assez vite utile.
 
Sinon pour faire avancer le shmilblik une table de 100M lignes en SQL Server (2x INT, 4x float, 1xDATETIME) ca prends sans indexes 5.3GB et +- 1min30 a remplire.
Par contre une table de 100M lignes (1x float, 1xint, 1xDATETIME) ca tombe a 2.7GB et 40sec a remplire (un seul thread, tu pourrais en avoir facil un par core mais tu serais limité par ton disque de toute facon).
Donc comme quelqu'un d'autre a dit, si tu arrivais a te débrouiller pour n'avoir besoin que d'une valeur + FK + timestamp (pas besoin d'ID apres tout), tu coupes tes besoin memoire en deux et la ca deviens tout de suite plus facile a caser en memoire.
 
Avec ta PK sur FK + DATETIME tu va pouvoir faire des aggregation de range assez facile et si tu partitionnes tu pourras encore plus facilement faire des calculs en parallele, enfin fo encore voir le detail exacte des calculs.

Non mais si les clients veulent vraiment (ce qui me surprend tout de même bcp) calculer sur 350M de données en ligne, ça fait un max de bande passante dès que t'as 3 ou 4 clients.

Sinon Oliii, je ne suis absolument pas persuadé que SQL Server soit plus rapide que PostgreSQL, par exemple. Mais malgré tout, je suis surpris par les chiffres que tu donnes. Il faut dire que je n'ai jamais eu l'occasion de remplir une très grosse table avec peu de colonnes, c'était plutôt des tables avec des dizaines de colonnes. Pour remplir ta table, tu fais comment ? Tu utilises quoi ?

Ce seront des données agrégées qui remonteront des serveurs de calculs donc peu de bp selon moi.

 
Avec la plus part des SGBD aboutit la vitesse d'insertion depend uniquement de la vitesse des disques quand on s'y connait un minimum.
Pour ce qui est de la vitesse, c'est un terme un peut trop générique, ca veut dire beaucoup de chose.  
Je suis sur que PostgreSQL est plus rapide dans certains cas, mais dans 99.999% des cas la vitesse ne depend que des connaissances des gens qui ont fait le design et de ce qu'on compare.
Je ne connais pas assez PostgreSQL pour comparer les deux.
 
Ici j'ai utilisé un bulk import simple (bcp in) a partir d'un fichier.

Ba du coup, on délègue tout au serveur : données + calculs. Ca revient à faire un client léger. Maintenant, je pense effectivement que ça résoud le pb juridique des données puisque tu ne les distribues plus, juste le résultat des tests (+ des graphes, éventuellement).

Voila, et là, ben en fonction du nombre de clients, t'as intérêt à avoir de gros serveurs, limite à tout coder en C++ (ou en D).