Salut les jeunes
 
Alors vala : je suis en train de coder une appli (client lourd) qui utilise des données fournies par l'utilisateur. Il s'agit de données historiques qui peuvent prendre énormément de place et pour lesquelles je ne contrôle pas la taille : le périmètre peut varier beaucoup selon le style et les envies de l'utilisateur. Un cas simple d'utilisation et qui me paraît le plus probable représente plus de 5 millions de lignes de données (et je sous-estime peut-être, on peut aller au double sans trop de pb, je pense). Un cas un peu sportif pourrait représenter facilement ~700 millions de lignes. Le cas extrême pourrait aller au-delà du milliard.
 
On parle de cotations financières. La fenêtre temporelle peut aller du tick (plus petit changement de prix possible ; par exemple, 1 centime d'euro sur une action comme celle de la SG. Lorsque le marché bouge bien, on peut avoir plusieurs changements de prix par seconde sur les titres liquides) à la journée entière. Le périmètre fonctionnel est l'ensemble des actions dispo sur un marché (ex : sur le NYSE, on a ~1800 titres différents) ; idem pour les futures. Donc en gros, pour quelqu'un qui dispose des données de cotation pour l'ensemble du NYSE sur une fenêtre temporelle de 5 minutes (= 1 ligne de donnée = évolution du prix pendant 5 minutes) sur une période de 10 ans, on a grosso-modo : 1800 (nb de titres) x 10 (années) x 252 (nb de jours par an où le NYSE est ouvert) x 6.5 (nb d'heures par jour d'ouverture du marché) x 12 (nb de fois par heure où on a des données) = 353.8 millions de données. Ramasse tes dents.
 
Je ne dispose pas et ne compte pas fournir ces données dans un premier temps. C'est assez réglementé et le seul truc que je peux faire c'est récupérer les données "end of day" (EOD) mises à dispo par des gens comme Yahoo Finance ou Google. Mais pour les données intraday, l'utilisateur peut tout à fait les acheter auprès de certains organismes et mon appli doit savoir les charger et les utiliser.
 
Ma question c'est : comment je peux stocker et organiser intelligemment ces données ?
 
Actuellement, je joue avec SQLite qui est très bien en termes de perfs et me permet d'utiliser un système de base de données sans avoir à déployer (ou demander à l'utilisateur de déployer) tout un tas de bordel comme Postgres ou MySQL ou que sais-je. Maintenant, si le user me refile 350 millions de lignes à bouffer, j'en fais quoi ? Je découpe et stocke ça comment ? D'ailleurs, dois-je stocker quoi que ce soit, est-ce qu'il ne serait pas plus simple de garder les fichiers que le user me refile pour les parser chaque fois que j'en ai besoin ? J'ai pensé aussi à du NoSQL mais je m'y perds un peu et ne connais pas bien le sujet.
 
Enfin tout ça quoi. Toute idée bienvenue Je défriche vraiment, je sais pas trop dans quelle direction aller.

La réponse pourrait dépendre de comment tu comptes exploiter ces données ensuite. J'imagine que la solution de stocker les fichiers fournis et de les parser à la demande peut effectivement être valable, mais pour certains cas d'utilisation seulement.

Sinon je te dirais bien de regarder du côté de la BI ; ce genre de données se représente bien dans une BDD avec un modèle en étoile

C'est juste
L'utilisation est de charger les données d'un périmètre défini par l'utilisateur ; ex : tout le NYSE ou "tels titres" ou "tous les futures". La fenêtre temporelle et la période restent fixes. Donc en gros, je vais devoir charger les données demandées pour une fenêtre temporelle spécifiée ; ex : toutes les données EOD du NYSE sur une période de 12 ans.
 
A partir de là, je vais calculer divers indicateurs (choisis par l'utilisateur) au fur et à mesure que je lis les données ordonnées par date.

L'intérêt d'utiliser une BD va vraiment dépendre de si les calculs demandés sont toujours les mêmes (des plages de dates et c'est tout) ou si l'utilisateur veut pouvoir varier les critères.
Un fichier plat, si tu veux être un minimum performant, ça ne se lit que dans un sens: du début à la fin. Dès que tu vas commencer à taper aléatoirement dans les données, ça va ramer autant qu'une BD sans index. Donc si tu veux appliquer des critères sur d'autres colonnes, tu peux oublier.

Comme dit précédemment, ça dépend de ce que tu veux faire des données.
 
Tes indicateurs sont calculés par période. C'est quoi la granularité la + fine que tu souhaites ? Si c'est des indicateurs au plus fin à la journée, tu peux déjà aggreger tes données par jour dans ta DB.

J'ai pas compris l'utilisation des données, en fait. C'est l'appli qui fait des calculs sur les indicateurs ? Les calculs ont-ils réellement besoin d'être faits sur des centaines de millions de données, ou on peut faire de l'échantillonnage (ce qui revient à prendre une granularité plus grosse) ? Quelles sont les contraintes de temps, hardware ?

Ça dépend surtout des budgets infras dont tu disposes, et des contraintes éventuelles de temps réel.
Déjà, zieute du côté des cubes de données, y a des applis open source qui font ça me semble bien. Ca prépare des axes d'analyses à partir d'une base de données (en gros ça précalcule les agrégats nécessaires aux utilisateurs).

Chez nous on fait du BI dans la finance justement, à base de 2-3 milliards de lignes (pour le type de traitement le plus gros, on en a plein d'autres), à traiter au fil de l'eau, la majeure partie durant la nuit et une autre durant la journée (en fonction des closing internationaux).
On a déployé une solution à base de Sybase IQ (base orientée colonne) + suite Microsoft SQL Server (SSIS pour les intégration, SSAS pour la restitution sous forme de cubes).

Mais on n'a pas de contrainte de temps réel, du coup on a une latence moy. d'environ 2-5min sur la mise à dispo des données. Par contre pour la restitution, c'est ultra rapide.
Et ça demande également pas mal de taf : tuning de perfs surtout, modèles de données adaptés à mettre en place (schémas en étoile), mécanisme de découpage des données récentes/archives pour réduire la taille des tables de faits, etc.

Avec des contraintes TR je regarderais plutôt vers des bases in-memory qui permettent de tout charger en mémoire une base de départ, et d'y charger les MAJ ultra rapidement (sans parler des restitutions).
J'connais pas trop les noms de produits qui font ça mais pendant un temps y avait un POC ActivePivot qui tournaient dans la boîte (j'sais pas ce que ça vaut).

En tout cas zieute les outils BI, j'connais pas trop ce qui se fait en opensource mais y en a, ça peut faire une bonne base de départ/de réflexion.

Suivant les traitements à effectuer, je pense que ça va se jouer entre un SGBD ou un BI (pour info, Pentaho est un BI en GPL qui est très bien). Si les tables risque d'être très grosses, il y a la solution de les partitionner (en colonnes ou en lignes) suivant des critères.

Voila, on est déjà dans le monde du "big data", pas exactement le domaine de l'appli de bureau de base, sauf à coup d'algos et de structures de données sophistiquées et d'hypothèses permettant de réduire la majorité des données à du bruit que l'on peut ignorer.

edit: exemple http://wiki.pentaho.com/display/DA [...] +with+Weka

C'est à dire ?

Les bases in memory, ça permet vraiment de gérer autant de données ??? Là, je pense qu'on tape dans les To de données disque, quand même. Après, en RAM, ils réduisent p-ê l'espace utilisé. 1 milliard de floats, ça ne prend que quelques Go de RAM.

On a deux modes de restitution : cubes de données consultables par les utilisateurs directement sous excel (qui a en natif des modules BI), et récupération en masse par d'autres applications des périmètres qui les intéressent.
Avec les cubes, les traders naviguent dans leur TCD en jouant avec les filtres, colonnes etc de manière assez intuitive. Alors c'est pas super mesurable, du coup je n'ai pas trop de chiffres à te donner, juste si tu ne demandes pas n'importe quoi (genre la somme de toutes les valeurs depuis 1 an sur tout le périmètre entier), la navigation est fluide. Les requêtes les plus lentes prennent quelques secondes, et souvent c'est excel (2007 parce que 2010 semble bien + rapide) qui prend du temps au formatage.
Pour la restitution en masse, quand c'est bien fait, on a en perf la bande passante réseau (qui est plutôt très grosse chez nous).
La recopie base à base d'une cinquantaine de millions de lignes (60 colonnes) se fait en env. 30min.

J'ai pas le détail, je pense qu'au-delà d'une certaine masse de données ce n'est plus une solution intéressante. Mais c'est idéal pour le temps réel par contre.

Sinon un autre ajout : pour les traitements en masse (insertion/restitution) et pour les requêtes par axe d'analyse (dimensions), il vaut mieux en SGBD s'orienter vers une base orientée colonne que vers une base transactionnelle classique.
Le défaut des bases colonnes par contre, c'est que ça n'aime pas trop les requêtes unitaires en grand nombre, et il y a pas mal de contraintes nouvelles à intégrer, mais c'est une autre piste à étudier pour taiche.
Edit : j'ai entendu parler d'infobright en bien sur les sgbd colonnes gratuites

D'après ce que je lis, j'ai pas l'impression qu'il ai besoin d'analyse multidimensionnelle ou de cubes (enfin faut voir la gueule des indicateurs à calculer).
 
Par contre vu les volumes et si il y a des gros moyens ça vaut le coup de regarder les trucs à base de bases de données "vectorielles" genre SybaseIQ ou Qlikview.

C'est ce que je mets dans mon dernier post : zieuter les DB orientés colonne.
Sybase IQ c'est pas donné par contre

Certains SGBD gèrent la compression des tables. Ça permet sur de grosses volumétrie comme celles dont tu parles de faire moins d'I/O, en compensant par du calcul CPU. C'est en général très intéressant, surtout que les serveurs (et aussi les postes clients) sont en principe très large en terme de CPU contrairement à l'I/O qui reste toujours un sacré goulot d'étranglement (sortir 4 Go de data, même sur de la fibre et des baies ave de gros cache, ça prends du temps ... ). N'empeche quand même que si tu fais un select sur 700 millions de lignes, même si il y a moins a sortir du disque, ça restera très long.
 
Une autre solution, c'est de gérer du partitionnement de table. Une table peux être partitionnée suivants certaines règles. Le plus courant est la date, mais tu peux choisir tout un tas de critères. Tu peux très bien avoir, par exemple,  une partition par jour, et lorsque tu insère une donnée, le SGBD place la data directement dans la bonne partition. C'est entièrement transparent pour le select, tu ne fais qu'niterroger ta table, sans te préoccuper de la partition.
Ce type de système est très intéressant pour limiter le nombre de lignes que tu interroges, d'autant plus que tu peux avoir des indexes locaux à la partition. Par exemple si les consultations se font beaucoup sur la journée courante, tu ne récupère que les quelques lignes du jours, que tu peux éventuellement stocker en RAM comme suggéré plus haut (je ne pense pas que tu auras 1 To de data pour une seule journée). Le tout après est de définir le critère de partitionnement (un jour / deux jours / une semaine / ou sur d'autres critère scomme le nom d'une action, etc.), et de le gérer correctement (les indexes globaux posent des soucis par exemple, si tu veux dropper une partition).
 
Ces deux solutions fonctionnent plutôt pas mal chez Oracle, mais j'avoue ne pas bien connaître les autres SGBD...

T'as Infinidb aussi qui a une version community : http://infinidb.org/
Mieux qu'Infobright de ce que j'ai pu tester (au niveau compatibilité SQL).
 
Récemment pour des tests j'ai chargé 170 millions de lignes à partir d'un CSV.
Le loading avec leur loader a pris 700 secondes dans une VM sur mon PC.
Taille de la base après loading : 2Go (le CSV faisait 18Go). En MyISAM avec nos index on était aux environ de 70Go (20Go de données et le reste d'index).

drapal

J'ai pas bien compris le besoin en terme de latence, nombre de users et si tu comptais faire du Write
 
 
j'ai du louper autre chose parce que passer de SQLite à Cassandra c'est un peu le grand écart par exemple
T'as quand meme la couche intermediaire avec des vrais bases de données et des vrais serveurs, du partionnement et du caching par exemple

Le pb est intéressant, mais c'est vraiment l'usage des données derrière qui va jouer.
 
Mettons que ce soit de l'exploration, genre afficher des parties arbitraires de la courbe d'une valeur, je partirais bien sur un stockage hiérarchique de ce genre :
T'as à stocker la séquence :
1 4 2 6 8 5 9 4
Tu groupes récursivement les éléments 2 à 2 en calculant la moyenneet l'écart entre les deux :
(2.5, -1.5)  (4, -2)  (6.5, -1.5)  (6.5, 2.5)
puis :
        (3.5, -0.75)                 (6.5, 0.0)
     -1.5            -2           -1.5          2.5
puis :
                      (4.875, -1.625)
          -0.75                              0.0
-1.5                -2             -1.5             2.5
Tu peux interroger une valeur au tick près comme la moyenne sur une sous-section arbitraire en log(n).
Tu stockes des bouts de sous-arbres par paquets de 4k qui vont bien pour être pote avec ton disque dur et banco, log2(un miyard)/log2(4096/sizeof(float)) t'as un worst case de 4 accès disques à la louche, sans compter les premiers niveaux que tu gardes en ram
(Par contre, y'a 2-3 trucs tricky à gérer pour la précision des données auxquels il faut faire gaffe, mais rien de très complexe)

Putain, je pose une question toute conne, je pars bouffer 2h et c'est le bordel On peut pas vous faire confiance
 
 
Plus sérieusement, merci Je vais déjà répondre aux questions, puis on verra.

Pour les connaisseurs, il s'agit de backtesting. En gros, un trader ou gérant ou quant va vouloir analyser les perfs d'une stratégie de trading sur une période donnée. Selon sa personnalité et son style, il va vouloir tester sa strat sur une fenêtre temporelle (ou time frame, que j'abrégerai en TF par la suite ) précise. Pour valider sa strat, il va vouloir la faire tourner soit sur une période précise (ex : crise de 2008, crash de 1987, bull market des années 80, etc...) soit sur une période très longue genre 20-25 ans pour voir ce que ça donne. Tout dépend des données dont il dispose et de ce qu'il a envie de tester.
Les indicateurs dont je parle représentent sa stratégie. Ca peut aller de quelque chose d'extrêmement simple (moyenne mobile) à de plus compliqué (calculs poussés pour options exotiques ; dans un 1er temps, je ne traiterai pas ce cas). Ca va jouer uniquement sur le CPU, je pense. Chaque indicateur va avoir des paramètres d'entrée (ex : une moyenne mobile sur 20 périodes ou 54 ou 14, etc...), donc il est a priori exclus de stocker aussi les indicateurs en base. Même s'ils ne sont pas censé bouger (la moyenne mobile 20 périodes entre le 12/05/2008 et le 11/06/2008 ne changera pas).

Le plus fin c'est le "tick" soit le changement de prix. C'est particulier car ce n'est pas vraiment une donnée temporelle. Pour l'expérience, on va dire que la granularité la plus fine est celle de 1 minute. 1 ligne de données = 4 doubles (open, high, low, close) + 2 strings (timestamp de la donnée + symbole du titre ou de l'instrument financier concerné) + 1 int (volume échangé durant cette période car je ne regarde que des marchés listés pour l'instant). Ca peut varier mais avec ça on a les infos nécessaires.
 
L'aggrégation de données, j'y avais (un peu) pensé. En fait, je n'ai besoin que des données le plus fines ; en effet, avec 5 lignes de 1m, je peux calculer les données sur 5m, et on peut extrapoler pour les autres TF. Mais l'inverse fait perdre des infos, ce qui est pénible lorsque le gars veut changer de TF (genre il teste sur du 5m et il veut faire un test sur du 1m)

Hardware inconnu, c'est celui de l'utilisateur et je ne le maîtrise pas Après, il faudra être réaliste, le gars pourra pas stocker 40M de lignes avec un disque dur de 400 Mo La config "recommandée" (comme pour les JV) serait un PC quad-core avec un HDD 500 Go, un OS 64 bits et 4 à 6 Go de RAM. Je vais regarder côté GPU si y a pas moyen que je lui délègue tout ou partie du calcul des indicateurs (je pense que c'est clairement le cas) mais une CG assez récente genre 2 ans mini serait bien. On parle de config recommandée, pas nécessaire
Contrainte de temps : ba honnêtement, y en a pas vraiment. J'aimerais que le test de l'utilisateur prenne quelques minutes, mais c'est évidemment fonction du périmètre et duy hardware. Typiquement, aujourd'hui, avec mes 4.8M de lignes dans SQLite (= 14 ans d'histo du NYSE pour une TF jour soit 1 ligne = 1 cotation pour un jour donné ; la DB pèse 550 Mo), j'arrive à lire + faire tourner 2 moyennes mobiles sur tout le périmètre en environ 24 secondes sur un quad-core 2.67 GHz avec HDD 7200 tours de base. Donc idéalement, sur le même type de config, je fais tourner tout le bordel sur ~50M de lignes en moins de 5 minutes. Si j'arrive à faire intervenir le GPU de façon significative, évidemment, les chiffres changeront mais j'ai pas encore d'idée sur le sujet.

0 temps réel. Budget = le mien C'est une appli perso que je fais essentiellement pour apprendre des technos et me prendre la tête sur comment organiser le merdier Ca a un peu fait tilt quand j'ai commencé à regarder tout ce qui est parallélisation en .Net + les histoires de NoSQL, je me suis dit qu'y avait moyen d'apprendre tout ça pour pas trop cher.
Donc effectivement, on va éviter les solutions chéros propriétaires style Sybase ou Oracle

Donc ouais, pas trop de trucs proprio, mais apparemment vous avez tous l'air d'accord sur la BI et les cubes, donc je vais voir

Oui big data, mais ces data sont potentiellement accessibles par n'importe qui cherche à les obtenir. Exemple de vendeur de data au tick près : http://www.tickdata.com
Là en gros, tu peux acheter un bon paquet de données pour style 1500$. C'est cher, mais les traders intraday un peu sérieux vont pas hésiter à investir pour tester leurs strats, c'est un peu leur gagne-pain.
Y a déjà des applis qui font ça mais bien souvent c'est sur des données EOD (donc pas d'intraday) donc moins de volume. Pour ceux qui font de l'intraday, c'est souvent vite limité à une période ou alors ils stockent rien en local et récup les données depuis un provider. J'aimerais voir si c'est possible de changer ça dans le monde d'aujourd'hui ; je pense que oui mais c'est surtout le "comment"

To je sais pas. Probablement pour les cas extrêmes, mais si 4.8M de lignes = 550 Mo, je pense qu'on peut extrapoler en disant que 500M de lignes =~ 60 Go, ce qui reste raisonnable. P'têt pas en un seul fichier mais bon, tu vois l'idée.

Ma dernière mission était pas mal en rapport avec ça Microsoft Analysis Services, des jobs d'analyse de risque ou de pricing qui prennent XX minutes sur une ferme et dont les résultats s'affichent dans Excel via un plugin. C'est intéressant mais stait un peu bloaté de partout et surtout très cher d'un point de vue infra. Mon opinion est qu'une bonne partie de ces trucs peuvent tourner en local, surtout chez un trader ayant 2 grosses cartes 3D en SLI pour afficher de la 2D sur 6 écrans

Oui, c'est aussi pour ça que je regardais NoSQL. Je sais pas ce que fait infobright mais leur site a l'air d'aller dans ce sens. Je vais regarder
Après, l'autre problématique, c'est le déploiement (je reviens là-dessus par la suite ).

Disons qu'après, c'est ce que je dis plus haut : l'utilisateur peut pas demander la lune non plus. Demander un backtest sur un histo de 350-400M de lignes, faut pas s'attendre à ce que les résultats tombent en 10s.

Vala, Oracle + base distante et tout Difficile dans mon cas.

Pas de write pour l'instant. La solution doit être standalone, c'est-à-dire que tout est chez l'utilisateur. Appli en local, base en local, calculs en local. J'ai pas trop peur pour les calculs, mais plutôt pour les données. Avoir une base en local permet d'avoir des bonnes perfs de chargement, mais du coup ça veut dire tout stocker chez le user et aussi s'interdire de partir sur n'importe quel SGBD. Je me vois pas dire "bon alors mon gars, pour utiliser l'appli, installe MongoDB/Cassandra/whatever", et pour ce qui est d'avoir un serveur de données, c'est difficile car certaines données ne peuvent pas se refiler gratos comme ça Les rares qui s'y sont essayés se sont fait taper dessus par les organismes de marchés (ex : CME, CBOT, etc...), donc bofbof.

Alors là pour le coup, j'ai pas bien pigé Tu stockes quoi au final en base/sur ton disque ? Et comment tu fais pour retrouver le bordel ?
 
 
Bref, merci à tous pour vos réponses, j'en attendais pas tant Après, vous êtes un peu partis sur des solutions de DB distantes, ce qui est difficile à mettre en oeuvre pour moi actuellement. Si c'est vraiment mieux je regarderai, mais pour l'instant c'est un peu sportif. L'objectif de l'appli est simple mais ses conditions d'utilisation le sont nettement moins. Le nombre de données dépend clairement des envies de l'utilisateur et aussi de son hardware. Du bonheur, quoi

Je stocke une version transformée de ta séquence de nombre, de taille ~équivalente, mais qui permet facilement et rapidement de récupérer un sous-ensemble de la séquence. C'est un peu dans l'esprit du tuilage google maps, mais en 1D avec des floats. Cela dit t'as l'air de plutôt viser des traitements batch plutôt que de la ballade, donc c'est pas spécialement intéressant pour toi.
Ce que tu vas plutôt viser c'est de la compression pour pas de ton cpu/gpu ait à attendre que le disque ramène les données, tu devrais ptêtre regarder du coté des algos de compression de son lossless.
[edit]
Du coup au niveau "architecte", je verrais plus des fichiers avec un format custom que des grandes db.

OK, je comprenais pas comment ça pouvait s'appliquer

C'est un peu l'idée. Aujourd'hui avec SQLite c'est pas flagrant parce que leur driver bouffe pas mal de CPU pour lire les données (je sais pas trop pourquoi), donc en mettant tous mes cores dessus, ça fonctionne assez bien (50% du temps total = lecture des données, 50% suivants = calcul des indicateurs), mais si j'arrive à mettre le GPU à contribution, ça sera probablement plus visible.

J'y avais pensé ce midi mais je me disais que c'était con Reste l'organisation du bordel ; 1 instrument = 1 fichier dans lequel je mettrais toutes les cotations ? Ou je sépare aussi par TF ? Fichiers binaires compressés, du coup ?
Faut que je fasse le test, c'est aussi une idée

Tu peux mettre du numérique je pense pour ces 2 infos Tu gagneras de la place.
Par contre je comprends pas pourquoi t'as 4 doubles par tick.
J'ai du mal comprendre mais genre dans ta table tick t'as pas les champs suivant : date, titre_id, valeur, volume ?
C'est quoi ton schéma en fait ?

Le symbole sous forme de numérique ?   On parle de noms style "GLE" pour la Société Générale ou "AAPL" pour Apple. Des symboles Bloomberg, quoi. Possible qu'on puisse convertir ouais, mais je sais pas si c'est une suepr opération Pour la date oui, mais je sais pas jusqu'à quand le gars va vouloir remonter (y a des tarés pour remonter jusqu'au 17ème siècle, alors bon...).
 
Le pb dans tes champs, c'est "valeur". De quelle valeur on parle ? La façon conventionnelle de représenter l'évolution du cours d'un titre, c'est open (= prix à l'ouverture, au début de ta TF), high (= plus haut pendant ta TF), low (= plus bas) et close (= valeur à la clôture). Ca te donne pas le chemin parcouru, mais à partir de ces valeurs tu construis les graphiques les plus courants : bar charts, chandeliers japonais, etc... Et c'est aussi à partir de ces données que tu vas calculer pas mal d'indicateurs (ex : points pivots). Donc t'as besoin des 4
Pour un tick simple oui, les données sont différentes, t'as juste besoin du prix, mais pour la plupart des données histo, t'as 4 valeurs à considérer.

Le symbôle sous forme numérique : table de référentiel. T'as jamais fait de foreign key ? Heureusement que tes codes font pas 150 caractères

Je vois bien à quoi correspondent tes 4 valeurs au niveau fonctionnel, mais du coup comment tu intègres la notion de tick avec cette modélisation ?
Ta TF c'est un intervalle si j'ai bien compris. Donc pour moi tes 4 valeurs sur ta TF c'est déjà de la données consolidées.
Les données brutes ce sont les cours des symbôles. A partir de ces données brutes tu consolides ce que tu veux.

Pour reprendre ton exemple de fournisseur, ça correspond aux trade data dispo ici http://www.tickdata.com/products/equities/
D'ailleurs ils mettent ça dans leur doc (pour le format US) :

En l'occurence, pour optimiser l'espace, une foreign key, ça n'a pas grand intérêt parce que ça va prendre autant d'espace qu'un symbole de 3 caractères. Par contre, j'ai jamais compris pourquoi le volume n'était pas pris en compte en analyse technique.

Je me suis déjà amusé à faire du backtracking dans un lointain passé sur un logiciel adhoc (AmiBroker), mais je ne faisais pas ça sur des millions de données, juste sur le cours de cloture des 10 dernières années, ce qui faisait quelques milliers de valeurs
J'avais même développé un indicateur suiveur plutôt efficace. Mais les outils existants intègrent un langage de programmation complet et un optimiseur pour le backtracking. Tu comptes faire ça sur ton outil, Taiche ?
Et est-ce que ça a vraiment un intérêt de faire ça sur des grosses masses de données ?

En tout cas, pour moi, vu que ce sont des données purement temporelles, une base de données n'est pas forcément nécessaire, des fichiers binaires avec un format adhoc iraient probablement aussi bien et seraient probablement ce qu'il y a de plus rapide. L'idée de compression de son de 0x90 peut sembler pas mal mais ça signifie nécessairement une perte et une granularité minimale. Un répertoire par symbole, des fichiers de données lisibles en parallèle par des threads ou en mmap (à voir si c'est possible en C#), et s'il faut faire super vite, le tout sur du raid 0 ou des disques parallèles. Les traitements en RAM par lots si la mémoire dispo n'est pas suffisante.

Mais il faut bien faire attention aux limitations qu'on s'impose si on part sur ce type d'option.

Hop, pour le fun, j'ai retrouvé ma formule magique de suivi de cours qui déchirait tout

où VolatilityWeightMA est la moyenne pondérée par la volatilité et DEMA = "Double Exponential Moving Average"

Ba c'est ce que dit muchacho après ; pour le coup je vois pas l'intérêt, mes symboles faisant en général 4 caractères max, avec quelques trucs exotiques à 5 ou 6. J'en suis pas encore à économiser là-dessus

Oui OK, mais seulement si tu disposes des données tick et que tu veux les utiliser. Un trader swing ou long terme, il va utiliser des données déjà consolidées et la granularité au tick près il s'en fout. Donc il achètera les données qu'il voudra (ou il les chopera carrément depuis Yahoo ) et s'il ne me fournit que des données consolidées, va falloir que je me débrouille avec
Je ne considère pas les données tick dans un premier temps pour mon dev, d'une part parce que c'est pas ce qu'il y a de plus utilisé et ensuite parce que j'en ai pas pour tester facilement Après, la lecture + consolidation, ça sera juste un traitement supplémentaire.

Il l'est sur les plateformes sérieuses ; en forex, qui est OTC, tu n'as pas de notion de volume donc ça bloque pas mal de possibilités. Mais pour tous les marchés listés, la notion de volume est importante et utilisée, oui.

Développer un système de trading, c'est pas simple. Tu veux que ton système fonctionne sur divers marchés, sur des TF différentes et à des périodes différentes, sinon c'est un système mal foutu qui présente un risque non négligeable de t'amener à la ruine. Par exemple, si tu fais un système qui ne marche que sur des bull markets (buy and hold, anyone ? ), il va un peu te péter à la gueule dans des marchés comme 2007-2008 ou 2002-2003.
Donc stu veux tester par exemple 20 ans d'histo sur 40 futures différents, avec des données EOD, ba c'est tout de suite 200k lignes dans la tronche. Ca fait pas trop peur. Mais si tu passes sur de l'intraday, genre des données 5m, ba hop, on multiplie tout le monde par 12x23 (pas mal de futures sont ouverts 23h par jour) et c'est tout de suite 5.5M de lignes. Alors imagine si t'as 1000 actions au lieu de 40 futures

Ba vala, justement je me demande quelles sont les limitations. Je vois ce que tu disais plus haut, à savoir la lecture "unidirectionnelle" genre on va pas se faire chier à faire des recherches sur telle donnée et tout, mais je peux déléguer ça au CPU via le LINQ de .Net qui est super pratique et rapide (du coup, puisqu'on a tout en RAM).
Donc je sais pas trop, je vais tester ça aussi ce WE, on verra bien. Je connais pas trop ce qui est derrière le memory mapping, je creuserai (quand je récupèrerai Internet, vu la Freebox est en rade depuis hier ).
 
Merci en tout cas Si je réponds pas avant lundi, c'est normal

Je réponds aux bouts que t'as édités

Oui, dans une certaine mesure Y a quelques solutions pour compiler du .Net à la volée au runtime, j'ai appris ça cette semaine. Je connais rien au sujet, mais ça me donne envie d'apprendre

Oui, la HullMA, j'aime bien la courbe que ça donne mais j'ai jamais trop joué avec

Si tu codes proprement, normalement, tu peux atteindre la bande passante de ton disque, qui peut monter à 100-150 Mo/s de données, à multiplier par le nombre de disques/plateaux si tu fais du raid ou du SSD.

Mon truc, la haut, ça bat tout (ce que je connais) colle le cours à la culotte sans overshoot ou undershoot.

http://msdn.microsoft.com/en-us/li [...] dfile.aspx \o/

 
Tes fongibles tu veux pas les traiter par position ?

Ba c'est le principe des HullMachin, sauf que du coup t'as pas vraiment de valeur ajoutée par rapport au prix brut et quand le marché "choppe" (= zig-zague), ba tu te fais chopper avec

Par contre, 64 bits obligatoires, pour les volumes de données en quesiton.

Pas faux, mais t'as tout de même bcp moins de bruit, avec très peu de retard par rapport au cours (ce qui est le pb des moyennes). Tu peux appliquer tes algos sur la moyenne plut^to que sur le cours lui-même.

Je viens d'apprendre la définition de fongible, mais je vois pas ce que tu veux dire
Je me sers des données justement pour savoir s'il doit y avoir ouverture ou fermeture de pos, une fois les signaux générés par les indicateurs, les données peuvent se faire dégager par le garbage collector, j'en ai plus trop besoin (sauf quand je voudrai faire un chart pour chaque trade mais c'est une autre histoire). Donc je pige pas trop

Disons que ça permet de créer un cache en tout cas. Je sais pas, je connais pas bien le sujet, je vais jouer avec
Après ouais, la limite de ~1.2 Go de RAM par process sous Win32 c'est clairement la merde

Oui, c'est ce que j'avais bien aimé justement, t'avais un bon rapport latence/bruit avec cet indicateur. Mais ch'ais pas, j'ai pas accroché.

Pour le memory map, tu vois ton fichier comme un grand tableau en RAM, donc sous win32 (comme sous nulix d'ailleurs, enfin la limite est un peu plus haute, vers 1,7Go de mémoire), tu ne pourras pas mapper des fichiers de plus de 1,2 Go grosso merdo. Donc tu découpes tes fichiers en segments d'1Go voire 512Mo (ce qui n'est pas une mauvaise idée en soit, soi dit en passant, ça facilite bien des choses, pour la gestion de transfers de fichiers par ex) que tu traites un à un, ou en // si l'algo le permet. C'est probablement une bonne solution, ça ne sera pas plus lent et ça passera sur win32.

Le but du cube c’est de permettre l’analyse multidimensionnelle, c’est à dire d’étudier des indicateurs agrégés en faisant varier le niveau de granularité. En gros tu vas précalculer tous les agrégats et les stocker en base. Tu pourras par exemple avoir la valeur de ton action minute par minute, et précalculer des moyennes horaires, quotidiennes, etc. pour y accéder rapidement.
 
Ca n’a pas l’air de correspondre à ton besoin.

Les futures par ex. (mais fonctionne entre autres aussi pour les options listées ou les bonds) sont fongibles, cad que tu peux les agréger par position sur un contrat+date de livraison (pour les futures), ce qui réduit le nombre de lignes à traiter de manière drastique

Si si, c'est pas idiot, il peut stocker plusieurs niveaux de granularité et y accéder plus rapidement, comme ça: exemple, un tableau de cotations à la seconde, un à la minute, un à l'heure, par exemple. Il gagne un facteur 3600 entre la seconde et l'heure, en grossissant de façon assez marginale la taille de ses données.
Par ailleurs, le tableau des heures permet d'indexer le tableau des minutes et celui des minutes d'indexer le tableau des secondes en indiquant dans quel fichier et à quel endroit taper pour tomber sur une date donnée à la minute près. On peut faire de l'accès direct de cette manière, on est alors au maximum à 59 secondes de la date exacte voulue. Comme une seule lecture disque permet de lire 8 ko d'un coup, on doit pouvoir même indexer toutes les 5 mn sans pertes de perf.

J'ai l'impression que tu te prends la tete pour pas grand chose, tes worst case sont quand meme hyper rares et les strategies de trading pluri annuels sont fait dans des trucs souvent un peu plus optimises et budgetes que ce que tu as
Je pense que reflechir sur les mecanismes d'import export etc... rendront ton truc plus utilisables que de vouloir gratter 4sec sur SQLite
 

 
Tu connais sans doute mieux la techno que moi derriere et les optimisations qui peuvent s'appliquer mais se cogner une FK dans une table de 350MM de lignes pour pointer sur un referentiel de symbol ca me semble un poil couteux
 

Toi on sens que tu bosses sur des trucs qui sentent le souffre

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.