flux de data live

[buzzz]

Bonjour à tous

Je cherche un flux de qualité pour mes trading autos. J'ai déjà eu à faire à des flux tronqués : max 4 messages par seconde et je sais que c'est compliqué pour du scalping.

Je m'interesse aux indices et j'aurais aimé tradé avec IG/cfd à risque limité. Je ne sais pas si leur version MT4 permet 1- de recevoir ces flux et 2- de recevoir des flux de qualité ?

J'ai fait une mission avec l'api LMAX et avec eux j'avais bien du 20 à 100 ticks / secondes

J'ai entendu parlé de CQG mais je n'ai pas d'expérience avec eux. J'ai bossé avec avec TT api et leurs flux étaient de toute beauté mais la licence est à 1000 brouzoufs par moi.

De mémoire PRT est assez radada pour le dev et il n'est pas possible de capturer les flux premium de PRT (je peux me tromper, je n'ai pas regardé depuis un moment).

Donc j'hesite a prendre le flux d'un broker car si je dois changer de broker, je change de flux... et j'aurais preferé m'abonner à un flux de data indépendant de mon brooker, si cela est possible.

[Benoist Rousseau]

Tu parles de quel flux ? Futures ?

cfds à risque limité c’est chaque broker qui le fait ce n’est pas un vrai flux

[buzzz]

oui cfd à risque limité chez IG
cependant, je pensais que les flux futures étaient assez proches des cfd à risque limité voir plus précis car plus rapides
et je me disais que cela suffirait

mauvaise idée ?

[Benoist Rousseau]

Je ne comprends pas ce que tu écris désolé

[buzzz]

Pardon, je vais reprendre

Tu écris : "je suis passé notamment par PRT Trading pour ouvrir mon compte chez IB et IG". Ils me fournissent un flux premium tick." dans ton livre.

J'ai regardé les datas stockées par takapeek. Pour les cfd à risque limité IG Dax , (je peux me tromper) je crois avoir vu au mieux 4 ticks/seconde soit du flux tronqué

Il me semblait que PRT Trading fournissait plus que 4 ticks/sec pour les cfd à risque limité dax.

Bref, je ne sais pas si les données de takapeek correspondent au flux optimal des cfd à risque limité ig. Et si cela n'est pas le cas, comment les avoir ...

[Benoist Rousseau]

4 ticks par seconde c’est le flux natif d’IB

[takapoto]

@buzzz
Si ça peut alimenter ta réflexion :
nombre-de-ticks-recus-en-une-seconde-pt ... 16365.html

[buzzz]

merci takapoto

je vais regarder ce fil qui correspond à mes interrogations

[zwan]

Si tu veux la meilleur source pour les données IG la seule bonne méthode et d'utiliser leur API.
Il m'ont dit qu'elle me serait disponible quand je passerais en compte réel.
Mais si c'est pour du backtest en tick absorber les données vas prendre des mois entier.
pour exemple mes données EUR/BTC en tick sur KRAKEN prennent 6 giga sur une base données SQL j'ai mis 1 semaine à absorber tout ça depuis 2013 car les API ont des limitations pour ne pas saturer l'infra broker ce n'est pas du téléchargement pure.
alors je te laisse imaginer le DAX tu peux faire du * 10000 pour la même période.
un bon compromis serais d'acheter les données sur le web en gros bloc sur le web (et la beaucoup d'arnaque car ce qu'il appellent "tick" est souvent du "1000 tick" ce qui divise leur coût de stockage par 1000.
je test en ce moment tiskstory les données en tick on l'air pas trop mal pour du back test mais la encore difficile de dire si c'est du tick du 100 tick?.
Exemple de sortie (au choix csv ou metatrader).
Timestamp,Bid price,Ask price,Bid volume,Ask volume
20190210 23:03:28:904,10954.41,10960.59,0.000609999988228083,0.00063999998383224
20190210 23:03:37:155,10953.41,10960.59,0.000609999988228083,0.00047999998787418
20190210 23:03:37:206,10953.41,10959.59,0.000609999988228083,0.00047999998787418
20190210 23:03:38:363,10954.41,10959.59,0.000369999994290993,9.99999974737875E-05
20190210 23:03:38:413,10954.41,10960.59,0.000609999988228083,0.00047999998787418
20190210 23:03:40:517,10953.41,10960.59,0.000609999988228083,0.00047999998787418
20190210 23:03:40:567,10953.41,10959.59,0.000609999988228083,0.00047999998787418
20190210 23:03:41:157,10952.31,10959.59,0.000609999988228083,0.00047999998787418
20190210 23:03:41:207,10952.31,10958.49,0.000609999988228083,0.00047999998787418
20190210 23:03:41:870,10952.81,10958.49,0.000369999994290993,9.99999974737875E-05
20190210 23:03:41:920,10952.81,10958.99,0.000609999988228083,0.00047999998787418

[Robinhood]

@Zwan : si je peux me permettre, stocker du tick en SQL ça n'a pas de sens. Il vaut mieux privilégier des fichiers plats et à la rigueur du no-sql (beaucoup plus adapté à l'intégration de très gros jeux de données). Bien plus efficient en termes d'accès, de taille de stockage et de sécurisation de tes données.

[zwan]

@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.

[takapoto]

Screenshot 2019-08-11_20-57-28-151.jpg (23.29 Kio) Vu 1255 fois

[zwan]

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"

[takapoto]

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 )

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.

[takapoto]

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

[Robinhood]

@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

[zwan]

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 pourquoi 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.