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
- акции
- алготрейдинг
- алготрейтинг
- архитектура
- волаильность
- волатильность
- вопрос
- временной распад
- глубокое обучение
- данные
- долгосрок
- Европа
- инвестирование
- инвестирование без убытков
- инвестиции
- Инвестиции в недвижимость
- источник данных
- календарный спрэд
- Книги
- машинное обучение
- метрики
- мобильный пост
- накопления
- Недвига
- недвижимость
- нейронные сети
- опционы
- ордер
- отзыв
- открытые позиции
- помощь
- портфель
- программироание
- Программирование
- продажа опционов
- простота
- реальность
- рецензия
- рецензия на книгу
- робот
- стратегии
- структура
- торговая система
- торговля
- торговые роботы
- торговые сигналы
- торговые системы
- трейдинг
- фреймворк
- фундаментальный анализ
- хедж
- хэдж
- эксперимент
Придумывать ничего не нужно:
1. Для ленивых:
Пишешь бары в БД сразу DtOHLCV
База данных 5-секундных баров по RI, Si, SR c 2015 года по наст. время занимает всего лишь ~ 5 гигов. Очень даже приемлимо.
2. Не для ленивых
Делаешь примерно так, описывать неохота
2.1:
var bytesBar = BinarySerialization.SerializeToByteArray(bars);
var bsBarsZip = Compressor.Compress(bytesBar);
Далее пишешь в БД образ по дням.
Здесь делаешь BinarySerialization
сжимаешь,
пишешь в БД по дням.
2.2.
var barsStr = bars.Select(b => b.ToStr()).ToList();
var bytesBarStr = BinarySerialization.SerializeToByteArray(barsStr);
var bsBarsStrZip = Compressor.Compress(bytesBarStr);
Далее пишешь в БД образ по дням.
Здесь в начале Бары сериализуешь в List<string>,
потом делаешь BinarySerialization
и далее сжимаешь.
Этот вариант работает быстрее — проверено юнит-тестами
В БД информация хранится по дням и тикерам.
Желаю успехов.
Там string-ы быстрее сериализуются, чем класс bar-ы.
У меня так получилось.
t1 = time для варианта 2.1
t2 = time для варианта 2.2
t3 = это при упаковке каждой строки, не описал 2.3
BytesBar, BytesBarStr, BytesBarStrPacked — это размер образов в байтах для вариантов 2.1, 2.2, 2.3 для одного дня по RI,
если мне память совсем еще не отшибло по-моему так.
Получается самый компактный — это 2.2
public class BarDto: IBarBase
{
public BarDto();
public DateTime DT { get; set; }
public double Open { get; set; }
public double High { get; set; }
public double Low { get; set; }
public double Close { get; set; }
public double Volume { get; set; }
public override string ToString();
}
Denis, нет я не знаю.
Я использую технологии Microsoft: MS SQL , С# — сейчас
А компрессор можно взять для С# в using System.IO.Compression;
Мне уже поздно распыляться, я уже забываю что я вчера делал.
2. В конце дня эти бары читаются из файла дневого либо из БД за один последний день (у меня из БД) и далее выполняются варианты 2.1 либо 2.2 — пишутся образы в БД.
3. На полноту не проверяю
Это лучше при тестах — можно не выгружать сразу все в память. и будет быстрее чем запрос в бд тиков за один день. все зависит от того, что вы тестируете и как. у меня не получалось получать быстрее тики из бд, чем из бинарников. если уж хочется бд, то посмотрите на influx
Дилема как бы такая сложность упаковки распоковки против стоимости гигабайтов :).
В целом к тикам я сейчас еще и бид/аск сохраняю… вдруг когда понадобится.
Denis, да надо просто погуглить «алгоритмы упаковки данных».
Кстати такую задачу решил Николай Морошкин со своим приводом qscalp. И выложил формат данных и упаковки на своем сайте, вдруг будет полезным
Но непонятно, что поучительного в тиковой истории котировок за 4 года? Неужто кто-то научился выуживать из этих данных некие внутренние различия?
про память, я выше писал, это как раз таки и есть дилема, террабайты нынче дешев особенно если хдд… но и ссд не так дорог.
Что то мне кажется я слишком много оптимизацией занимаюсь :)
Помотрите его внимательно, там присутствует бинарная сериализация.
В варианте 2.2 в начале List<Bar> — перегоняется в List<string>,
а затем делается сериализация List<string>
Т.е. получается вы сохраняете сперва где то на диске весь день данных, потом потом пакуете и базу. А позвольте поинтерисоваться, вы перед тем как данные загонять в базу, проверяете их целостность? все ли бары были получены, и если были разрывы то заполняети ли все из истории?
Сорри за столько вопросов… я просто как погрузился в сохранение данных, всплыло масса деталей.
Не очень понятен вопрос.
Сколько тикеров вы собираете ?
За какой период ?
В каком фрейме ?
Как дальше будут использоваться эти данные ?
1. на данный момент всего 10
2. за весь период пока мой домашний сервер подключен к брокеру. Я не выкачиваю историю… собираю реалтайм, хотят тут разницы нет.
3. что значит фрейм? тики+бид/аск и еще 5сек бары
4. в осоновном для анализа и для стадии инициалицации алгоритма, т.е. первого его старта. все банально.
Denis, как я понимаю для инициализации робота нужно не очень много данных.
Так что этот хвостик можно держать не запакованным.
Для анализа скорость выборки не имеет значения.
Соответственно можете паковать в любом формате.
Если оно занимает существенный объём диска.
И если вам не нужна какая-то выборка по условиям.
Если места хватает, то можно использовать обычную либо nosql базу и удобно хранить, выбирать, сортировать.
Про форматы хранения написали выше.
Только зарегистрированные и авторизованные пользователи могут оставлять ответы.
Залогиниться
Зарегистрироваться