ProRealTime
Pour partager sur le trading automatique, nos algorithmes, nos backtests

Re: flux de data live

par zwan » 11 Aoû 2019 19:31

@robinhood: heu la c'est un vaste sujet les mode les coût de développement les retour en arriere tous ca je t'invite a de la lecture ;)
Pour la partie base modern evidement c'est sympas pour les hyper infrastructure la question est en a tu vraiment besoin??
https://blog.timescale.com/time-series-data-why-and-how-to-use-a-relational-database-instead-of-nosql-d0cd6975e87c/
Je te passe la flexibilité la portabilité car quand en développe en DEV on change d'avis un coup je veut du JSON et puis finalement non entity framework vas me facilité le dev etc.. etc..

le fichier flat je comprend pas...
quel différence entre construire + télécharger 1000 fichier de 1 giga
et aquerir 1000 JSON du serveur sql (avec multithreading et tout les avantages).
https://stackoverflow.com/questions/2356851/database-vs-flat-files

dans mon cas je ne suis même pas au stade ou je suis dans ce genre de problématique les séries de tick ne sont pas du " big data" et les traitement sont modeste (si on code pas avec les pieds).
Le jour ou je fait du machine learning de dingue ou que je suis a l'international et que j'aurais une équipe de développement qui a le temps de faire compliqué pour gagner 20 second je penserai a mongodb ou autre .
et a vrai dire je laisserai azure gérer le truc. Je vois trop de société (dont la mienne) qui utiliser des technologies qu'ils ne comprennent qu'en surface.

D’ailleurs qu'en on débute le trading c''est aussi pratique pour faire de petit test en pure sql (aggregation/SMA/PP/) avant de sortir le gros code en C.
Pour l'instant Je suis en DEV et mon petit proc intel a 50 euro me retourne mes 30 million de tick en 2 minutes (sans le multi-threadind) imagine en PROD avec un XEON et les bon disque.
de plus si je code pas avec les pied je vais évidemment jamais appeler autant de tick pour rien .
Franchement faudrait le faire exprès pour pas s'en sortir en SQL.

Re: flux de data live

par takapoto » 11 Aoû 2019 19:59


par zwan » 11 Aoû 2019 20:14

Alors tu n'a pas lu les lien..
Evidemment que ca marche les fichier sont déjà téléchargé lol.
Je pourrais dire a mon stagiaire de télécharger en powershell et de m'en fichier csv aussi ce n'est pas le problème une fois les data en local chargé sans la mémoire vive tout marche ....
Tu pense que les banque font ca? des ptit fichiers ? ou il on un bon gros mainfraim avec de solide base DB2 éprouvées?.
La j'invite juste robin a lire les article citée et la réponse d' andrey qui est quand même une sommité stackoverflow donc quand il dit quelle-que chose c'est rarement dans le vide.
Et ça fait un point de vue "PRO"

Re: flux de data live

par takapoto » 12 Aoû 2019 01:41

Puisque l'on parle "PRO", essayons de ne pas tout mélanger sans trop savoir de quoi on parle.

Evidemment que les banques utilisent des bases de données. Mais elle elles en ont besoin car elle agrègent une grande quantité de données disparates reliées entre elles et qui, de plus, doivent être accédées en temps réel par plusieurs milliers, voire centaines de milliers d'utilisateurs.

Ce n'est absolument pas notre problématique quand on développe un robot qui est un petit système devant prendre une décision le plus vite possible avec les données dont il dispose et qui sont de structure simple et basique.

Et passer par la lourdeur des couches logicielles constituant une base de données et complètement inutiles dans ce cas (comme la création et la maintenance d'index, la réplications, l'analyse et l'optimisation des requêtes, la gestion du stockage, etc...) est juste contre-productif.

Sans parler de la lourdeur induite par une BDD lors de son installation, de sa mise à niveau, de sa conception et de l'écriture des requêtes. Tout cela étant complètement inutile et gaspillant un temps précieux qui ne sera pas utilisé à réfléchir et à développer notre stratégie (en supposant que l'on de dispose pas de stagiaire pour faire cela à notre place :D )

Bref, ne confondons pas les serviettes et les torchons et essayons de réfléchir par nous-même plutôt que restreindre notre pensée à celle d'une ou plusieurs "sommités" mal comprise et hors contexte.

Re: flux de data live

par takapoto » 12 Aoû 2019 02:29

Désolé Buzzz, ton sujet a un peu dérivé...

Re: flux de data live

par Robinhood » 12 Aoû 2019 07:54

@zwan : comme dit taka, chacun voit vs son besoin. Jai pas trouvé plus rapide pour ma part que de stocker en flat files et cest pas en csv je te rassure mais dans un format matlab (30 fois moins lourd sur le disque). Je tassure que quand tu as des milliers dactions en tick à traiter et à backtester tu as besoin du pont le plus court est cest dabord en cache puis en flat.
Pour info je fais du multi en permanence en particuliers sur laquisition et les backtests. Je dev avec une machine basée sur un 7940x et un serveur qui me permet davoir un pool enorme de core pour envoyer du lourd niveau BT (dual epyc 64 coeurs).
Bien entendu tout ceci en fonction des besoins. Parfois une DB en sql est plus adaptée. Parfois non :-)

Re: flux de data live

par zwan » 12 Aoû 2019 10:40

Oui la conversation perd son sens original on parle développement et ça dérive sur un petit programme de test perso qui ne prend en compte un seul indice alors oui ce n'est pas ma vision "PRO" des choses.
Donc taka te vexe pas nos projet sont juste différent.
Robinhood me demande simplement pq SQL plutot que flat donc je lui donne les liens pour comprendre ma problématique qui est différente la tienne je n'ai rien contre le flat je l'utilise et c'est même ce que je fait en premier en dev avoir une db local mais tout dépend du projet.
Mon concerne depuis c'est l’intégrité des data en permanence un décalage max avec le broker de 1 seconde et surtout reprise d'activité en cas de crash serveur (voir le poste ou il te manque des data).
Je joue sur crypto/forex/indice et j'ai pas l'intention de me descendre 2 tera de data sur un disque utilisateur ou d'avoir des data perdu que je doit reassembler a la main de plus
C'est bien évidement au final le serveur qui exécutera les strat(comme PRT d'ailleur) car c'est lui qui a la puissance de calcul et qui a la redondance pour
la sécurité de l’exécution des trades.
le client est juste la pour observer visuellement mes réglages et je n'ai aucun souci de perf sur calcul d'indicateur ou autre je peux attendre 1 minute que mon loader charge les données SQL ensuite je suis en flat ou ram (si j'ai besoin des new data ou pas )et ca speed pas de soucis je peux test et retest en un battement de cil

j'ai plus une problématique de stockage et d’intégrité des données et je pense que quand on commence a mettre des mois et des mois a collecter des données on fait plus gaffe et on s'assure que la solution de stockage est solide donc c'est ma réponse point.

Articles en relation
help EURUSD data
par ticktack » 24 Jan 2018 17:31 (4 Réponses)
Flux de données et mode démo API
par ouf2finance » 25 Juin 2018 12:09 (4 Réponses)

ProRealTime