Загрузка котировок в базу данных - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Хм, так и пришлось заводить шарманку:
csv размером 760Мб 21,5 млн. строк из трех полей: время, бид, аск.
bulk insert первый раз - 2:55, второй, третий раз 2:30 примерно.
Т.е. 10Гб будет минут 30. Но раньше я загонял 5 полей (+объемы по бид и аск). Ну, и оперативки тогда было поменьше - 16Гб, сейчас 48Гб. Но оперативка здесь вряд ли актуальна.
База с журналом стоит на RAID 0 из четырех дисков, довольно быстром: из оперативки 10Гб записывается где-то за 6,5 сек. Два процессора Е5-2450.
Владимир! я с самого начала хотел спросить параметры твоей аппаратуры!
разница по скорости загрузки у нас разумеется отличается и по железу
X7350 4 ядра ( в сервере у меня 4 проца )
Е5-2450 8 ядер ( два прца )
я описывал выше у меня 16 ядер Xenon X7350 , т е по ядрам у нас вроде как паритет ... при этом Е5-2450 пободрее даже
это хорошо..
--10ггб у у тебя 30 минут - по расчетам меня будет не более 15 минут , могу проверить - "покрутить шарманку" попробую на 10ггб файле - отпишу позже
Ошибаешься , оперативка очень актуальна ! как у тебя настроен MS SQL в этом плане он у тебя из 16 ггб или 48ггб сколько кушает ? это очень важно
у меня из 64 гигов под SQL отдано 51ггб - часть операций он просто выполняет в кеше не обращаясь к дискам - именно поэтому 10ггб данных он просо всосет в память а у тебя идет обращение к дискам
у меня SQL отстроен достаточно целенаправленно , т е это чистый SQL сервер там даже нет файловых операций!
имеется ввиду клиенты НЕ видят его как файловый ресурс
Тиковые данные грузятся в виде "как есть" или с обработкой?
У меня не просто грузятся тики, а делается семплирование с периодом 1 сек. Делал профайлинг, много времени уходит на преобразование даты-времени в текстовом формате в Матлабовский формат времени
2015.10.30 05:25:52,1.09766,1.09776
Вот функция парсинга строки, вроде ускорить уже нельзя
О ! Алексей подтянулся , уже веселей!
1) гружу как есть не теряя время на обработке - давно пришел к выводу - нельзя ничего обрабатывать в момент загрузки
уж лучше приготовить - преобразовать данные на вход как надо до начала загрузки
1.1 загрузка это как правило самая медленная операция - поэтому упрощать ее надо по максимум пост обработка потом делается и на порядки быстрее !
но это я отношу именно к MS SQL , ORACLE, SyBase , MySQL - при этом сервер должен быть хорошо настроен - все сеты согласно рекомендаций от лучших собаководов
при этом логично разбивать дальнейшие операции преобразования на этапы
2) затем из загруженных данных ( тики ) - они уже при этом как правило в кеше - формируется минутка - уходит 2 секунды примерно на 5мл записей
2.1 первой выобркой максимально уменьшаем результирующую табличуку формируя при необходимости первичный ключик
затем с уже значительно уменьшенной табличкой операции по обработке
если при каждой итерации обращаться к первичной табличке то только по ключу !но есть ситуации когда даже не приходится ходить в первичную выборку
подход такой просто в разы поднимает скорости обработки
и еще - скорость такая обеспечивается хорошо настроенным сервером и хорошей аппаратурой
кстати на маленьких объемах нет смысла даже строить индексы - они не мешают как правило но и не помогают
p.s.
не хочу быть неверно понятым , более чем 20 лет опыта занимаюсь этим на основной работе
на работе оперирую табличками с миллиардамим записей
хорошая практика , классно руку набивать и выжимать при этом скорость
Хм, так и пришлось заводить шарманку:
csv размером 760Мб 21,5 млн. строк из трех полей: время, бид, аск.
bulk insert первый раз - 2:55, второй, третий раз 2:30 примерно.
Т.е. 10Гб будет минут 30. Но раньше я загонял 5 полей (+объемы по бид и аск). Ну, и оперативки тогда было поменьше - 16Гб, сейчас 48Гб. Но оперативка здесь вряд ли актуальна.
База с журналом стоит на RAID 0 из четырех дисков, довольно быстром: из оперативки 10Гб записывается где-то за 6,5 сек. Два процессора Е5-2450.
--
10ггб у у тебя 30 минут - по расчетам меня будет не более 15 минут , могу проверить - "покрутить шарманку" попробую на 10ггб файле - отпишу позже
Ошибаешься , оперативка очень актуальна ! как у тебя настроен MS SQL в этом плане он у тебя из 16 ггб или из 48ггб сколько кушает ? это очень важно
...на 10 ггб как и рассчитывал ушло 15 минут
т е если у нас при одинаковом кол ядер и примерно одинаковой скорости дисковой подсистемы еще и памяти не такая великая разница - у тебя 48 у меня 64
, при этом разница в скорости загрузки в 2 раза - т е у тебя 30 минут а у меня 15 !
то явно ты что то не так делаешь
Тиковые данные грузятся в виде "как есть" или с обработкой?
У меня не просто грузятся тики, а делается семплирование с периодом 1 сек. Делал профайлинг, много времени уходит на преобразование даты-времени в текстовом формате в Матлабовский формат времени
2015.10.30 05:25:52,1.09766,1.09776
Вот функция парсинга строки, вроде ускорить уже нельзя
Ускорить можно - Вы на каждой строке выбираете, с миллисекундами, или нет.
Сделайте две разных функции и определитесь один раз, какую вызвать в начале загрузки файла.
Ускорить можно - Вы на каждой строке выбираете, с миллисекундами, или нет.
Сделайте две разных функции и определитесь один раз, какую вызвать в начале загрузки файла.
Этот if - сотые доли процента по быстродействию. Основное время занимает парсинг строки в DateTime, потом из строкового в double Bid и Ask. Я знаю, тут была смешная дискуссия, что якобы if ужасно медленная операция.
Могу сказать только одно, те, кто нес этот бред, никогда ассемблера не нюхали и не знают, как if переводится на asm instructions.
Кстати, очень полезно сделать в VS простейший проект командной строки С++, включить в свойствах генерацию asm - кода и потом посмотреть, что же в реальности генерится из кода С++ в каманды asm. Это на многое открывает глаза и лишает иллюзий )). Особенно интересно посмотреть, как VS делает оптимизацию.
У разных ДЦ есть формат .csv - котировок с миллисекундами, а есть без них, поэтому приходится делать этот выбор.
Этот if - сотые доли процента по быстродействию. Основное время занимает парсинг строки в DateTime, потом из строкового в double Bid и Ask. Я знаю, тут была смешная дискуссия, что якобы if ужасно медленная операция.
Могу сказать только одно, те, кто нес этот бред, никогда ассемблера не нюхали и не знают, как if переводится на asm instructions.
Кстати, очень полезно сделать в VS простейший проект командной строки С++, включить в свойствах генерацию asm - кода и потом посмотреть, что же в реальности генерится из кода С++ в каманды asm. Это на многое открывает глаза и лишает иллюзий )). Особенно интересно посмотреть, как VS делает оптимизацию.
У разных ДЦ есть формат .csv - котировок с миллисекундами, а есть без них, поэтому приходится делать этот выбор.
Вы бы сначала проверили, а потом бы рассказывали про ассемблер.
Есть еще по крайней мере 1 способ, как ускорить Ваш код. Но Вам это видимо не сильно надо.
Еще не надо забывать, что ML- это интерпретатор и притягивать сюда VS - это гнать пургу.
А про выбор миллисекунд Вы даже не поняли ;)
Вы бы сначала проверили, а потом бы рассказывали про ассемблер.
Есть еще по крайней мере 1 способ, как ускорить Ваш код. Но Вам это видимо не сильно надо.
Еще не надо забывать, что ML- это интерпретатор и притягивать сюда VS - это гнать пургу.
А про выбор миллисекунд Вы даже не поняли ;)
Приплыли...прямо вот такой чистый интерпретатор? ))) Каждую строчку в цикле заново интерпретирует? ))) Или, может, все же перед запуском программы происходит динамическая компиляция?
Да, объясните мне про выбор миллисекунд. Только четко и с фактами, а то пока лишь понты и апломб ))
Приплыли...прямо вот такой чистый интерпретатор? ))) Каждую строчку в цикле заново интерпретирует? ))) Или, может, все же перед запуском программы происходит динамическая компиляция?
Да, объясните мне про выбор миллисекунд. Только четко и с фактами, а то пока лишь понты и апломб ))
?? Я Вам что-то должен еще раз объяснять?
Мне до вашего апломба далеко.
на 10 ггб как и рассчитывал ушло 15 минут
то явно ты что то не так делаешь
Я сразу преобразую в datetime и numeric, причем datetime - первичный ключ. Это позволяет сразу выявить некоторые ошибки (раньше пользовался чужим загрузчиком тиков - не мало глюков было).
Попробовал просто текст импортировать - быстрее почти в 2 раза. Ну, не суть. Импорт - это пол-дела.
Вспомнил тут, что смотрел профилирование: там самые большие потери были при чтении/записи отдельных полей из курсора. А кроме, как через курсор, я не знаю как последовательно обрабатывать строки.
Да и в чудеса я не верю: не может программа, написанная на .net или java работать быстро )))
Я сразу преобразую в datetime и numeric, причем datetime - первичный ключ. Это позволяет сразу выявить некоторые ошибки (раньше пользовался чужим загрузчиком тиков - не мало глюков было).
Попробовал просто текст импортировать - быстрее почти в 2 раза. Ну, не суть. Импорт - это пол-дела.
Вспомнил тут, что смотрел профилирование: там самые большие потери были при чтении/записи отдельных полей из курсора. А кроме, как через курсор, я не знаю как последовательно обрабатывать строки.
Да и в чудеса я не верю: не может программа, написанная на .net или java работать быстро )))
Понятно !
ну тут как говорится кто как делает ,
--- только bulk insert это совет ---
При загрузках в SQL сервер - по скорости однозначно медленней будет если что то творить с данными в момент передачи между источником и приемником.
Еще в 90х работая с MS SQL версиий 4 - 6 если помните эти старенькие версии , не было Bulk Insert - начиная с 7ки 1998 - перестал практиковать этот подход преобразования внутри передачи именно из за скорости
опыт - работы с хранилищами и базами данных очень больших объемов , выработали особые подходы при загрузки и обработке.
Но опять же историю мы грузим один раз и если не критично уходит на это 8 часов это или 15 минут то можно забить на скорость ,
В принципе надо уделить внимание механизму обновления
но если не научится быстро грузить большой объем то обновлять маленький вряд ли будет быстро ...