Загрузка котировок в базу данных - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Добрый день!
Хочу создать своего торгового робота. Прогностические модели создавал и ранее, но они не касались трейдинга. Всегда использовал для этого SAS Base + БД.
Подскажите, пожалуйста, как можно загрузить историю котировок в базу данных?
https://www.mql5.com/ru/code/93
автор этого проекта правильно сказал :
В общем, препарировал тут еще раз на обычном компе, но с очень хорошим ssd: samsung 950 pro (pci-e).
Задача та же. 730Мб csv импортировался больше 4 минут (на сервере -2:30). Процессор - не загружен, ОЗУ - навалом; контроллер диска забит на 100%, при чем скорость обмена мизерная: 10-40 Мб/сек.
Включил запрет очистки кэша диска (без UPSа лучше не включать): получил скорость импорта 1:15 (ускорился более чем в 3 раза, и в 2 раза быстрее, чем на сервере).
А происходит там вот что: сначала таблица создается во временной базе (700Мб), потом переносится в мою базу (те же 700Мб), да еще и пишется журнал транзакций (лог) размером 5Гб(!).
Т.е. исходные данные "разрастаются" в 9 раз примерно. И запись происходит, видимо, очень маленькими блоками.
Полагаю, что все остальные запросы, связанные со вставкой и модификацией данных работают аналогично.
Я все понимаю, конечно - надежность, целостность данных и все такое. Но это как-то дороговато (в плане времени) получается. Вот не понимаю я этих восторгов - глючная, тормозная хрень.
В общем, препарировал тут еще раз на обычном компе, но с очень хорошим ssd: samsung 950 pro (pci-e).
Задача та же. 730Мб csv импортировался больше 4 минут (на сервере -2:30). Процессор - не загружен, ОЗУ - навалом; контроллер диска забит на 100%, при чем скорость обмена мизерная: 10-40 Мб/сек.
Включил запрет очистки кэша диска (без UPSа лучше не включать): получил скорость импорта 1:15 (ускорился более чем в 3 раза, и в 2 раза быстрее, чем на сервере).
А происходит там вот что: сначала таблица создается во временной базе (700Мб), потом переносится в мою базу (те же 700Мб), да еще и пишется журнал транзакций (лог) размером 5Гб(!).
Т.е. исходные данные "разрастаются" в 9 раз примерно. И запись происходит, видимо, очень маленькими блоками.
Полагаю, что все остальные запросы, связанные со вставкой и модификацией данных работают аналогично.
Я все понимаю, конечно - надежность, целостность данных и все такое. Но это как-то дороговато (в плане времени) получается. Вот не понимаю я этих восторгов - глючная, тормозная хрень.
Владимир !
по вышесказанному
у тебя не настроен SQL сервер
- глючная, тормозная хрень. подозреваю что профессионально с базами данных ты не работал ? даже не подозреваю - это видно из вышесказанного
1 у тебя стоит модель базы Recovery model: full --- переведи в simple - это делается если прокликать правой кнопкой мыши саму базу - в которую ты заливаешь - и найти закладку с ключевым словом
для такой примитивной задачи которую мы выполняем достаточно режима simple и не будет ненужного нам журнала транзакций ...
режим full применяют в серьезных системах например банковских
2 отдай sql серверу ВСЮ память машины - как раз ту самую память которой навалом - это делается уже в настройках самого сервера
sql сервер будет значительно быстрей работать если вся память сервера будет у него ! на серверах где ставят SQL допустим 64 гига отдают серверу не менее 48ггб
там где 128 можно отдать 110
вообще расчет озу можно сделать так
например у сервера 36ггб ( для винды оставить 4ггб если процессоров 8 то 1,5 на каждый проц еще - остальное серверу ) у кого 2003 сервер можно оставить винде 2 ггб а не 4
36 - 4 - 1.5*8 = 20 ГБ
3 распределитьь базу на несколько дисковых массивов как правило у sql серверов их несколько - при этот файл для лога желательно также положить на отдельный диск - это даст значительный прирост дисковых операций
4 при первичном наполнении однозначно наблюдается низкое быстродейсвие - что бы исключить это достаточно изначально задать расчетный размер - дабы исключить инкрементного изменения самой базы
даже при не очень серьезных закачках - его быть не должно
хотя бы это уже даст прирост
правда еще можно много чего отстроить
--
Задача та же. 730Мб csv импортировался больше 4 минут (на сервере -2:30).
В общем, препарировал тут еще раз на обычном компе, но с очень хорошим ssd: samsung 950 pro (pci-e).этот компьютер не для работы c SQL сервером!
я показал выше свои скорости ! это реальные скорости
... - глючная, тормозная хрень.
Владимир неправда твоя - нехорошо хаять инструмент если его не умеешь использовать
Я не хочу обижать - просто наводится ассоциация с басней Крылова Пробившись попусту час целой, Пошла и говорит с досадою: «Ну, что́ ж! На взгляд-то он хорош, Да зелен — ягодки нет зрелой: Тотчас оскомину набьешь».
вообще - если не получается использовать инструмент - разумно отказаться от него
Симпл рекавери включал - разницы никакой. Файлы разбрасывал - разница в пределах погрешности. Тем не менее на "неподходящем" компьютере результат вдвое превосходит сервер.
Но 10 Мб в секунду - это практически потолок скорости роста базы. С дисковой системой она работает, мягко говоря, не оптимально.
Да, если она уже заполнена, и практически вся лежит в оперативке - данные можно довольно быстро получать. Но генерировать свой контент большого объема - это надо запастись терпением )))
зы Что значит не получается использовать? Скорость у меня получилась не хуже, чем у тебя. Но мне ее сильно не хватает. Из С++ на порядок быстрее получается.
Симпл рекавери включал - разницы никакой. Файлы разбрасывал - разница в пределах погрешности. Тем не менее на "неподходящем" компьютере результат вдвое превосходит сервер.
Но 10 Мб в секунду - это практически потолок скорости роста базы. С дисковой системой она работает, мягко говоря, не оптимально.
Да, если она уже заполнена, и практически вся лежит в оперативке - данные можно довольно быстро получать. Но генерировать свой контент большого объема - это надо запастись терпением )))
зы Что значит не получается использовать? Скорость у меня получилась не хуже, чем у тебя. Но мне ее сильно не хватает. Из С++ на порядок быстрее получается.
на си разумеется заточенная под конкретику любая задача будет быстрее
но беда тут в другом , как только нужно будет иначе что то выбрать - придется писать чуть ли не новую программу - гибкость в этом случае полностью отпадает
--
ну вот это верно
когда все настроено - летает как положено
и выбрать можно очень быстро и гибко все что угодно - и минутку набить и найти закономерности - но это уже надо достаточно хорошо знать сам язык SQL
на sql минутку собираю за 2 секунды с 5,000,000 записейскорость сборки минутки на Си++ у тебя равно 2 секундам на 5 миллионах записей ?
Добавлю свои 5 копеек.
Вы наверное не обратили внимание, но все базы данных которые Вы перечисляли - строкоориентированы. А наши данные используют в основном колонки. Т.е. для наших целей нужны колонко-оринтированные (какое то слово кривое, но другого не придумал) базы данных. Одна из таких баз MonetDB. Там много других полезных плюшек.
Удачи
матлаб и прочие инструменты - стоят в стороне они не заточены под скорость работы с данными
Это Вы батенька загнули...
Вы уверены на что при объемах базу 4 5 10 трб матлаб обгонит по скорости ОБРАБОТКИ данных например MS SQL ?
В общем, препарировал тут еще раз на обычном компе, но с очень хорошим ssd: samsung 950 pro (pci-e).
Задача та же. 730Мб csv импортировался больше 4 минут (на сервере -2:30). Процессор - не загружен, ОЗУ - навалом; контроллер диска забит на 100%, при чем скорость обмена мизерная: 10-40 Мб/сек.
Включил запрет очистки кэша диска (без UPSа лучше не включать): получил скорость импорта 1:15 (ускорился более чем в 3 раза, и в 2 раза быстрее, чем на сервере).
А происходит там вот что: сначала таблица создается во временной базе (700Мб), потом переносится в мою базу (те же 700Мб), да еще и пишется журнал транзакций (лог) размером 5Гб(!).
Т.е. исходные данные "разрастаются" в 9 раз примерно. И запись происходит, видимо, очень маленькими блоками.
Полагаю, что все остальные запросы, связанные со вставкой и модификацией данных работают аналогично.
Я все понимаю, конечно - надежность, целостность данных и все такое. Но это как-то дороговато (в плане времени) получается. Вот не понимаю я этих восторгов - глючная, тормозная хрень.
Во-первых, логирование таблицы в которую идет запись надо отключать или создавать с опцией типа NOLOGGING. Если включено логирование на таблице, все состояния при выполнении DML операций идут в лог чтобы можно было восстановить данные на любой момент времени.
Во-вторых, удалить индексы таблицы до вставки данных и создать после вставки. Если существуют индексы, они будут перестраиваться каждый раз при любой DML операции. Кстати, если есть триггеры на таблице - тоже отключить до вставки.
В-третьих, используйте возможности BULK INSERT и транзакционность если база поддерживает. Транзакции позволят сгруппировать данные в памяти, а по завершению записать на диск, в противном случае на диск будет записываться каждая новая строка. А BULK INSERT и существует для массовой вставки больших объемов данных.
Ну и плюс ко всему - убедитесь что места на носителе хватает, можно и табличные пространства заранее увеличить до требуемого объема.
Вы уверены на что при объемах базу 4 5 10 трб матлаб обгонит по скорости ОБРАБОТКИ данных например MS SQL ?
А матлаб и не заточен под обработку БД, просто у него есть такие возможности. И вообще он тормозной. Встроенные функции, конечно, летают, но самописный код довольно медленный, если нельзя применить векторные/матричные операции и приходится писать в обычном стиле.
Например, когда я своем тестере стратегии заменил модуль по работе с ордерами на ДЛЛ на шарпе, которая делала то же самое, скорость увеличилась около 2 раз.