SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
Блог им. kvazar
Нужен опытнейший программист (C#, MS SQL, VBA)
- 19 мая 2020, 17:50
- |
Интересуют консультации платные по договоренности и ответы на разные вопросы. Если алготрейдер, еще лучше.
Например, скорость работы различных БД, оптимизация запросов, индексация, тонкости работы с Квиком.
Кодить не потребуется, я сам (может немного с помощью). Общение Skype.
Например, скорость работы различных БД, оптимизация запросов, индексация, тонкости работы с Квиком.
Кодить не потребуется, я сам (может немного с помощью). Общение Skype.
теги блога kvazar
- odbc
- QUIK
- S&P500 фьючерс
- StartTrack
- vba
- алготрейдинг
- базы данных
- блокировка сайта
- брокеры
- Вакансия
- займы
- инвестиции
- квик глюки
- комиссия брокера
- консультации
- лчи 2012 смартлаб
- маркет дата
- математическое ожидание
- Ментор
- опрос
- оптимальное f
- офф топ
- оффтоп
- Ральф Винс
- реклама. оффтоп
- рецензия на книгу
- роботостроительство
- торговля
- торговые алгоритмы
- Торговые роботоы
- торговые роботы
- торговый робот
- тороговые роботы
- Финам
- цикл жизни
- что почитать
- юмор
А с компом у вас и так все ОК.
Определенно написать на С#/VB, а часть на С++.
до 16gb.
Одно это добавит скорости.
И что удивительно и неожиданно, надежности.
(своп до сих пор, несмотря на 25 лет использования в ос подглючивает)
опять-же на квик 64 бит переходит.
У меня вот всего 4 ГБ (несчастный случай, сдох комп, и срочно на Авито купил новый-ненадеванный, других не было, а через неделю появился — локти кусал) — и то на все хватает. Квик подтормаживает, но здесь не в памяти дело, ее еще 20% остается, и проц не загружен.
Квик х64.
а через стенку, в другой квартире, у 12 летнего гейсера 32 гига чтобы было.
И что у вас нет запасного терминала в виде дешевого ноута тоже очень грустно.
А еще это значит что ни о каких бд промышленно используемых вы в реале не видели.
Потому что железо сейчас очень дешевое.
А квалификация хорошо оплачивается. даже в рф.
С Квик вообще все интересно, свободная память есть, процессор свободен, а Квик подвисает. Че-то в нем не так.
И воще, я IT специалист, а сапожнику положено без сапог.)
Это такое.
Он может свопить и показывать свободную память.
+ то-же dde
Работает в ТОМ ЖЕ потоке.
И если стучится в dde сервер, в виде excel, пока тот из свапа выползет фрезится.
А по памяти это не видно навскидку.
Ок надо, )
А вообще б/у покупать хорошо. Кому-то дарят на ДР, он на Авито продает ненужное новье с гарантией в 2 раза дешевле.
Памяти нужно на разработку как минимум 16gb
Тем более что это дешево. 100$ 16gb
А вот память не апгрейдится, впаяна в сис. плату.
А Васька слушает, да ест. Тем временем моя сделка на стрэнглах РТС вверх ползет.)) Пустячок, а приятно.
Он на этом компьютере не только стратегию крутит.
но и использует его как рабочую станцию.
Так что 8gb ему мало, это видно по скриншоту.
Самое дешевое и надежное добить памяти до 16 gb.
Как минимум.
Все станет надежнее.
Даже квик с dde.
И акцесс весь кеш переселит в память и вообще не будет читать диск.
Только писать.
По факту просто добив памяти получаешь надежность и отзывчивость.
Очень дешево.
+ открывает путь к безопасности и надежности через виртуализацию.
( Когда бот работает в виртуалке в отдельной чисто системе)
Которую можно снешшопить.
При обновлении квика.
И если что пойдет не так, обратно восстанавливать.
+ которую хакнуть будет тяжело.
потому что вылезти из броузера будет недостаточно.
нужно еще в чистую виртуалку зайти.
а через стенку, в другой квартире, у 12 летнего гейсера 32 гига чтобы было.
И что у вас нет запасного терминала в виде дешевого ноута тоже очень грустно.
Опытнейший программист не станет консультировать так абстрактно.
Потому что понимает, что очень многое зависит от архитектуры приложения, используемых фреймворков и библиотек.
Можно и на C++ так наговнокодить, что VBA окажется быстрее.
Разбирать нужно что-то конкретное.
Иначе в этом нет почти никакого смысла.
kvazar, базы данных — это не к программисту.
Это к DBA(DataBase Administrator).
При этом достаточно базовых знаний, которые есть в массе книг.
Разделение на нормальные формы, создание правильных индексов, работа с SQL Query Analyzer.
Но самое занятное, что во многих случаях базы данных просто не нужны.
Либо нужны но в гораздо меньших объёмах.
Не редко их используют не по назначению.
Самый первый вопрос: «Что вы храните в базе данных ?»
kvazar, хорошо.
Основной объём и проблемы дают тики.
Идём дальше.
За какой период хранится тиковая история и по какому количеству инструментов?Зачем вам вообще тиковая история и можно ли обойтись бОльшим фреймом или меньшим объёмом тиков ?
kvazar, возьмём фьючерс на индекс РТС(RIM0).
За первый час пролетело 44308 сделок.
Это совершенно не много.
При учёте того, что время от времени очищать старые данные.
MSSQL достаточно просто потянет данную задачу.
Если нужна супер скорость, то можно создать in-memory-table.
Скажу больше, подобный объём можно хранить и обрабатывать внутри программы.
Хоть в массивах, хоть в хеш-таблицах.
Данные в access поставляются через ODBC ?
Сколько оперативки на компе ?
Какой процессор ?
В день записывается строк с расчетами около 35000-40000, самих запросов больше в день, есстественно.
kvazar, горячие/актуальные данные правильнее кешировать.
Т.е. хранить внутри программы.
Либо где-то в оперативной памяти.
По ним вести расчёты и не совершать избыточную работу.
Записывая и читая по 100 раз из базы(ибо это дисковые операции).
Время от времени скидывать пачками(bulk insert) данные в базу(если оно вообще нужно).
Можно поизвращаться с in-memory-table.
https://docs.microsoft.com/ru-ru/sql/relational-databases/in-memory-oltp/introduction-to-memory-optimized-tables?view=sql-server-ver15
Но простое решение всегда лучше, надёжнее, стабильнее и быстрее.
kvazar, через LUA или DDE из таблицы всех сделок.
Первый вариант особо не щупал.
Со вторым работаю давно.
kvazar, это 2 разные технологии с отличными целями.
DDE — старый протокол для обмена данными.
ODBC — интерфейс для работы с базами данных.
С DDE я могу напрямую работать из C#, получая сырые данные прямо из Квика.
И решая что с ними делать дальше.
Писать в базу, хранить в памяти или выбрасывать.
ODBC подобной прямой возможности не имеет.
С СУБД проще работать. Решил что главнее результат, чем процесс. Когда получаешь результат, интереснее улучшить процесс)
kvazar, C# — это норм.
Со Stock# связываться категорически не рекомендую.
Для начала выбирайте простые задачи, чтобы как можно быстрее видеть результат и сохранять мотивацию.
Например отправка заявок через файлы или trans2quik.dll
Но всё равно это будет непросто.
Ибо написать программу и написать её хорошо — это 2 бооольшие разницы.
Каждый должен заниматься своим делом.
Трейдер торговать и генерировать идеи, а программист программировать.
Иначе на рынке не победить.
kvazar, чтобы иметь степени свободы нужно как можно меньше использовать сторонние библиотеки типа Stock#.
Но подобный подход требует значительно больше времени и опыта.
Для новичка это почти нереально.
В общем пробуйте.
Это полезно.
Если что, обращайтесь.
kvazar, если вам не к спеху, то подстрагаю и дам на пробу программу, которая получает данные по DDE из таблицы всех сделок, сворачивает их в нужный фрейм и выводит бары в Excel.
Запустите на десятке ликвидных инструментов и оцените загрузку процессора/памяти(за вычетом экселя).
Если устроит, то на основе этих библиотек можно будет соорудить то, что нужно именно вам.
Свободное время появится к концу этой — началу следующей недели.
Работы там не сильно много.
Акцессовский движок это урезанный SQL. И поскольку все работает локально прирост в скорости будет далеко не в разы.
9 * sizeof( float64 ) = 72 байта, когда это все можно хранить в 8ми?? 4 на кол-во секунд с «начала эпохи» и по 2 на милли- и микро- секунды? Микро, подозреваю, можно отбростить, тогда 6… Память, правда, скорее всего выделяется порциями не меньше 4 байт (выравнивание, так называемое), поэтому особо микросекунды отбрасывать не имеет смысла.
kvazar, ну, уже хорошо, хотя, время можно вполне себе в int32 перевести, по сравнению с текстом — ужатие существенное. Ну и посмотрите на структуру обезличенной сделки:
Вам и вправду все эти данные нужны??
kvazar, под «обсчитываем» что понимается?
тики за 60 мин это маленькая база, чтобы хоть как-то напрячь SQL сервер
kvazar, экстенсивный путь не является умным решением.
Это действие в лоб.
Возможно, забесплатно советов наслушаетесь на годы работы вперед ))
Если есть таблица обезличенных сделок с 10 инструментами, и нужно делать выборки, учитывая время, инструмент, операцию, необходимо ли индекс на поле время. Вот общем я это и сам выяснить могу, опытным путем. Добавляя / убавляя индекс.
kvazar, у меня опыт не впечатляющий, но без совета не оставлю )))
На мой взгляд прямого выигрыша не будет. Не те задачи.
Сами запросы SQL перенести легко, базовые конструкции везде одинаковы.
MS SQL я использовал с SQL Server Management Studio. Мощная штука, особенно на этапе изучения и повышения навыков в SQL.
Имеет смысл поставить и протестировать там то, что используется.
Как минимум, можно повысить скилл написания самих запросов, что в Access сделать сложно.
А вот это уже приведет к итоговому улучшению.
С индексами только эксперименты, просто потому что база маленькая.
SQL там нормальный, это скорее в MS SQL расширенный, причем большая часть этих расширений нужна только для сложных задач
Там мастер кривой. Я когда запросы из MS SQL переносил в access, он ряд запросов даже отобразить не мог, хотя выполнял их прекрасно.
Я почему и говорю, что имеет смысл поработать именно над запросами и, возможно будет достаточно их просто перенести потом в access, не устраивая кардинальных переделок
Вы сделали, очень интересное и изящное решение для робота. Никаких танцев с бубнами над коннекторами и прочей обвеской.
Там история длинная, зачем это понадобилось, но такой опыт был
Наоборот естественно тоже переносил ))
А где их использовать другой вопрос
Самый быстрый и надежный результат.
sql будет все хранить в памяти сам если будет видеть что озу много.
Access это чуть лучше чем Excel. Любая нормальная СУБД будет намного лучше. Сервер с 32ГБ в аренду можно взять за 40 евров в месяц.
Ынвестор, если вы хотите ехать комфортнее, быстрее и не убиться от лёгкого удара об столб, то пересаживаться на современную машину стоит.
Для задач данного топика никаких 32 гигов оперативы не требуется.
Совет добавь озу до 16 gb самый простой и рабочий.
А еще надежный и дешевый.
И не отменяет следующих шагов
Машина хорошо, но для похода в соседнюю булочную она необязательна. )))
А так, классы C# для работы с qsh вроде ведь доступны, просто бери и используй (не то что некоторым заново на С++ все это реализовывать надо было). День торгов по РИ вместе со всем ордерлогом там вмещается в ~10Мб, а если в текст распаковать — то больше 1 Гб может получиться. Мало ли, вдруг заинтригует. В конце концов, можно тики хранить в .qsh, а сами файлы (либо ссылки на них, относительные пути) уже в БД записывать. Вполне себе функциональная вещь должна получиться))
Проблема не в базе, а в архитектуре. данные надо держать в памяти и дампить в базу с некоторой переодичностью в отдельном потоке. из базы данные брать только при первичной загрузке и при перезапуске, например, после обрыва связи. вытаскивать данные раз в 5 секунд с базы за последний час… ну такое.я, конечно, не знаю всех входящих условий, но я бы пересмотрел логику работы с котировками, а не оптимизировал бы базу.
ЕО ВООБЩЕ ГДЕ-ТО ДО СИХ ПОР ПОЛЬЗУЮТ?
Я пользовал его до развития 1С чтобы создавать свои базы на предприятии ...
Закончилось это примерно в 2001-2003 году… а тут робот через акцесс… ЖЕСТЬ ПОЛНАЯ!!!
Берете с гитхаба библиотеку луашарп — тики у вас уже есть. Дальше делаете подписку роботов на событие OnTrade ( FinSerfing может помочь). Да, это сложнее.
Все тики собираете в базу также через ODBC в SQLite/MS SQL, и при старте робота запрашиваете нужную глубину. Готово. ))
Кстати, активные запросы знатно убивают SSD диски.
Еще можно сделать трюк, чтобы лишний раз не драконить базу. Таблицу с тикером и флагом апдейт. Если пришел новый тик, то тригером выставляем флаг ему. А уже из проги сначала проверяем флаг, если он тру, то уже дергаем серию тиков. Удачи!
1. БД — только для хранения данных и загрузки данных в начале работы робота с утра или после сбоя. Использовать БД для быстрого оперативного анализа — неправильно.
2. Весь анализ необходимо производить в ОЗУ — быстро и безопасно.
Если нужно очень быстро обрабатывать, то используйте многопоточность.
Можно, например, разделить на потоки обработку по разным инструментам и стратегиям.
В любом случае Вы рано или поздно в процессе развития своей системы придете к такой архитектуре:
Прием данных в Память, а дальше Анализ, Принятие решений, Прием и отправка ордеров и сделок, Запись данных в БД для истории итд — Все это в отдельных потоках.
И чем раньше Вы это сделаете, тем лучше.
Желаю успехов.
Правильно поняли.
1. У Вас уже есть то, что работает сейчас — это здорово.
2. Вы понимаете, что то что есть сейчас, развивать все сложнее и сложнее — это тоже хорошо (то что Вы это понимаете).
3. Необходимо смело сделать соответствующие выводы —
Использовать то что есть сейчас, и постепенно переходить к другим более перспективным технологиям.