21 сентября 2016, 11:04

Поделитесь, какую структуру базы данных выбирали для более быстрого доступа(сохранения)потоковых данных? какую организацию данных выбрали и почему?

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

алготрейдинг вопрос

CloseToAlgotrading

CloseToAlgoTrading

не определен

117

814

с 11 февраля 2016

20 Комментариев

CloseToAlgoTrading
21 сентября 2016, 11:06
Задача стоит в сохранении потоковых данных тиков, объемов и поток ордеров (акции, опционы). Так же синхронизация с историей яхуфинанс. Все для дальнейшего анализа офлайн и на лету.

+1
Leo
21 сентября 2016, 11:21
Посмотрите на influxdb, она заточена на подобные задачи. Мы там храним данные мониторинга — прилетает тысячи метрик в секунду, т.е. задача примерно схожая
www.influxdata.com/time-series-platform/influxdb/
+3
- CloseToAlgoTrading
  21 сентября 2016, 12:02
  Lev, спасибо за наводку, очень интересно… надо углубиться, это так называемая база временных рядов, но что то вроде как очень молодая.
  А насколько они лучше обычных бд. т.е. как там получением данных по каким нить завернутым запросам? :) И в целом удобно ли потом с данными работать?
  +1
Leo
21 сентября 2016, 12:26
Да, в целом направление молодое, может не устроить банк (если я правильно расшифровываю LBBW). У нас работает стабильно, нагрузка на железо при подобном режиме работы — минимальна.
Лучше обычных DB скоростью работы, в десятки раз быстрее.
С данными работать удобно — там поддерживается sql

UPD. Это скриншот из встроенного веб-интерфейса, писать данные можно через HTTP API
docs.influxdata.com/influxdb/v1.0/guides/writing_data/
+1
- CloseToAlgoTrading
  21 сентября 2016, 12:47
  Lev, LBBW в моем случае обозначения города и земли. Не банк. :) Проект частный так что любое направление подойдет. Просто не хочется потом все перестраивать если вдруг логика работы с данными поменяется.
  Поддержка sql это хорошо.
  
  0
  - Leo
    21 сентября 2016, 13:16
    Denis, ну вы сами понимаете, что никаких гарантий я вам дать не могу.
    Но думаю, что даже в случае внезапного закрытия проекта (пока считаю маловероятным) у вас есть возможность использовать его ещё лет десять. Бинарники на go отличаются тем, что линкуются полностью статически и не содержат никаких внешних зависимостей. Так что если текущий функционал вас полностью устраивает, то можно годами жить без апдейтов (ну и с учётом того, что это закрытая система, а не наружу в интернет).
    
    0
    - CloseToAlgoTrading
      21 сентября 2016, 14:10
      Lev, гарантий я не требую, инетресно опыт других людей узнать.
      На данный момент я использую постргри но в таком очень простом его виде, без всяких там примочек.
      Но как то у меня не очень удобные структуры данных выходят, все ж приходит асинхронно, поэтому походу хранить чистые не подготовленные данные самое простое решение, но не самое эфективное.
      Кстати, а у этой бд есть какая библиотека под C/C++?
      0
      - Leo
        21 сентября 2016, 14:21
        Denis, насколько я могу судить, библиотека на C была, но считается устаревшей. Но судя по коду, думаю что можно адаптировать, там не сильно сложно на мой взгляд, простой сетевой обмен, можно поверх libcurl написать какой-то враппер
        
        Список актуальных API - https://docs.influxdata.com/influxdb/v1.0/tools/api_client_libraries/
        0
        CloseToAlgoTrading
        21 сентября 2016, 14:26
        Lev, как говаривают немцы, алес клар :). спасибо за наводку поглядим.
        0
Андрей К
21 сентября 2016, 13:39
О! постою послушаю =))
0
Андрей К
21 сентября 2016, 13:43
Кстати, а задача стоит также их и онлайн обрабатывать параллельно в бд?
0
- CloseToAlgoTrading
  21 сентября 2016, 14:04
  Андрей К, В данном случае еще не знаю, пока надо просто кидать в базу, что бы потом можно было вменяемы анализ делать, модели всякие обучать и т.д.
  В дальнейшем возможно понадобится эти самые данные обрабатывать онлайн.
  Хотя, что вы имеете ввиду онлайн?
  
  Сама система будет работь на лету с данными от брокера в обход бд, но возможно понадобится некоторые вещи подкачивать из базы.
  0
Андрей К
21 сентября 2016, 14:10
Если просто кидать, то из опыта, что делал я:
— не грузить БД мелкими sql запросами на добавление
— копить данные в некий промежуточный буфер какое то время и потом разом добавить в БД (лично я после мытрств остановился на том, что делаю это 2 раза в сутки и все).

Исходя из этого, пришлось выбирать БД, которая умеет некий буфер сразу помещать в таблицу, без множественных insert запросов. То есть вам нужно добавить к примеру в таблицу 1000 записей и она будет делать не 1000 инсертов, а один какой то свой метод. FIREBIRD например так делать не умеет.

Так умеет делать например:
— sybase
— так умеет делать c# с Entity Framework в связке с Microsoft SQL (тут вообще можно на потоки разделить, если ядер не одно)
— еще какие нибудь БД, с которыми я не столкнулся =)

На примере, если нужно добавить тысяч 200 записей, 200т инсертов может занять минут 8, особенно если много индексов.
Подход через промежуточный буфер решает это секунд за 7-10.
+1
- CloseToAlgoTrading
  21 сентября 2016, 14:19
  Андрей К, Это кстати очень хорошее наблюдейние/замечание, а позвольте поинтерисоваться, тут уж просто из любопытства. Если вы эти данные надо использовать сразу в другом процессе который их берет из бд, как вы обходите задержку по времени? скажем если к вам пришло 999 значений за первую секунду, а последнее пришло через 10 минут? или это не актуально в ваших задачах?
  0
  - Андрей К
    21 сентября 2016, 14:23
    Denis, да, не совсем актуально. Я поэтому и спросил уточняющий вопрос. В вашем тогда вопросе придется долбить инсертами получается, на вскидку ничего и не придумать дельного.
    Но тогда второй вопрос, быстро обрабатывать потом данные. Тут уже придется грамотно выстроить индексацию полей и sql запросы на выборку. Вооружайтесь тогда анализаторами и боритесь за секунды =)) При этом надо иметь ввиду, что большое кол-во индексов прямиком влияет на время добавления данных. Приходится все время варьировать в этом вопросе, что выбрать, быстрый insert или быстрый select
    0
    - CloseToAlgoTrading
      21 сентября 2016, 14:31
      Андрей К, секунды в нашем вопросе слишком долго :). Но в теории можно пользовать временные интервалы для выгрузки данных, скажем туже каждую секунду.
      В моем случае работа с бд, и работа системы онлайн как бы разделены. Но никто ж не знает как оно будет в будущем )).
      
      А используете чистые данные для записи или делаете какую то предобработку, форматирование?
      
      0
      - Андрей К
        21 сентября 2016, 14:57
        А используете чистые данные для записи или делаете какую то предобработку, форматирование?
        как я уже сказал, если время ценно, то приходится проводить опыты. Что быстрее в конретном примере: обработать заранее и добавить в БД, либо потом при выборке обрабатывать в sql
        
        Но если вы познакомитесь с современными плюшками, там уже даже думать не надо. =)) это я про Entity Framework. Олд скул программирование БД все больше уходит в прошлое =))
        0
    - Капитан Сильвер
      21 сентября 2016, 14:33
      Автор, тебе Анрей К, првильно говорит. NET framework+ плюшки от майкрософта.
      Насколько понимаю, твоя задача тривиальна и решается по сути двумя способами(без костылей), Это мелгомягкие технологии или Джава Энтерпрайз(EJB 3.0)- зачем изобретать велоcипеды?
      0
      - CloseToAlgoTrading
        21 сентября 2016, 18:36
        Капитан Сильвер, так я ничего и не изобретаю, мой вопрос был не сколько о что за бызу юзать, сколько о том как данные организовать. Видимо не правильно поставил.
        Если брать обычную бд, и сырые данные, то получается что мы имеем много так сказать не нужной информации… тот же тикер ид в каждой из таблиц, но как то же надо их связывать и идентифицировать.
        Хотел узнать может есть какой опыт наработанный уже. Что бы не натыкаться на ошибки проектирования :). Но как Андрей сказал имееет смысл смотреть на конкретных задачах.
        
        по поводу .net и явы… первое хорошо но у меня связка c++/qt… ну и иногда питон. А яву я по религиозным причинам не люблю %)
        
        0
CloseToAlgoTrading
21 сентября 2016, 18:31
почитал немного про таймсериес бд и что то как то не могу для себя понять, чем же они лучше обычных реляционных бд.
0

Читайте на SMART-LAB:

Страховка на миллион: как Tickmill защищает ваши средства через Lloyd's of London

Многие брокеры не предлагают никакой страховки сверх того, что требует регулятор. Мы в Tickmill считаем, что этого недостаточно и пошли дальше. Сегодня рассказываем подробнее: кто нас...

Tickmill

12.05.2026

Длинные ОФЗ ― в фокусе внимания инвесторов

Длинные ОФЗ сейчас выглядят одним из самых интересных инструментов для инвестора, который хочет получить не только купонный доход, но и результат от возможного снижения рыночных...

Финам Брокер

12.05.2026

Записки инвестора. Ключевые тренды и события на рынке

«Записки инвестора» — еженедельная рубрика для быстрого погружения в рынок. Мы выделяем самые важные события, за которыми стоит следить — и вы можете пробежаться по ним буквально за пару...