Сбор тиков по нескольким инструментам.
Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).
Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.
Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.
- Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
- Какова нагрузка на терминал при таких операциях
Выскажитесь по существу вопроса, пожалуйста.
А зачем вешать на каждый инструмент?
Как я понимаю нам достаточно создать цикли с перебором всех инструментов, после чего внутри цикла делать запрос на подгрузку данных с сервера https://www.mql5.com/ru/docs/series/timeseries_access после чего мы получаем свежие данные по инструменту и кладем их базу.
Или как я понял доступ к данным не предполагает получение последнего тика по инструменту?
- www.mql5.com
Да и кстати, 30 инструментов - это же наверно будет много места занимать, нужно в базе отключать все возможные индексации и т.п.
Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).
Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.
Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.
- Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
- Какова нагрузка на терминал при таких операциях
Выскажитесь по существу вопроса, пожалуйста.
По поводу все в одном эксперте, заглядываем в документацию. Видим там следующее
Тип |
Имя функции |
Параметры |
Применение |
Примечание |
int |
нет |
эксперты и индикаторы |
Обработчик события Init. Допускается тип возвращаемого значения void. |
|
void |
const int reason |
эксперты и индикаторы |
Обработчик события Deinit. |
|
void |
нет |
скрипты |
Обработчик события Start. |
|
int |
индикаторы |
Обработчик события Calculate на всех ценовых данных. |
||
int |
индикаторы |
Обработчик события Calculate на одном массиве данных. В индикаторе не может одновременно присутствовать 2 обработчика Calculate. В этом случае будет работать только обработчик события Calculate на одном массиве данных. |
||
void |
нет |
эксперты |
Обработчик события NewTick. Пока идет обраб |
Из таблицы становится ясно, что с тиками умеют работать исключительно эксперты. При этом обработчик самих новых тиков как мы помним дополнительных входных параметров не имеет.
Из всего вышесказанного следует что или при текущей архитектуре терминала и модели обработки тиков мы получаем три основные возможности (API пока брать в расчет не будем):
1. Кучу советников, по числу валютных пар с которых собирается инфа (разумеется каждый советник на своем графике)
2. Выбор оптимальной пары с точки зрения частоты поступления тиков (скажем Евро). Установка на нее советника в обработке тиков у которого собираются тики со всех пар.
Тут проблема возникает - Если по Евре не будит тиков то и с других пар тики не соберутся. Но есть вторая сторона этой медали, которая проявится если по Евре будут тики, а по какой-то другой паре нет.
PS
Обе эти модели страдают (будут страдать) дырявостью тиковой истории.
3. Переделать обработчик события OnTick() таким образом чтобы в него в качестве параметра подавался символ по котором поступил новый тик.
В этом случае один советник достаточно корректно сможет разобрать все новые тики.
PPS
Но и это не спасет от дыр в тиковой истории. Тут возможно придется воспользоваться минутными барами и в случае отсутствия данных переносить минутные бары на тиковую историю (считая что за минуту был только один тик).
С этой стороны, на мой взгляд, проще воспользоваться минутной историей, а выходные и прочие "дыры" в ней при необходимости заштопывать по специальным алгоритмам.
И не забыть "макс баров в окне" поменьше сделать, чтобы оперативку не ел :)
Да и кстати, 30 инструментов - это же наверно будет много места занимать, нужно в базе отключать все возможные индексации и т.п.
К чему тикам макс бары? Тики это данные из окна маркет вач. Так что запрашивать их нужно через SymbolInfo.
Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).
Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.
Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.
- Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
- Какова нагрузка на терминал при таких операциях
Выскажитесь по существу вопроса, пожалуйста.
Проще всего работать из OnTimer() тогда будет синхронизация данных, да и дискретность о чём не раз говорил Prival будет постоянной.
А зачем вешать на каждый инструмент?
Как я понимаю нам достаточно создать цикли с перебором всех инструментов, после чего внутри цикла делать запрос на подгрузку данных с сервера https://www.mql5.com/ru/docs/series/timeseries_access после чего мы получаем свежие данные по инструменту и кладем их базу.
Или как я понял доступ к данным не предполагает получение последнего тика по инструменту?
Как я понимаю цикл этот будет крутиться постоянно? При этом даже если туда внутрь поместить слипеджи с разумным интервалом он все равно будет "холостым".
А о процессоре кто будет думать, Пушкин?
Кроме того это не гарантирует нормального получения необходимой тиковой истории.
PS
Единственное разумное решение (на мой взгляд устраивающего всех) это либо применения третьего варианта из моего предыдущего поста, либо получение всей необходимой информации из внешнего ПО (позволяющего организовать работу в несколько потоков).
Два остальные варианта будут мягко выражаясь НЕ ОЧЕНЬ УДОБНЫМИ.
Идея с циклом возможно и прокатит, но на месте процессора я бы сильно возражал такому решению (если идею я правильно понял).
Проще всего работать из OnTimer() тогда будет синхронизация данных, да и дискретность о чём не раз говорил Prival будет постоянной.
Можно по таймеру каждую секунду, получаем данные и проверяем перед отправкой, чтобы новые данные не были похожи на уже отправленные, по каждой валютной паре, т.е. изменение данных для Ask или Bid будет считаться новым тиком.
Но иногда, значение котировки может приходить такое же как предыдущее определяя активность на рынке.
Как с этим быть?
Urain:
Проще всего работать из OnTimer() тогда будет синхронизация данных, да и дискретность о чём не раз говорил Prival будет постоянной.
Тогда не будет тиков, а будут минутные интервалы.
Единственным плюсом этого подхода являются следующие вещи:
1. При обрыве связи можно будет восстановить инфу, залатав дыры по минутным барам;
2. Обеспечивается достаточная синхронизация и дискретность;
3. Можно разработать алгоритм позволяющий обойти правило "нет тиков, нет баров";
4. Резко уменьшится объем информации в базе.
Можно по таймеру каждую секунду, получаем данные и проверяем перед отправкой, чтобы новые данные не были похожи на уже отправленные, по каждой валютной паре, т.е. изменение данных для Ask или Bid будет считаться новым тиком.
Но иногда, значение котировки может приходить такое же как предыдущее определяя активность на рынке.
Как с этим быть?
Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).
Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.
Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.
- Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
- Какова нагрузка на терминал при таких операциях
Выскажитесь по существу вопроса, пожалуйста.
1. Можно. Прикладываю скрипт и советник. Запускается на одном графике. Посмотрите, там все просто, до сих пор работало без перебоя. Собираются все тики с инструментов в "обзоре рынка". В рабочем режиме можно включать и отключать тики с инструмента добавляя или удаляя инструмент из "обзора рынка". Я на этом принципе сделал мультивалютник.
2. У меня работает без тормозов, хотя процессор загружает прилично. получал тики более чем с 30 инструментов.
Дополнительно можно собирать еще данные, посмотрите и поймете суть. Вот такое ноу-хау.
Можно по таймеру каждую секунду, получаем данные и проверяем перед отправкой, чтобы новые данные не были похожи на уже отправленные, по каждой валютной паре, т.е. изменение данных для Ask или Bid будет считаться новым тиком.
Но иногда, значение котировки может приходить такое же как предыдущее определяя активность на рынке.
Как с этим быть?
никак = это и есть текущая активность на рынке, если у Вас задача фильровать тики, значит фильтруйте и пишите изменения тиков если нет, то пишите все
по сабжу один вопрос - насколько тиковые котировки МТ5 соответсвуют МТ4 - кто нить сравнивал? на альпари есть демо МТ5 и демо МТ4 - есть разница в тиках, один два пропущенный тик в минуту не страшен
ЗЫ: интересная задача, мне тож предстоит переписать с МТ4 в МТ5
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).
Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.
Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.
Выскажитесь по существу вопроса, пожалуйста.