Проблема с историей - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как вариант ...
Может быть кешировать результаты сделок на локальной машине, аналогично кешированию ценовых данных?
Это бы решило все проблемы.
Эксперт имел бы всю историю, сервера выдавали бы результаты только последних сделок.
История сделок ведь меняться не может?
Как вариант ...
Может быть кешировать результаты сделок на локальной машине, аналогично кешированию ценовых данных?
Это бы решило все проблемы.
Эксперт имел бы всю историю, сервера выдавали бы результаты только последних сделок.
История сделок ведь меняться не может?
Во первых, на стороне клиента может стоять флаг "не хранить персональную информацию".
Во вторых - кеш не гарантирует достоверности(или его придется реализовать с гарантией, но это дополнительные трудности), кеш будет постоянно перезагружаться. Как минимум - на каждом рестарте терминала.
В третьих - история может меняться без участия терминала.
У нас есть кеширование запросов account history в сервере на небольшую глубину, что позволяет относительно безболезненно выдавать отчеты при каждом подключении терминала. Но делать кеш на полную глубину - это слишком накладно по ресурсам.
К сожалению, наша позиция прямо противоположна желанию "хочу всю историю по любому запросу и когда хочу".
Если логика конкретного эксперта не меняется, то и хранить всю выборку нет смысла.
Назовите файл poundMM.data и пишите туда не историю по сделкам эксперта, а только данные для последующего анализа ну и результаты торговли ;)
Успехов.
Во вторых - кеш не гарантирует достоверности(или его придется реализовать с гарантией, но это дополнительные трудности), кеш будет постоянно перезагружаться. Как минимум - на каждом рестарте терминала.
В третьих - история может меняться без участия терминала.
У нас есть кеширование запросов account history в сервере на небольшую глубину, что позволяет относительно безболезненно выдавать отчеты при каждом подключении терминала. Но делать кеш на полную глубину - это слишком накладно по ресурсам.
К сожалению, наша позиция прямо противоположна желанию "хочу всю историю по любому запросу и когда хочу".
Наверное мы не поняли друг друга.
Вы ведь храните на стороне клиента ценовые данные?
Там по 1 символу может быть больше 100К баров?
Символов в этом кеше может быть много?
Эти бары обнажды сформировавшись больше не меняются?
При запуске терминала в него подгружаются бары сформированные за время, пока он был выключен?
Чем это отличается от моего предложения хранить историю сделок в таком же кеше?
- Число трейдов на счете будет много меньше 100К.
- Будет только 1 история сделок (а не много, как с ценами).
- Однажды сформировавшись результаты трейдов больше не меняются.
- При загрузке терминала в него подгружаются сделки совершенные за время, пока терминал был выключен.
Если вы решили проблемы с хранением и подкачкой ценовой истории,
то хранение и подкачка истории операций получается даже немного проще.
----------------------------------------------------------
Я все это пишу не потому, что мне эта история очень нужна.
Мне она не нужна вовсе ...
Я пишу это потому, что текущий вариант реализации на мой взгляд очень неудачный.
Чем меньше побочных эффектов в системе, тем она лучше.
В данном случае невинные действия наблюдателя (изменил глубину истории в закладке)
могут сломать работу некоторых скриптов.
Не забывайте, запрос Account History (особенно по всей истории) - это очень серьезная и затратная выборка из базы данных. Если каждый терминал начнет по запросам экспертов бездумно дергать базу сделок, то о высокой производительности придется забыть. Конечно же, на это мы никогда не согласимся. Чтобы предсказать наш ответ и его обоснование - думайте, пожалуйста, о технической стороне дела.
Кстати, для манименеджмента в 80% случаев достаточно знать всего лишь несколько последних сделок.
Принимать какие-то решения с проходом на всю глубину - это явно лишнее.
С одной стороны, Вы, конечно, правы. Это МОЖЕТ быть долго. Особенно, если скальпер решит посылать запрос на каждом тике. С другой стороны, можно кешировать данные: при первом за сессию вызове функция получает доступ ко всей истории (и если программиста предупредить в хелпе, что это медленно, то он сделает этот вызов из init) и хранит ее в локальной базе данных, а при последующем запросе, получает только обновления. Собственно, Ваше предложение (выше) - это вариант такого подхода, только в моем варианте программа сама заботится о периоде, за который запрашиваются данные, освобождая программиста от необходимости ломать над этим голову.
Альтернатива, некий компромис, это быстрые stored функции, типа GetExpertProfit(magic), такие запросы сервер будет обрабатывать достаточно быстро. Но честно говоря, это полумера.
Насчет мани менеджмента - не согласен. То есть, да, 20 - 80 и все такое. Но МТ4 - это "взрослая" платформа, и она должна быть готова работать и с "20". Кроме того, вот вам, просто для примера два варианта, когда "несколько последних сделок" не будет работать с нынешней реализацией работы МТ с историей:
1. Система торгует редко. "Несколько последних сделок" были давно. С другой стороны, на том же счету висит скальпинговый эксперт, создающий в окне Account History множество дополнительных строк (buy, sell, cancel...). Таким образом, с точки зрения человека, хорошо бы показывать только последний день или несколько дней, но никак не год. С точки же зрения первого эксперта - нужен последний год, иначе "несколько последних сделок" останутся за кадром.
Конечно, можно предложить открыть два аккаунта (10, 20...) - для каждого эксперта в отдельности. Но, повторюсь, МТ4 - это "взрослая" система.
2. Несколько раз встречал на форумах варианты ММ, когда размер лота рассчитывается исходя из некоего извращенного варианта мартингейла, а именно, по кривой эквити строятся скользящие средние, ищутся пересечения, дивергенции и т.п. Для такого ММ нужно МНОГО последних сделок.
Я бы все-таки высказался за вариант с кешированием, если, конечно, не найдется лучшего варианта, до которого я не додумался.
С уважением,
Кварк
Как вариант ...
Может быть кешировать результаты сделок на локальной машине, аналогично кешированию ценовых данных?
Это бы решило все проблемы.
Эксперт имел бы всю историю, сервера выдавали бы результаты только последних сделок.
История сделок ведь меняться не может?
Забавно. Я прочитал Renat`овский пост, написал ответ о кешировании, затем прочитал следующий - Ваш - пост. Тоже о кешировании :) Виртуально пожимаю руки.
Насчет последних сделок - тут логика может быть довольно хитрой. Вдруг закроется старая сделка? Так что надо хорошо продумать, что и как обновлять. Слать эти обновления просто так, наверное, не надо, а вот по запросу - можно.
Если на стороне клиента может стоять флаг "не хранить персональную информацию", то это его, клиента, проблемы. Он же имеет возможность этот флаг отключить, так?
Не забывайте, запрос Account History (особенно по всей истории) - это очень серьезная и затратная выборка из базы данных.
Не согласен категорически. Stored процедура, простой запрос, без наворотов - миллисекунды.
К тому же, что бы ни происходило с базой данных, это изменение идет через ваш сервер, через Database Engine. И оно может дублироваться, посылаться на сторону клиента. Скажем, закрылся ордер по стопу, клиенту посылается строчка "закрыт ордер, тикет такой-то, время, прибыль...". На фоне общего потока котировок - мизерный объем.
Конечно, SQL Server или Oracle у клиента не поставишь, а значит, возникнут вопросы, как синхронизировать базу данных на стороне клиента, и настоящую, у брокера. Но ведь клиент ничего не обязан рассчитывать! Скажем, есть данные на стороне брокера по данному ордеру. Открыт, модифицирован - закрыт. Модификация нас не интересует. Открыт - закрыт - это одна строчка в базе данных, ее мы и посылаем клиенту, и она просто переписывает то, что у него есть по данному тикету.
Я, конечно, понимаю, что это лишь схема, причем наверняка в ней можно найти проблемы. Но а) я думаю, она все-таки может работать, б) она лучше, чем нынешнее положение и в) поработав с МТ4, я убедился в высоком уровне его разработчиков.
С уважением,
Кварк
Как вариант кеширования. На стороне клиента храним простенькую базу данных, одна запись на один ордер. На стороне сервера, каждому ордеру ставим в соответствие timestamp - время последнего изменения. Когда клиент запрашивает что-то, связанное с историей, на первый, после перезапуска терминала, запрос посылается вся таблица. На следующие - только те ордера, timestamp для которых больше времени последнего запроса пользователя. Это поиск по одному ключу, очень быстро.
С уважением,
Кварк
Гарантий никаких! Все может сто раз поменяться без клиента - это я бы повторил сто раз.
Хранить персональную информацию на стороне клиента - явный пробел в защите.
Клиент с отключенным режимом сохранения персональной информации, но с полным правом запрашивать историю, может принести серьезный вред серверу.
Если бы работа сервера была в выдаче истории сделок, то это не так страшно. Но задача сервера в быстрой и качественной обработке _тысяч_ (до 10000) одновременно подключенных пользователей. Естественно, попутно сжимая весь контент и шифруя трафик.
Миллисекунды тут, миллисекунды там, миллисекунды еще много где и все - производительности как не бывало.