MinIO, MongoDB, PostgreSQL для хранения 25 лет истории стоимости акций

[ValentinAndreev]

У PG есть timescaledb, очень даже хорошо работает и запросы на чтение во много раз быстрее и в несколько раз меньше по объему. А главное - встроенная агрегация, то есть скачиваем 1m таймфрейм, устанавливаем политики агрегации и получаем MATERIALIZED VIEW под основные. И есть возможность без них на лету агрегировать вообще произвольный таймфрейм - тоже достаточно быстро, быстрее чем обычные запросы к таблице.

[tripolskypetr]

Если кратко, победило решение-конструктор, которое собрано из модулей, а не универсальная сборка под все случаи жизни

[joeberetta]

Хотелось бы увидеть более долгый ответ тоже)

Пока был неопытный было дело и пришлось поработать с timescale и периодически ловил странные ошибки с лимитами каким-то (уже не помню точно что за ошибки, пару лет прошло)

И 2е - у монго также есть встроенные time series коллекции, которые как раз таки дают возможность эффективнее работать с такими данными (по итогу пару лет вместо таймскейл юзал их, у меня данных было побольше за те же пур лет, т.к. крутил данные за Х валют сразу, поминутных, но к скорости прям таких требований не было, т.к. это был рейт сервис в 1ю очередь с выборкой за определённый промежуток для разных пар валют и веб апп мог пару сек подождать если большое колво точек надо тянуть)

[ValentinAndreev]

Я когда timescale настраивал у меня только одна проблема была небольшая - не работали политики агрегации, там настройки по офсету и размеру окна - вроде разумные, но - просто не работали, сделал с большим перехлестом (благо работают инкрементально) и все стало ок. Забыл написать, что там еще и gapfill есть и иерархическая агрегация (1m по сырым данным агрегируем, 5m по 1m, 1h по 5m и так далее, но не стал делать так как просто явно была бы преждевременная оптимизация - и так все летало на слабеньком серваке).

[u_story]

" Чтобы проверить автоматизированную торговую стратегию, нужно сделать виртуальное время, которое итерацией пройдет весь этот массив данных по одной свече. " - это не совсем так.
есть стаканы, где хранятся заявки и предложения. когда вы тестируете стратегию, вы не используете информацию о состоянии стакана и ценах там.
поэтому при переходе от бэктеста в продакшен, может оказаться, что ликвидности в стакане не хватит на ваши сделки (например, 1 бумага по цене лучшей стоит, а следующая заявка на 10% хуже по цене) или боты начнут с вами гоняться и рушить вашу стратегию в моменте (например, отменяя заявки в стакане) и т.д.

поэтому для проверки лучше брать стаканы как есть. ну и это даже не гарантирует результата.

[joeberetta]

Не хватает кармы для апвоута, поэтому пишу так, поддерживаю, арбитражного бота пока пилили, нахлебались подобного

[tripolskypetr]

Почему нельзя взять VWAP за 5 минут чтобы усреднить стакан и предложение было стабильным?

Для крипты датасет стакана - редкое явление. Обычно можно найти завершенные сделки или свечи

[u_story]

можно взять как угодно, но чем "грубее" данные - тем выше риск.

мы в 2017 сами собирали стаканы с 20+ бирж криптовых, в итоге нахлебались того, что стаканы часто рисованные. во время твоей зявки стакан моментально исчезал, ты ловил -25% к цене, а потом он снова рисовался.