Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Задача простейшая и хочу проверить возможно ли. 28 валютных пар, все с 1999 года. Хочу запустить минутные чарты и посмотреть их все.
Считаем:
минутки за 10 лет по 28 парам и 40 байт на запись > 328 ГБ .. Бред
PS: А почему только за 10, а не скажем от самого Р.Х. ? ;-))
а может вас еще и тики для анализа заинтересуют ? )))))
Считаем:
минутки за 10 лет по 28 парам и 40 байт на запись > 328 ГБ .. Бред
PS: А почему за только 10, а не скажем от Р.Х. ? ;-))
может вас еще и тики для анализа заинтересуют ? )))))
В последствии может быть и тики потребуются, кто знает....
Выяснил, больше 1,91Gb терминал не может использовать. Что не есть хорошо....
И не нужно думать, что Вы умные, а я глупый, раз спросил значет мне действительно нужно открыть все эти 28 пар и нужно знать то что я спрашивал.
Выяснил, больше 1,91Gb терминал не может испотльзавать. Что не есть хорошо....
а если запустить несколько турминалов с разными парами, и советники связать посредством DLL+некий IPC для обмена данными между терминалами, думаю вполне реально.
Даже если и сделают мкксимум что сможеш выжать 2.89 GB на терминал - тебя это спасёт ?
Да спасет. я смогу загрузить минутных котировок приблизительно за 1-5 года по каждой валютной паре. А мне как раз и нужны пока эти пределы.
Вопрос в том что-бы загружены они были все и сразу. Требует ситуация именно такого подхода.
Для таких объёмов лучше СУБД использовать, ИМХО. База котировок у меня с 1999 года занимает около 4,7 ГБ, а прога работает хоть на 6ГБ RAM хоть 512МБ.
Скорость конечно сильно разная, но зато проблем с масштабированием нет.
Для таких объёмов лучше СУБД использовать, ИМХО. База котировок у меня с 1999 года занимает около 4,7 ГБ, а прога работает хоть на 6ГБ RAM хоть 512МБ.
Скорость конечно сильно разная, но зато проблем с масштабированием нет.
Вариант с СУБД рассматривался, пока отложен из за скорости обработки информации. Хотя это может быть единственным вариантом работать с очень большими объёмами информации.
Кстати, а мультипотоковость еще забыли!
Одно ядро - два потока, да умножить на кол-во ядер - это ж какой профит по скорости должен произойти при оптимизации! Если грамотно тестер сделать.
Но это, возможно, к MQL6 квешн...
Но это, возможно, к MQL6 квешн...
В MQL5 уже это есть...