Блог им. kvazar

Нужен опытнейший программист (C#, MS SQL, VBA)

Интересуют консультации платные по договоренности и ответы на разные вопросы. Если алготрейдер, еще лучше.
Например, скорость работы различных БД, оптимизация запросов, индексация, тонкости работы с Квиком. 
Кодить не потребуется, я сам (может немного с помощью). Общение Skype.

125 комментариев
Если не секрет… за каким лешим вам понадобился такой зверь?
avatar
$100, я на пороге глобального рефакторинга своего робота, не могу решиться, нужен помогатор. Мамба переходит на 19-значные номера заявок ордеров в июле (приблизительно). Квик перешел на х64. Мои алгоритмы требовательны к ресурсам — много запросов SQL в Access. Нужно оценить что делать, перетащить базу в MS SQL и как оптимизировать запросы и т.д. Оставить ли клиентом Access или написать эту часть заново в VB / C#. Рефакторинг опять же. Поменять комп нужно, мой моно блок ЦП жрет 30% в процессе работы, а память 8Г на 60-80%, греется к концу дня. И так далее
avatar
kvazar, Sqlite вам в помощь вместо Access. Оч быстрая и компактная БД при определенных настройках pragma. Хотя, объемы транзакций надо знать, чтобы сказать что-то определенное.
А с компом у вас и так все ОК.
Определенно написать на С#/VB, а часть на С++.
avatar
3Qu, почитаю, про SQLite, спасибо. а С++ для каких задач?
avatar
kvazar, экспорт данных из терминала, в БД, в том числе. В том числе из Квик через Луа. Ну, или по ODBC. Эт как хочется, но не все хотелки возможны через ODBC.
avatar
3Qu, Выгоднее просто добавить памяти.
до 16gb.
Одно это добавит скорости.
И что удивительно и неожиданно, надежности.
(своп до сих пор, несмотря на 25 лет использования в ос подглючивает)

опять-же на квик 64 бит переходит.

avatar
Антон Б, если памяти  итак хватает, на фига ее добавлять. А 8 ГБ и так за все про все хватит.
У меня вот всего 4 ГБ (несчастный случай, сдох комп, и срочно на Авито купил новый-ненадеванный, других не было, а через неделю появился — локти кусал) — и то на все хватает. Квик подтормаживает, но здесь не в памяти дело, ее еще 20% остается, и проц не загружен.
Квик х64.
avatar
3Qu, см. ниже принт-скрин, это 8 Гб
avatar
kvazar, Собственно видно что не хватает.
avatar
kvazar, см. ниже принт скрин 4 ГБ. Уж не знаю, что вы там делаете. У меня тоже много чего крутит. Еще Питон сейчас не запущен.



avatar
3Qu, Это все очень грустно что у вас 4 гб на квике. и бу комп. где нужна надежность реально.

а через стенку, в другой квартире, у 12 летнего гейсера 32 гига чтобы было.

И что у вас нет запасного терминала в виде дешевого ноута тоже очень грустно.

А еще это значит что ни о каких бд промышленно используемых вы в реале не видели.

Потому что железо сейчас очень дешевое.
А квалификация хорошо оплачивается. даже в рф.
avatar
Антон Б, нормально, потом куплю. Руки ( и ноги) не доходят.))
С Квик вообще все интересно, свободная память есть, процессор свободен, а Квик подвисает. Че-то в нем не так.
И воще, я IT специалист, а сапожнику положено без сапог.)
avatar
3Qu, Свободная память которую показывает диспетчер.
Это такое.
Он может свопить и показывать свободную память.
+ то-же dde
Работает в ТОМ ЖЕ потоке.
И если стучится в dde сервер, в виде excel, пока тот из свапа выползет фрезится.

А по памяти это не видно навскидку.
avatar
Антон Б, а вообще, Квик перед запуском чистить надо, и ему резко лучшает. В одном из своих топиков показывал cmd-шку.
avatar
3Qu, Как это отрицает то что я написал до этого?
Ок надо, )
avatar
Антон Б, я ничего не отрицаю.)
А вообще б/у покупать хорошо. Кому-то дарят на ДР, он на Авито продает ненужное новье с гарантией в 2 раза дешевле.
avatar
3Qu, как Вы разрабатываете на этом железе?

Памяти нужно на разработку как минимум 16gb
Тем более что это дешево. 100$ 16gb

avatar
Антон Б, да, куплю, не переживайте, руки не доходят, и ноги тоже. Пока вроде хватает — Питон идет, VC идет.
А вот память не апгрейдится, впаяна в сис. плату.
А Васька слушает, да ест. Тем временем моя сделка на стрэнглах РТС вверх ползет.)) Пустячок, а приятно.
avatar
3Qu, Ниже скриншот там 92% загрузка по памяти.
Он на этом компьютере не только стратегию крутит.
но и использует его как рабочую станцию.
Так что 8gb ему мало, это видно по скриншоту.

Самое дешевое и надежное добить памяти до 16 gb.
Как минимум.
Все станет надежнее.
Даже квик с dde.
И акцесс весь кеш переселит в память и вообще не будет читать диск.
Только писать.
По факту просто добив памяти получаешь надежность и отзывчивость.
Очень дешево.
+ открывает путь к безопасности и надежности через виртуализацию.

( Когда бот работает в виртуалке в отдельной чисто системе)
Которую можно снешшопить.
При обновлении квика.
И если что пойдет не так, обратно восстанавливать.

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

avatar
Антон Б, в общем, да. 16 ГБ по любому не помешают.
avatar
3Qu, Это все очень грустно что у вас 4 гб на квике. и бу комп. где нужна надежность реально.

а через стенку, в другой квартире, у 12 летнего гейсера 32 гига чтобы было.

И что у вас нет запасного терминала в виде дешевого ноута тоже очень грустно.
avatar
Антон Б, +++
avatar
Пацан собрался тест проходить на Крем долину, а репетиторов ноль.
avatar
Silent Hamster, пацан давно все сделал
avatar

Опытнейший программист не станет консультировать так абстрактно.

Потому что понимает, что очень многое зависит от архитектуры приложения, используемых фреймворков и библиотек.

Можно и на C++ так наговнокодить, что VBA окажется быстрее.

Разбирать нужно что-то конкретное.

Иначе в этом нет почти никакого смысла.

avatar
FinSerfing, что то вполне конкретное есть. Но меня интересуют теоретические / практические советы. Если ты работал с разными базами 20 лет и написал тысячи запросов, мне нужны советы опытного практика.
avatar

kvazar, базы данных — это не к программисту.

Это к DBA(DataBase Administrator).

При этом достаточно базовых знаний, которые есть в массе книг.

Разделение на нормальные формы, создание правильных индексов, работа с SQL Query Analyzer.

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

Либо нужны но в гораздо меньших объёмах.

Не редко их используют не по назначению.

Самый первый вопрос: «Что вы храните в базе данных ?»

avatar
FinSerfing, все. поток сделок потиково, статистику торговую, позиции, ордера, стоп-ордера. сделки. ну и статистику сделок для анализа. Знания из книг не подходят, книг у меня немеряно, нужен практик который скажет как лучше сделать. 
avatar

kvazar, хорошо.

Основной объём и проблемы дают тики.

Идём дальше.

За какой период хранится тиковая история и по какому количеству инструментов?

Зачем вам вообще тиковая история и можно ли обойтись бОльшим фреймом или меньшим объёмом тиков ?

avatar
FinSerfing, сейчас 10 инструментов, можно обойтись 2 и проблема исчезнет, НО — нужно сделать так чтобы не было проблем и при расчете 30 инструментов, вот задача. расчет по тикам, это основа, от этого нельзя отказаться. Перерасчет идет каждые 10 секунд, это край.  
avatar
kvazar, какая максимальная глубина тиков необходима для перерасчёта?
avatar
FinSerfing, окно скользящее — обсчитываем тики за последние 5 минут/ соотносим с данными за последние 15 минут  и по той же логике 15/60 минут. много, к вечеру память 90% использует.
avatar
kvazar, т.е. дальше 60 минут тиков не нужно?
avatar
FinSerfing, да, так. Но базу акцесс нельзя сжать в процессе работы... 
avatar

kvazar, возьмём фьючерс на индекс РТС(RIM0).

За первый час пролетело 44308 сделок.

Это совершенно не много.

При учёте того, что время от времени очищать старые данные.

MSSQL достаточно просто потянет данную задачу.

Если нужна супер скорость, то можно создать in-memory-table.

Скажу больше, подобный объём можно хранить и обрабатывать внутри программы.

Хоть в массивах, хоть в хеш-таблицах.

 

Данные в access поставляются через ODBC ?

Сколько оперативки на компе ?

Какой процессор ?

avatar
FinSerfing, для меня это сложно, идет поток по ODBC из квика и идет. Мне с этим очень просто работать. Да, только запросов то на 44000 тиков — в цикле 10, а не 1. несколько индикаторов. Я соврал, вернее забыл — есть еще пару запросов по всему дню, с начала торгов, здесь сам додумаю.
В день записывается строк с расчетами около 35000-40000, самих запросов больше в день, есстественно.
avatar

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

Но простое решение всегда лучше, надёжнее, стабильнее и быстрее.

avatar
FinSerfing, наверное так. Как получать сделки из квика, через какой механизм? 
avatar

kvazar, через LUA или DDE из таблицы всех сделок.

Первый вариант особо не щупал.

Со вторым работаю давно.

avatar
FinSerfing, ODBC не уступает DDE
avatar

kvazar, это 2 разные технологии с отличными целями.

DDE — старый протокол для обмена данными.

ODBC — интерфейс для работы с базами данных.

С DDE я могу напрямую работать из C#, получая сырые данные прямо из Квика.

И решая что с ними делать дальше.

Писать в базу, хранить в памяти или выбрасывать.

ODBC подобной прямой возможности не имеет.

avatar
FinSerfing, понял, я 2-3 года назад брался за C# / Stock#. Времени и терпения не хватило пройти весь путь. Нужен профи-помощник-учитель..
С СУБД проще работать. Решил что главнее результат, чем процесс. Когда получаешь результат, интереснее улучшить процесс)
avatar

kvazar, C# — это норм.

Со Stock# связываться категорически не рекомендую.

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

Например отправка заявок через файлы или trans2quik.dll

Но всё равно это будет непросто.

Ибо написать программу и написать её хорошо — это 2 бооольшие разницы.

Каждый должен заниматься своим делом.

Трейдер торговать и генерировать идеи, а программист программировать.

Иначе на рынке не победить.

avatar
FinSerfing, я хочу иметь 100% степеней свободы, сам придумал. сам сделал. Поэтому робот внешний, не LUA. Есть только КВИК и все.
avatar

kvazar, чтобы иметь степени свободы нужно как можно меньше использовать сторонние библиотеки типа Stock#.

Но подобный подход требует значительно больше времени и опыта.

Для новичка это почти нереально.

В общем пробуйте.

Это полезно.

Если что, обращайтесь.

avatar
FinSerfing, спасибо, не совсем я новичок, скорее старичок) как относитесь к идее устроить демонстрацию, чтобы оценить насколько трудозатратен переход к DDE-C#? 
avatar

kvazar, если вам не к спеху, то подстрагаю и дам на пробу программу, которая получает данные по DDE из таблицы всех сделок, сворачивает их в нужный фрейм и выводит бары в Excel.

Запустите на десятке ликвидных инструментов и оцените загрузку процессора/памяти(за вычетом экселя).

Если устроит, то на основе этих библиотек можно будет соорудить то, что нужно именно вам.

 

Свободное время появится к концу этой — началу следующей недели.

Работы там не сильно много.

avatar
FinSerfing, давайте попробуем. не к спеху, это среднесрочная задача) я сам только что не делал с тиками. 
avatar
FinSerfing, есть 2 пути в алготорговле (очень образно, их конечно много): ООП — C# — DDE и ODBC — СУБД. По второму я уже прошел, робот готов, все работает. Первый для меня — либо самому пилить ради расширения кругозора либо заказать. Пока решил, пардон, второй прокачать.
avatar
kvazar, хорошо написано!
avatar
kvazar, а можно 60-минутными частями записывать, а потом в конце дня все их объединять (для архива и бектеста последующего, например)?
avatar
tranquility, поток ODBC льется в приемник-таблицу, как это в процессе изменить не знаю. Задал вопрос техподдержке квика можно ли сделать много таблиц обезличенных сделок и настроить у каждой фильтр.  Тогда можно 10 таблиц квика (по инструментам) — 10 таблиц БД
avatar
kvazar, значит надо из своего кода производить запись потиково в БД. Как заполняется час — подставлять другую таблицу, а прежнюю на диск, сливать отдельным потоком… Вроде народ через коннекторы C# кучу инструментов за раз мониторит (арбитражеры, например) и соединение у них не лопается). Кстати, когда сами писать в БД будете, там какой-нибудь порожняк выкинуть можно будет, вроде номера сделки (если так надо, то хотя бы можно базовое значение отнять, а сохранять только int32), время из текстового вида в численный перевести — поток данных ужмется в разы.
avatar
tranquility, запрос работает со смещением. скользит. то есть ему придется обрабатывать сразу 2 таблицы, обсчитывая 60 минут, так как часть данных в одной, часть в другой. В чем проблема Акцесса? Это 2Гб на базу. И базу нельзя сжать в процессе, к концу дня замедляется поток, нужно индексы ведь обсчитывать при вставке в таблицу, база растет. А SQL такой проблемы не испытывает, там можно базу сжимать в процессе. насколько я знаю.
Акцессовский движок это урезанный SQL. И поскольку все работает локально прирост в скорости будет далеко не в разы.
avatar
kvazar, А, я все же подразумевал что все данные у Вас в ОЗУ будут за необходимый промежуток времени, а БД нужна только для последующего бектестирования. Но если так надо чтобы данные в БД были, можно писать какое-то время в старую таблицу еще час и в новую. Тогда будут куски по 120 минут, каждый последующий повторяет половину предыдущего. Данные брать из старой продолжать пока час новой не наберется, тогда только сохранять старую, делов-то ;) Ну, и если сами писать будете, то следует ожидать какого-то ужатия данных. Может, как раз в те же 2Гб и уложитесь. Я подозреваю, что в бд все в текстовом виде поступает, а это значит, что еще стоит кроме ужатия и прироста скорости ожидать, если все перевести в численный. Ведь чтобы найти нужное время, СУБД не надо будет индекс производить, просто достаточно логарифмический поиск по упорядоченному массиву выполнить.
avatar
tranquility, если все данные за день в ОЗУ — тогда вопросов нет конечно.  Сбросить в конце дня в базу. А если 30 инструментов, это где-то за день, 3-4 млн записей приблизительно будет...  
avatar
kvazar, ну, тогда внахлест сбрасывайте каждые 2 часа, раза в 4 разгрузите память ОЗУ. Но вот только надо разобраться с коннектором и как самому в базу писать. Я правильно подозреваю что в БД все в текстовом виде сохраняется, время, и может даже — цена? Если так, то перегоняя каждый тик при поступлении в численный вид — сильно объем данных ужмется.
avatar
tranquility, нет в БД все поступает в форматах биржи и квика. время- время. цена — число и т.д.
avatar
kvazar, ну и вот со временем тем же, вот сколько байт это занимает в одном тике?

9 * sizeof( float64 ) = 72 байта, когда это все можно хранить в 8ми?? 4 на кол-во секунд с «начала эпохи» и по 2 на милли- и микро- секунды? Микро, подозреваю, можно отбростить, тогда 6… Память, правда, скорее всего выделяется порциями не меньше 4 байт (выравнивание, так называемое), поэтому особо микросекунды отбрасывать не имеет смысла.

avatar
tranquility, это нюансы,  но для поля «дата» акцессу требуется 8 байт.
avatar
kvazar, миллисекунды не сохраняются, что ли? А если бы они Вам нужны были…
avatar
tranquility, нет миллисекунд) 
avatar
tranquility, в БД поступает ровно в форматах биржи и квика, как есть. никаких переводов. 
avatar

kvazar, ну, уже хорошо, хотя, время можно вполне себе в int32 перевести, по сравнению с текстом — ужатие существенное. Ну и посмотрите на структуру обезличенной сделки:




Вам и вправду все эти данные нужны??

avatar
tranquility,  я получаю только  номер сделки, инструмент, время, количество, цену и операцию. Спасибо за подсказку, глаз замылился, исторически сложилось, номер сделки мне не нужен, выкину.
avatar
kvazar, а, ну хорошо что можно настроить какие поля писать в БД, иначе перебор, однозначно был бы.
avatar
tranquility, это само собой) не все так страшно с акцесс и vba как его малюют.
avatar

kvazar, под «обсчитываем» что понимается?
тики за 60 мин это маленькая база, чтобы хоть как-то напрячь SQL сервер

avatar
kachanov, различные (не одна) выборки из всех тиков по инструменту за последние 60 минут. Т. е. выборок несколько, допустим, 10 и 10 инструментов. За 10-30 секунд около 100 запросов проходит. Это один цикл.
avatar
 умный человек посоветовал навернуть комп, это раз.
avatar

kvazar, экстенсивный путь не является умным решением.

Это действие в лоб. 

avatar
FinSerfing, в моем случае памяти объективно не хватает компу, факт)
avatar
На мой взгляд, если SQL запросы в Access писали ручками, а не через их кривой мастер, то для простых приложений MS SQL явного прироста производительности не принесет.

avatar
kachanov, ручками, опыта у меня хватает. В том числе и в этом и нужен совет.
avatar
kvazar, так спросите тут.
Возможно, забесплатно советов наслушаетесь на годы работы вперед ))
avatar
kachanov, :) будет ли выигрыш от ухода от акцесса к localdb ms sql. как строитт запросы в этом случае. чем хорош акцесс, это его офигенная терпимость к ошибкам. исправил код в процессе выполнения и дальше погнали.
Если есть таблица обезличенных сделок с 10 инструментами, и нужно делать выборки, учитывая время, инструмент, операцию, необходимо ли индекс на поле время. Вот общем я это и сам выяснить могу, опытным путем. Добавляя / убавляя индекс. 
avatar

kvazar, у меня опыт не впечатляющий, но без совета не оставлю )))
На мой взгляд прямого выигрыша не будет. Не те задачи.
Сами запросы SQL перенести легко, базовые конструкции везде одинаковы.
MS SQL я использовал с SQL Server Management Studio. Мощная штука, особенно на этапе изучения и повышения навыков в SQL.
Имеет смысл поставить и протестировать там то, что используется.
Как минимум, можно повысить скилл написания самих запросов, что в Access сделать сложно. 
А вот это уже приведет к итоговому улучшению.
С индексами только эксперименты, просто потому что база маленькая.

avatar
kachanov, посоветовали inmemory таблицы попробовать
avatar
kachanov, access прекрасная среда разработки для локальных БД. Движок его — это урезанный sql.  Написание запросов в акцессе — проще простого)
avatar
kvazar, согласен. Просто и удобно.
SQL там нормальный, это скорее в MS SQL расширенный, причем большая часть этих расширений нужна только для сложных задач
Там мастер кривой. Я когда запросы из MS SQL переносил в access, он ряд запросов даже отобразить не мог, хотя выполнял их прекрасно.
Я почему и говорю, что имеет смысл поработать именно над запросами и, возможно будет достаточно их просто перенести потом в access, не устраивая кардинальных переделок

Вы сделали, очень интересное и изящное решение для робота. Никаких танцев с бубнами над коннекторами и прочей обвеской. 
avatar
kachanov, спасибо, запишу как-нибудь видео его работы. не совсем понял фразу, вы переносили из sql в access? не наоборот?
avatar
kvazar, именно так. Из sql в access
Там история длинная, зачем это понадобилось, но такой опыт был
Наоборот естественно тоже переносил ))
avatar
kachanov, именно поэтому я говорю, что писать добротные запросы проще научится в SQL Server Management Studio. 
А где их использовать другой вопрос
avatar
kvazar, кстати, а заявки Вы как отправляете в квик?
avatar
kachanov, через текстовые файлы, был бы c# использовал api
avatar
 

avatar
kvazar, Добей ОЗУ до 16gb.Минимум.


Самый быстрый и надежный результат.
sql будет все хранить в памяти сам если будет видеть что озу много.
avatar
У меня старый запорожец. В принципе я знаю где и что у него отваливается. Стоит ли мне пересаживаться на новую современную машину?
Access это чуть лучше чем Excel. Любая нормальная СУБД будет намного лучше. Сервер с 32ГБ в аренду можно взять за 40 евров в месяц.

Ынвестор, если вы хотите ехать комфортнее, быстрее и не убиться от лёгкого удара об столб, то пересаживаться на современную машину стоит.

Для задач данного топика никаких 32 гигов оперативы не требуется.

avatar
FinSerfing, если нужна скорость то ничего другого кроме как хранить в оперативке не придумали еще. Ну если вся база это 8ГБ то это вообще смешно. Хотя для accessa и это вызов
FinSerfing, Ему требуется совет на ВЫРОСТ.
Совет добавь озу до 16 gb самый простой и рабочий.
А еще надежный и дешевый.
И не отменяет следующих шагов
avatar
Ынвестор, в данном случае корректней сравнение автомобиля и прогулки пешком/ на велосипеде.
Машина хорошо, но для похода в соседнюю булочную она необязательна. )))

avatar
Итак, комп устарел. Переход на MS SQL. Но консультацию я все таки получил через профи.ру. Лучше поговорить с человеком)
avatar
kvazar, думаю, если бы Вы хранили историю в .qsh файлах, при этом держа в памяти только те данные, к которым производится обращение, то ресурсов Вашего компа было бы все еще достаточно. Интересно вообще, а зачем нужна тут СУБД? Там же в любом случае не должно быть каких-то суперхитрых запросов, а функцию логарифмического поиска и самому реализовать несложно, на любом языке программирования…
avatar
tranquility, мне так проще или по другому я не умею.
avatar
kvazar, ну, хотя бы переход на SQL будет каким-то поводом встряхнуть мозгами) Я вообще СУБД никогда не пользовался, разве что когда-то немного с примерами SQLite игрался. Поэтому и спросил в чем там профит от использования СУБД, вдруг лично мне как раз этого не хватает чтобы откопать свой персональный грааль))
А так, классы C# для работы с qsh вроде ведь доступны, просто бери и используй (не то что некоторым заново на С++ все это реализовывать надо было). День торгов по РИ вместе со всем ордерлогом там вмещается в ~10Мб, а если в текст распаковать — то больше 1 Гб может получиться. Мало ли, вдруг заинтригует. В конце концов, можно тики хранить в .qsh, а сами файлы (либо ссылки на них, относительные пути) уже в БД записывать. Вполне себе функциональная вещь должна получиться))
avatar
tranquility, у Вас есть реализация на практике этого подхода?
avatar
kvazar, есть только то, что касается qsh и на С++. С# мне не нужен, но я видел на сайте кускальпа библиотеку классов C# для работы с qsh. Этого должно быть достаточно для нуждающегося.
avatar
kvazar, может, я проблему саму техническую не понял? Т.е. инструментов так много, что тиковая история в ОЗУ не вмещается, если ее целиком там хранить весь день и поэтому ее надо сразу практически скидывать в ОЗУ на диск? Звучит как-то странно, тиков по одному инструменту ну тысяч 200, каждый, скажем, байт 100 (на самом деле — меньше) занимает — это всего 20 Мб. 8Гб на сотню-другую таких инструментов должно хватать…
avatar
tranquility, я не знаю, нет опыта реализации связки DDE-C# и хранения этого где-то в памяти
avatar
kvazar, если не чистый HFT — то не обязательно в памяти хранить… твердотельные вполне обеспечивают скорость записи/считывания ..


avatar
GrayFox, у меня ssd, вполне себе скорость. посоветовали именно nvme поставить
avatar
kvazar, так «хранение этого где-то в памяти» подразумевает только лишь создание объекта массива структур (объектов с полями: время, цена, объем, номер сделки, и т.п.). Обычная работа с массивами (ну, векторами по С++шному). Там реально ничего сложного. С# как и С++ позволит Вам создать хоть миллирардной длины массив (вектор) — лишь бы памяти хватало, и все будет стабильно работать.
avatar

Проблема не в базе, а в архитектуре. данные надо держать в памяти и дампить в базу с некоторой переодичностью в отдельном потоке. из базы данные брать только при первичной загрузке и при перезапуске, например, после обрыва связи. вытаскивать данные раз в 5 секунд с базы за последний час… ну такое.я, конечно, не знаю всех входящих условий, но я бы пересмотрел логику работы с котировками, а не оптимизировал бы базу.

avatar
 ГОТОВ ПОКАЗАТЬ ЧЕРЕЗ СКАЙП СВОЮ ПОДЕЛКУ и обсудить возможности реализации другим гарантированно более быстрым способом (с открытым кодом для меня).  За деньги) 
avatar
kvazar, а не через скайп?
avatar
GrayFox, ? каким способом
avatar
kvazar, любой иной мессенджер… а может и просто гуглдиск или прочее, может платформы типа зум… да дофига способов…

avatar
GrayFox, а, вообще не принципиально. показать и объяснить визуально, а не выложить все на гугл диск)
avatar
kvazar, так почему тогда СКАЙП? мерзакаяя майкрософтская приоьретёнка, если такие глобальные задачи? и с какого фига до сих пор Акцесс фигурирует в написаниии????

avatar
GrayFox, в написании чего? какая разница, скайп, не скайп. уже блин и скай и скайп фо бизнес, и зум, у гуглмит стоит. чего только на удаленке нет.
avatar
kvazar, да ниже написал… потому что в самом посте ничего не написано… в первых же ответах нафталин.
avatar
 Давайте ещё будем строить всё в Кью-Бейзе и прочих… АКЦЕСС!!! Реально??????? ЭТО РЕАЛЬНО СТРОИТЬ РОБОТА ЧЕРЕЗ АКЦЕССС????
ЕО ВООБЩЕ ГДЕ-ТО ДО СИХ ПОР ПОЛЬЗУЮТ?
Я пользовал его до развития 1С чтобы создавать свои базы на предприятии ...
Закончилось это примерно в 2001-2003 году… а тут робот через акцесс… ЖЕСТЬ ПОЛНАЯ!!!
avatar
GrayFox, робот написан и работает. что столько эмоций? абсолютно все равно в 90% случаях на чем написан робот, если это не HFT. Если гонять 1-2 инструмента, так вообще пофиг.
avatar
kvazar, если переписывать робота, то вам однозначно надо уходить от постоянного запроса тиков из базы. Это неправильно, хотя понятное решение с минимум ошибок. MS SQL Server очень прожорлив к памяти, хотя его и можно настроить.
Берете с гитхаба библиотеку луашарп — тики у вас уже есть. Дальше делаете подписку роботов на событие OnTrade ( FinSerfing может помочь). Да, это сложнее.

Все тики собираете в базу также через ODBC в SQLite/MS SQL, и при старте робота запрашиваете нужную глубину. Готово. ))

Кстати, активные запросы знатно убивают SSD диски.
avatar
yurikon, спасибо за совет. задачка масштабнее… мы говорили только про узкое место. функционала в поделке намного больше, это конструктор, плюс анализ сделок — это главное… на  переделку хозспособом у меня уйдут годы. Самое разумное сейчас сменить комп и возможно СУБД.  Правильно говорите, решение стабильное относительно. 
avatar
kvazar, можете поставить ms sql express — бесплатный релиз, там ограничение на ядра и ОЗУ есть. И поставить MsManager MS SQL — оттуда можно делать запросы и смотреть скорость исполнения. MS SQL будет конечно шустрее.
Еще можно сделать трюк, чтобы лишний раз не драконить базу. Таблицу с тикером и флагом апдейт. Если пришел новый тик, то тригером выставляем флаг ему. А уже из проги сначала проверяем флаг, если он тру, то уже дергаем серию тиков. Удачи!
avatar
yurikon, этим уже занимаюсь. есть VS prof 2013, и MMSQL. Тиков заходит в таблицу 1-10 в секунду… Проверять это лишнее время? В роботе я лишь проверяю актуальность времени котировок в базе.
avatar
kvazar, если только РИ/СИ, то можно и не усложнять. Индекс по tradeid+datetime сделать и так норм работать будет.
avatar
Наверное самый грамотный подход вы выбрали. Удачи вам.
Cristopher Robin, искреннее спасибо!
avatar
Правильно Вам все пишут.
1. БД — только для хранения данных и загрузки данных в начале работы робота с утра или после сбоя. Использовать БД для быстрого оперативного анализа — неправильно.
2. Весь анализ необходимо производить в ОЗУ — быстро и безопасно.
Если нужно очень быстро обрабатывать, то используйте многопоточность.
Можно, например, разделить на потоки обработку по разным инструментам и стратегиям.

В любом случае Вы рано или поздно в процессе развития своей системы придете к такой архитектуре:
Прием данных в Память, а дальше Анализ, Принятие решений, Прием и отправка ордеров и сделок, Запись данных в БД для истории итд — Все это в отдельных потоках.
И чем раньше Вы это сделаете, тем лучше.

Желаю успехов.
avatar
_sg_, возможно. более легкий путь с СУБД я прошел. второй сложнее. 
avatar
kvazar,
Правильно поняли.
1. У Вас уже есть то, что работает сейчас — это здорово.
2. Вы понимаете, что то что есть сейчас, развивать все сложнее и сложнее — это тоже хорошо (то что Вы это понимаете).
3. Необходимо смело сделать соответствующие выводы —
Использовать то что есть сейчас, и постепенно переходить к другим более перспективным технологиям.
avatar
Обновил компьютер, все летает. Скорость обсчета выросла, плюс расспараллелю вычисления.

avatar

теги блога kvazar

....все тэги



UPDONW