Нужно ли добавить в MQL5 нативные функции обращения в MySQL базу данных(например)? - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Про нейронные сети слыхал? Так вот для хранения образов и анализа БД необходима.
да и в мою деревню провели интернет
для форекса нейросети помещаются в 1 мб вместе с данными, хотя смотря с какой фанатичностью считать, если по тикам считать то да
Например, я сдампил историю за 2012-2013гг. в Мускул по всем интересующим парам и за пару запросов вывел закономерности и ошибки реализации, которые с помощью MQL узнать очень сложно из-за отсутствии реализации. Мне 2 простых SQL-запроса сэкономили несколько дней на поиск бага.
не проще ли было fann или mt4r использовать
Незнание SQL - это огромное упущение для трейдера.
как знание СУБД поможет трейдеру???
Сам SQL стандартизирован, поэтому разница только в обслуживании серверов БД и в нескольких фишках.
Для большинства PostgreSQL или MySQL хватит полностью. Основная разница в репликации БД на несколько серверов, которую использовать точно будут только единицы.
Кстати, из-за санкций Оракла некоторые меняют на открытый PostgreSQL ;)
санкции? три хаха - в роснефти, в РЖД как стоял например САП так и стоит, в ВТБ, МТС оракл как платформа корп.приложений и ХД как стоял так и стоит
По сути, при наличии WebRequest ничего не нужно.
Кидать запросы из терминала при многопользовательском решении напрямую в БД не всегда хорошо. Для нормального серверного решения нужны как минимум очереди (RabbitMQ|Beanstalkd|Gearmand и тд) которые исключат пики нагрузки. К примеру скинуть логи и "сформировать отчет" - достаточно ресурсоемкие операции. Поэтому под WebRequest лучше сделать небольшое собственное API к серверным мощностям (а там хочешь MariaDb, хочешь MongoDb и тд.). Самый простой вариант на коленке вообще без апи - SQL запрос прокидывать в одном из полей WebRequesta.
Так что особого смысла городить свой протокол только к MySQL не нужно. Ну если только для "быстрого старта" при необходимости SQL запросов. Хотя я очень сомневаюсь в устойчивости community сервера MySQL если туда начнут сливать всё. Опять понадобятся очереди и тд и тп.
transcendreamer:
для форекса нейросети помещаются в 1 мб вместе с данными, хотя смотря с какой фанатичностью считать, если по тикам считать то да
1МБ - конечный объем - в это поверю.
А для поиска наилучшего результата и 2ГБ может не хватать.
transcendreamer:
не проще ли было fann или mt4r использовать
Проще тогда уже R + RMySQL напрямую заюзать, а не через костыли.
transcendreamer:
как знание СУБД поможет трейдеру???
СУБД вообще-то разные есть, а я именно язык SQL указал.
Может вопрос: "Как знание языка программирования запросов может помочь программисту?"
Ответ: Никудышному программисту действительно не поможет, а профи получит профит.
Если знания о СУБД ограничены "Я слыхал, что Мускул используется для сайтов.", то я даже этого человека за программиста не посчитаю.
transcendreamer:
санкции? три хаха - в роснефти, в РЖД как стоял например САП так и стоит, в ВТБ, МТС оракл как платформа корп.приложений и ХД как стоял так и стоит
http://www.cnews.ru/news/top/index.shtml?2015/02/10/592592
По сути, при наличии WebRequest ничего не нужно.
1МБ - конечный объем - в это поверю.
А для поиска наилучшего результата и 2ГБ может не хватать.
а я считал что все промежуточные расчеты выгоднее в оперативной памяти держать - так и быстрее
возможно у Вас какая-то большая задача, 2 ГБ это конечно объем, хотя ноутбуки уже меньше 8 ГБ редкостью становятся
что же Вы такое считаете..... без сарказма, просто интересно..... обычно же нужно подобрать десяток переменных на истории, а у Вас что-то явно большое
Проще тогда уже R + RMySQL напрямую заюзать, а не через костыли.
тогда отдельно нужно еще решать спряжение МТ с R
MT4R позволяет прямо из MQL отправлять команды в R и получать обратно, что удобно
СУБД вообще-то разные есть, а я именно язык SQL указал.
Может вопрос: "Как знание языка программирования запросов может помочь программисту?"
Ответ: Никудышному программисту действительно не поможет, а профи получит профит.
из программирования напрямую профит не получится, только если индикаторы не продавать на маркете ))))))
в основе должна лежать определенная торговая идея, без этого нейросеть и база данных не поможет
хотя можно конечно численным перебором найти набор значений для бай-селл и сделать черный ящик
Если знания о СУБД ограничены "Я слыхал, что Мускул используется для сайтов.", то я даже этого человека за программиста не посчитаю.
http://www.cnews.ru/news/top/index.shtml?2015/02/10/592592
сколько помню все время ведутся эти разговоры о свободном ПО только ничего не меняется с начала 2000ых
ведь интеграторам интереснее работать с жирными вендорами, заодно приторговывая лицензиями
все эти ланиты, айбиэсы, сапраны... они ставят маржу до 30%, менеджмент тупо не дает удешевить контракт, приходится даже вендора просить о скидке
плюс сказывается что заказчики выбирающие фривар обычно люто экономят на всем, поэтому и на консалте с них мало что соберешь
да и вообще фривар это обычно госуха, а госуха = вынос мозга, запредельные требования, запредельная грань безопасности и запредельно смешной бюджет проекта
плюс неадекватные деды в айти... например требование под систему бюджетирования на соответствие требованиям под системы видеонаблюдения! каково?
и еще хрен туда пробьешься без аккредитации, только с "правильным" партнером который отожрет треть бюджета... поэтому госы и около-госы не любят
а что самое смешное фриварная аналитика/ХД/приложения настолько слабы что даже даром не нужны
поэтому все все равно сидят на сапе, оракле, когносе и тд по списку, платят огромные бабки за лицензии а потом козлят и не могут это внедрить годами
росатом например - они сами откровенно улыбались когда называли бюджет в 400М но реально там работы было на 800+ (это sap erp)
связываться с таким заказчиком безумие
money talks
а я считал что все промежуточные расчеты выгоднее в оперативной памяти держать - так и быстрее
возможно у Вас какая-то большая задача, 2 ГБ это конечно объем, хотя ноутбуки уже меньше 8 ГБ редкостью становятся
что же Вы такое считаете..... без сарказма, просто интересно..... обычно же нужно подобрать десяток переменных на истории, а у Вас что-то явно большое
Действительно интересно?
У нас есть CopyRates(), который просто выдаст историю за определенный промежуток.
Дальше мне нужно модифицировать эти значения для удобства обработки - это тоже на MQL.
А теперь мне, ради исследовательского интереса, захотелось сгруппировать по определенному критерию и отсортировать по полю TREND.
Вариант MQL: Задача для БД, но MQL - язык программирования, поэтому на MQL придется реализовать примитивную БД, чтобы решить эту задачу.
Вариант SQL:
Ставим MySQL или PostgreSQL. И загоняем туда подготовленные на MQL данные (можно в виде CSV).
И посылаем любые запросы. Например для MySQL:
chromosome,
(chromosome & ((1 << (5 * 4)) - 1)) AS chrombits,
CAST(MIN(trend) AS DECIMAL (5 , 2 )) AS mintrend,
CAST(MAX(trend) AS DECIMAL (5 , 2 )) AS maxtrend,
CAST(AVG(trend) AS DECIMAL (5 , 2 )) AS avgtrend,
CAST((MAX(trend) - MIN(trend)) AS DECIMAL (5 , 2 )) AS divtrend,
GROUP_CONCAT(CONCAT_WS('=',
symbol,
CAST(trend AS DECIMAL (5 , 2 )))
ORDER BY trend DESC
SEPARATOR ' '),
COUNT(*) AS `count`
FROM
history
GROUP BY chrombits
ORDER BY `divtrend` DESC , `count` DESC;
При знании SQL такой запрос составляется очень просто.
Желание реализовать на MQL тоже самое еще не пропало? :D
transcendreamer:
тогда отдельно нужно еще решать спряжение МТ с R
MT4R позволяет прямо из MQL отправлять команды в R и получать обратно, что удобно
А зачем MT4R, когда все нужные данные в MySQL?
MT4R может понадобится только на последней стадии, когда стратегия на истории в прошлом уже наметилась.
А графики в R можно строить и по данным MySQL.
transcendreamer:
сколько помню все время ведутся эти разговоры о свободном ПО только ничего не меняется с начала 2000ых
ведь интеграторам интереснее работать с жирными вендорами, заодно приторговывая лицензиями
все эти ланиты, айбиэсы, сапраны... они ставят маржу до 30%, менеджмент тупо не дает удешевить контракт, приходится даже вендора просить о скидке........
Вообще-то я - программист, а не руководитель компании, который погряз в финансовых отчетах.
Для программиста открытый код - мега аргумент, а что там думает руководитель или заказчик... - его проблемы.
Действительно интересно?
У нас есть CopyRates(), который просто выдаст историю за определенный промежуток.
Дальше мне нужно модифицировать эти значения для удобства обработки - это тоже на MQL.
А теперь мне, ради исследовательского интереса, захотелось сгруппировать по определенному критерию и отсортировать по полю TREND.
Вариант MQL: Задача для БД, но MQL - язык программирования, поэтому на MQL придется реализовать примитивную БД, чтобы решить эту задачу.
Вариант SQL:
Ставим MySQL или PostgreSQL. И загоняем туда подготовленные на MQL данные (можно в виде CSV).
И посылаем любые запросы. Например для MySQL:
chromosome,
(chromosome & ((1 << (5 * 4)) - 1)) AS chrombits,
CAST(MIN(trend) AS DECIMAL (5 , 2 )) AS mintrend,
CAST(MAX(trend) AS DECIMAL (5 , 2 )) AS maxtrend,
CAST(AVG(trend) AS DECIMAL (5 , 2 )) AS avgtrend,
CAST((MAX(trend) - MIN(trend)) AS DECIMAL (5 , 2 )) AS divtrend,
GROUP_CONCAT(CONCAT_WS('=',
symbol,
CAST(trend AS DECIMAL (5 , 2 )))
ORDER BY trend DESC
SEPARATOR ' '),
COUNT(*) AS `count`
FROM
history
GROUP BY chrombits
ORDER BY `divtrend` DESC , `count` DESC;
При знании SQL такой запрос составляется очень просто.
Желание реализовать на MQL тоже самое еще не пропало? :D
да, понятно, MQL здесь не подходящий инструмент
я бы скорее всего в экселе бы колдовал (до определенного объема конечно), но это потому что я не программист а аналитик больше
а судя по названию переменных это не нейросеть а ГА
А зачем MT4R, когда все нужные данные в MySQL?
MT4R может понадобится только на последней стадии, когда стратегия на истории в прошлом уже наметилась.
А графики в R можно строить и по данным MySQL.
я думал что это в рамках исследования, т.е. один раз нужно, не в онлайне считать
Вообще-то я - программист, а не руководитель компании, который погряз в финансовых отчетах.
Для программиста открытый код - мега аргумент, а что там думает руководитель или заказчик... - его проблемы.
к сожалению, из моего опыта, корпоративный заказчик меньше всего слушает техническое обоснование
как правило заказчик вообще не касается деталей и может требовать все что угодно, в том числе и противоречивые требования выдвигать
и тут нужно уметь корректно извернуться чтобы не сказать "нет" потому что это может похерить весь проект и не обещать невозможного
в большинстве случаев проекты заваливаются именно по вине заказчика
либо на этапе сбора ТЗ он наврал и переврал, либо на этапе приемки он вспоминает что он совсем другое имел в виду и вообще концепция поменялась
задача консалтера - грамотно показать заказчику что он дурак но так чтобы он не обиделся и выбить доп.бюджет на доработку разумеется )))
transcendreamer:
я бы скорее всего в экселе бы колдовал (до определенного объема конечно), но это потому что я не программист а аналитик больше
А желание после R запускать обычный Калькулятор осталось?
БД с SQL - это такой же мощный аналитический инструмент, как R. А Excel - Калькулятор :D
Даже RMySQL имеет преимущество в скорости анализа против MT4R.
При отсутствии желания изучать новое мои аргументы теряют смысл...
Да, и мне не понятно: зачем сюда приплели проблемы руководителей/заказчиков? Они сами не понимают, чего хотят. К этой теме их "желания" точно не относятся. В любом случае будут пользоваться тем, что дадут или доплатят за разработку драйвера для подключения к коммерческой БД.
Поддержки свободных БД - более чем достаточно.
А желание после R запускать обычный Калькулятор осталось?
признаюсь, за время консалтерской практики я так привык к экселю, поэтому по привычке запускаю эксель )))))
что-то быстро посчитать очень удобно, все главные вещи по хоткеям
а еще мне нравится statistica, я начинал пользоваться еще с 5й версии
сейчас новомодная штука появилась - rapidminer, но Вы наверняка про нее знаете
БД с SQL - это такой же мощный аналитический инструмент, как R. А Excel - Калькулятор :D
все-таки БД для хранения-обработки а не аналитический инструмент
Эксель - калькулятор, согласен, но чертовский удобный калькулятор
Даже RMySQL имеет преимущество в скорости анализа против MT4R.
не спорю, наверняка быстрее
при этом если бы МТ имел коннектор в БД и мог читать напрямую то для Ваших задач было бы идеально
При отсутствии желания изучать новое мои аргументы теряют смысл...
Да, и мне не понятно: зачем сюда приплели проблемы руководителей/заказчиков? Они сами не понимают, чего хотят. К этой теме их "желания" точно не относятся. В любом случае будут пользоваться тем, что дадут или доплатят за разработку драйвера для подключения к коммерческой БД.
Поддержки свободных БД - более чем достаточно.
тема с БД для МТ может иметь значение если метаквоты будут расширять позиционирование МТ для биржевых задач, пользователей это вряд ли коснется, а серверная часть МТ наверняка должна будет работать в связке с БД брокера причем в жестком онлайне, причем если коннекторы встраивать в стандартную поставку МТ это увеличит стоимость лицензий, которые и так немаленькие (насколько я знаю), хотя и не такие безумно дорогие как решения sap/sas/... а если не встраивать то решения интеграции лежит на заказчике и тут возможны косяки, поскольку стандартное решение всегда надежнее, с другой стороны сколько я видел коммерческих коннекторов и шин данных - в большинстве они представляют собой такое убожество что даже просто на уровне обмена файлами намного проще чем через эти коннекторы, причем опять же косяки с нестандартными таблицами они никак не страхуют, а стоимость коннекторов бывает достигает до 30% от основного решения в "пакете"
что касается заказчиков то сейчас это раньше заказчик был лох, теперь заказчик другой пошел, то есть в техническом отношении он все тот же лох, но теперь фишку сечет и просто так ему не "впаришь" лишний коннектор, он тут же начнет задавать вопросы, да еще и по плану проекта все резервы порежет... перелом поведения заказчиков случился где-то в районе 2005 года +/- пара лет, с другой стороны эпические продажи все равно еще случаются, например тот же sap умудрился продаться в минобороны (они даже раскрыли исходные коды для этого!) а в прошлом году в ростелеком (это была сделка года)
MySQL, SQL Server, Постгре, Оракл - добавляйте все! SQL Server особливо.