Сбор тиков по нескольким инструментам.

 

Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).

Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.

Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.

  1. Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
  2. Какова нагрузка на терминал при таких операциях

Выскажитесь по существу вопроса, пожалуйста.

 
avoitenko:

Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).

Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.

Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.

  1. Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
  2. Какова нагрузка на терминал при таких операциях

Выскажитесь по существу вопроса, пожалуйста.

А зачем вешать на каждый инструмент? 

Как я понимаю нам достаточно создать цикли с перебором всех инструментов, после чего внутри цикла делать запрос на подгрузку данных с сервера https://www.mql5.com/ru/docs/series/timeseries_access после чего мы получаем свежие данные по инструменту и кладем их базу.  

 Или как я понял доступ к данным не предполагает получение последнего тика по инструменту? 

Документация по MQL5: Доступ к таймсериям и индикаторам / Организация доступа к данным
Документация по MQL5: Доступ к таймсериям и индикаторам / Организация доступа к данным
  • www.mql5.com
Доступ к таймсериям и индикаторам / Организация доступа к данным - Документация по MQL5
 
И не забыть "макс баров в окне" поменьше сделать, чтобы оперативку не ел :)
Да и кстати, 30 инструментов - это же наверно будет много места занимать, нужно в базе отключать все возможные индексации и т.п.
 
avoitenko:

Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).

Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.

Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.

  1. Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
  2. Какова нагрузка на терминал при таких операциях

Выскажитесь по существу вопроса, пожалуйста.

По поводу все в одном эксперте, заглядываем в документацию. Видим там следующее

Тип

Имя функции

Параметры

Применение

Примечание

int

OnInit

нет

эксперты и индикаторы

Обработчик события Init. Допускается тип возвращаемого значения void.

void

OnDeinit

const int reason

эксперты и индикаторы

Обработчик события Deinit.

void

OnStart

нет

скрипты

Обработчик события Start.

int

OnCalculate


индикаторы

Обработчик события Calculate на всех ценовых данных.

int

OnCalculate


индикаторы

Обработчик события Calculate на одном массиве данных.

В индикаторе не может одновременно присутствовать 2 обработчика Calculate. В этом случае будет работать только обработчик события Calculate на одном массиве данных.

void

OnTick

нет

эксперты

Обработчик события NewTick. Пока идет обраб


Из таблицы становится ясно, что с тиками умеют работать исключительно эксперты. При этом обработчик самих новых тиков как мы помним дополнительных входных параметров не имеет.

Из всего вышесказанного следует что или при текущей архитектуре терминала и модели обработки тиков мы получаем три основные возможности (API пока брать в расчет не будем):

1. Кучу советников, по числу валютных пар с которых собирается инфа (разумеется каждый советник на своем графике)

2. Выбор оптимальной пары с точки зрения частоты поступления тиков (скажем Евро). Установка на нее советника в обработке тиков у которого собираются тики со всех пар.

Тут проблема возникает - Если по Евре не будит тиков то и с других пар тики не соберутся. Но есть вторая сторона этой медали, которая проявится если по Евре будут тики, а по какой-то другой паре нет.

PS

Обе эти модели страдают (будут страдать) дырявостью тиковой истории. 

3. Переделать обработчик события OnTick() таким образом чтобы в него в качестве параметра подавался символ по котором поступил новый тик.

В этом случае один советник достаточно корректно сможет разобрать все новые тики.

PPS

Но и это не спасет от дыр в тиковой истории. Тут возможно придется воспользоваться минутными барами и в случае отсутствия данных переносить минутные бары на тиковую историю (считая что за минуту был только один тик).

С этой стороны, на мой взгляд, проще воспользоваться минутной историей, а выходные и прочие "дыры" в ней при необходимости заштопывать по специальным алгоритмам.

 
mrProF:
И не забыть "макс баров в окне" поменьше сделать, чтобы оперативку не ел :)
Да и кстати, 30 инструментов - это же наверно будет много места занимать, нужно в базе отключать все возможные индексации и т.п.

К чему тикам макс бары? Тики это данные из окна маркет вач. Так что запрашивать их нужно через SymbolInfo.

avoitenko  2010.10.29 17:43

Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).

Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.

Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.

  1. Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
  2. Какова нагрузка на терминал при таких операциях

Выскажитесь по существу вопроса, пожалуйста.


Проще всего работать из OnTimer() тогда будет синхронизация данных, да и дискретность о чём не раз говорил Prival будет постоянной.

 
neftegaz:

А зачем вешать на каждый инструмент? 

Как я понимаю нам достаточно создать цикли с перебором всех инструментов, после чего внутри цикла делать запрос на подгрузку данных с сервера https://www.mql5.com/ru/docs/series/timeseries_access после чего мы получаем свежие данные по инструменту и кладем их базу.  

 Или как я понял доступ к данным не предполагает получение последнего тика по инструменту? 

Как я понимаю цикл этот будет крутиться постоянно? При этом даже если туда внутрь поместить слипеджи с разумным интервалом он все равно будет "холостым".

А о процессоре кто будет думать, Пушкин?

Кроме того это не гарантирует нормального получения необходимой тиковой истории.

PS

Единственное разумное решение (на мой взгляд устраивающего всех) это либо применения третьего варианта из моего предыдущего поста, либо получение всей необходимой информации из внешнего ПО (позволяющего организовать работу в несколько потоков).

Два остальные варианта будут мягко выражаясь НЕ ОЧЕНЬ УДОБНЫМИ.

Идея с циклом возможно и прокатит, но на месте процессора я бы сильно возражал такому решению (если идею я правильно понял).


 
Urain:

Проще всего работать из OnTimer() тогда будет синхронизация данных, да и дискретность о чём не раз говорил Prival будет постоянной.

Можно по таймеру каждую секунду, получаем данные и проверяем перед отправкой, чтобы новые данные не были похожи на уже отправленные, по каждой валютной паре, т.е. изменение данных для Ask или Bid будет считаться новым тиком.

Но иногда, значение котировки может приходить такое же как предыдущее определяя активность на рынке.

Как с этим быть? 

 

Urain:

Проще всего работать из OnTimer() тогда будет синхронизация данных, да и дискретность о чём не раз говорил Prival будет постоянной.

Тогда не будет тиков, а будут минутные интервалы.

Единственным плюсом этого подхода являются следующие вещи:

1. При обрыве связи можно будет восстановить инфу, залатав дыры по минутным барам;

2. Обеспечивается достаточная синхронизация и дискретность;

3. Можно разработать алгоритм позволяющий обойти правило "нет тиков, нет баров";

4. Резко уменьшится объем информации в базе.

 
avoitenko:

Можно по таймеру каждую секунду, получаем данные и проверяем перед отправкой, чтобы новые данные не были похожи на уже отправленные, по каждой валютной паре, т.е. изменение данных для Ask или Bid будет считаться новым тиком.

Но иногда, значение котировки может приходить такое же как предыдущее определяя активность на рынке.

Как с этим быть? 

Я делал похожее в мт4, там была такая схема: есть состояние окна маркет вач, если хоть одна позиция изменилась это считается общим тиком(и сосершенно не важно был ли тик по конкретному инструменту, записывается состояние окна маркетвач на момент события "новый тик"). Получается что в последствии с такими данными можно делать что угодно, любые исследования на мультивалютные стратегии.
 
avoitenko:

Уважаемые коллеги, у меня появилась задача сделать сбор тиков с сохранением в базу данных (Postgress или mySQL).

Меня интересует ваше мнение, только на счет самого сбора. Дальше вроде бы понятно как работать с базой.

Не устраивает то, что при сборе с 20-30 инструментов, советник нужно вешать на график каждого инструмента.

  1. Можно ли это сделать как-нибудь проще и компактнее, например в одном советнике?
  2. Какова нагрузка на терминал при таких операциях

Выскажитесь по существу вопроса, пожалуйста.

1. Можно. Прикладываю скрипт и советник. Запускается на одном графике. Посмотрите, там все просто, до сих пор работало без перебоя. Собираются все тики с инструментов в "обзоре рынка". В рабочем режиме можно включать и отключать тики с инструмента добавляя или удаляя инструмент из "обзора рынка". Я на этом принципе сделал мультивалютник.

2. У меня работает без тормозов, хотя процессор загружает прилично. получал тики более чем с 30 инструментов.

Дополнительно можно собирать еще данные, посмотрите и поймете суть.  Вот такое ноу-хау.

 
avoitenko:

Можно по таймеру каждую секунду, получаем данные и проверяем перед отправкой, чтобы новые данные не были похожи на уже отправленные, по каждой валютной паре, т.е. изменение данных для Ask или Bid будет считаться новым тиком.

Но иногда, значение котировки может приходить такое же как предыдущее определяя активность на рынке.

Как с этим быть? 

никак = это и есть текущая активность на рынке, если у Вас задача фильровать тики, значит фильтруйте и пишите изменения тиков если нет, то пишите все

по сабжу один вопрос - насколько тиковые котировки МТ5 соответсвуют МТ4 - кто нить сравнивал? на альпари есть демо МТ5 и демо МТ4 - есть разница в тиках, один два пропущенный тик в минуту не страшен

ЗЫ: интересная задача, мне тож предстоит переписать с МТ4 в МТ5