SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
теги блога CloseToAlgoTrading
- algo
- algorithmic trading
- algotrading
- API
- C++
- closetoalgotrading
- cuda
- Data Science
- deep learning
- Earning season
- ETF
- ETN
- finance
- IB
- Interactive Brokers
- machine learning
- momentum
- neural network
- open source
- portfolio
- portfolio managment
- python
- reinforcement learning
- RL
- Sharpe Ratio
- strategy
- tensorflow
- video
- акции
- алготрейдинг
- алготрейтинг
- архитектура
- волаильность
- волатильность
- вопрос
- временной распад
- глубокое обучение
- данные
- долгосрок
- Европа
- инвестирование
- инвестирование без убытков
- инвестиции
- Инвестиции в недвижимость
- источник данных
- календарный спрэд
- Книги
- машинное обучение
- метрики
- мобильный пост
- накопления
- Недвига
- недвижимость
- нейронные сети
- опционы
- ордер
- отзыв
- открытые позиции
- помощь
- портфель
- программироание
- Программирование
- продажа опционов
- простота
- реальность
- рецензия
- рецензия на книгу
- робот
- стратегии
- структура
- торговая система
- торговля
- торговые роботы
- торговые сигналы
- торговые системы
- трейдинг
- фреймворк
- фундаментальный анализ
- хедж
- хэдж
- эксперимент
www.influxdata.com/time-series-platform/influxdb/
А насколько они лучше обычных бд. т.е. как там получением данных по каким нить завернутым запросам? :) И в целом удобно ли потом с данными работать?
Да, в целом направление молодое, может не устроить банк (если я правильно расшифровываю LBBW). У нас работает стабильно, нагрузка на железо при подобном режиме работы — минимальна.
Лучше обычных DB скоростью работы, в десятки раз быстрее.
С данными работать удобно — там поддерживается sql
UPD. Это скриншот из встроенного веб-интерфейса, писать данные можно через HTTP API
docs.influxdata.com/influxdb/v1.0/guides/writing_data/
Поддержка sql это хорошо.
Но думаю, что даже в случае внезапного закрытия проекта (пока считаю маловероятным) у вас есть возможность использовать его ещё лет десять. Бинарники на go отличаются тем, что линкуются полностью статически и не содержат никаких внешних зависимостей. Так что если текущий функционал вас полностью устраивает, то можно годами жить без апдейтов (ну и с учётом того, что это закрытая система, а не наружу в интернет).
На данный момент я использую постргри но в таком очень простом его виде, без всяких там примочек.
Но как то у меня не очень удобные структуры данных выходят, все ж приходит асинхронно, поэтому походу хранить чистые не подготовленные данные самое простое решение, но не самое эфективное.
Кстати, а у этой бд есть какая библиотека под C/C++?
Список актуальных API - https://docs.influxdata.com/influxdb/v1.0/tools/api_client_libraries/
— не грузить БД мелкими sql запросами на добавление
— копить данные в некий промежуточный буфер какое то время и потом разом добавить в БД (лично я после мытрств остановился на том, что делаю это 2 раза в сутки и все).
Исходя из этого, пришлось выбирать БД, которая умеет некий буфер сразу помещать в таблицу, без множественных insert запросов. То есть вам нужно добавить к примеру в таблицу 1000 записей и она будет делать не 1000 инсертов, а один какой то свой метод. FIREBIRD например так делать не умеет.
Так умеет делать например:
— sybase
— так умеет делать c# с Entity Framework в связке с Microsoft SQL (тут вообще можно на потоки разделить, если ядер не одно)
— еще какие нибудь БД, с которыми я не столкнулся =)
На примере, если нужно добавить тысяч 200 записей, 200т инсертов может занять минут 8, особенно если много индексов.
Подход через промежуточный буфер решает это секунд за 7-10.
Но тогда второй вопрос, быстро обрабатывать потом данные. Тут уже придется грамотно выстроить индексацию полей и sql запросы на выборку. Вооружайтесь тогда анализаторами и боритесь за секунды =)) При этом надо иметь ввиду, что большое кол-во индексов прямиком влияет на время добавления данных. Приходится все время варьировать в этом вопросе, что выбрать, быстрый insert или быстрый select
В моем случае работа с бд, и работа системы онлайн как бы разделены. Но никто ж не знает как оно будет в будущем )).
А используете чистые данные для записи или делаете какую то предобработку, форматирование?
Но если вы познакомитесь с современными плюшками, там уже даже думать не надо. =)) это я про Entity Framework. Олд скул программирование БД все больше уходит в прошлое =))
Насколько понимаю, твоя задача тривиальна и решается по сути двумя способами(без костылей), Это мелгомягкие технологии или Джава Энтерпрайз(EJB 3.0)- зачем изобретать велоcипеды?
Если брать обычную бд, и сырые данные, то получается что мы имеем много так сказать не нужной информации… тот же тикер ид в каждой из таблиц, но как то же надо их связывать и идентифицировать.
Хотел узнать может есть какой опыт наработанный уже. Что бы не натыкаться на ошибки проектирования :). Но как Андрей сказал имееет смысл смотреть на конкретных задачах.
по поводу .net и явы… первое хорошо но у меня связка c++/qt… ну и иногда питон. А яву я по религиозным причинам не люблю %)
В дальнейшем возможно понадобится эти самые данные обрабатывать онлайн.
Хотя, что вы имеете ввиду онлайн?
Сама система будет работь на лету с данными от брокера в обход бд, но возможно понадобится некоторые вещи подкачивать из базы.
Только зарегистрированные и авторизованные пользователи могут оставлять ответы.
Залогиниться
Зарегистрироваться