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

Значимый прорыв формирует отрасль ИИ: tripolskypetr 3 минуты назад MinIO, MongoDB, PostgreSQL для хранения 25 лет истории стоимости акций Сложный 7 мин 1 PostgreSQL * MongoDB * Базы данных * TypeScript * Python * Аналитика Исходный код биндинга MinIO можно посмотреть по ссылкеУ акции нет точной цены, так как для каждого покупателя должен найтись продавец. Биржы хранят цены акций как японские свечи за минуту: самая большая цена за минуту, самая малая цена за минуту, цена открытия первый момент открытия торгового периода, цена закрытия в последний момент торгового периода. Итого: 25 лет истории × 20 тикеров × 525 600 минут в году ≈ 262,8 млн записей[ { "time": 1720958400, "open": 450.

]Чтобы проверить автоматизированную торговую стратегию, нужно сделать виртуальное время, которое итерацией пройдет весь этот массив данных по одной свече. Если усреднить и взять свечи за один час, получится close-to-close, не точный бектест. Я попробовал несколько вариантов баз данных и хочу рассказать об этомПрофиль нагрузкиclass CandleAdapter implements IPersistCandleInstance { constructor( readonly symbol: string, readonly interval: CandleInterval, readonly exchangeName: string, ) {} async waitForInit(initial: boolean) { /* поднять инфраструктуру */ } async readCandlesData(limit: number, sinceTimestamp: number) { /* ...

Технические детали

*/ } async writeCandlesData(candles: CandleData) { /* ... */ } }Записи иммутабельны. Свеча за конкретную минуту не меняется никогда.

Значит, нужен только идемпотентный upsert, который применит только недостающие записи. Прогон стратегии — это на 99% чтение: точечные выборки одной свечи по ключу (биржа, символ, интервал, timestamp), много и параллельно. Нужен строгий контракт видимости (о нём ниже) — иначе конкурентная запись рассыпается.

Мы не хотим сразу скачивать все 525 миллионов записей, нужен lazy loadingКонтракт видимости записиУ движка жёсткое требование к долговечности записи: после того как writeCandlesData вернул управление, следующий же readCandlesData обязан увидеть записанное. Файловый адаптер выполняет его тривиально (fs. readFile увидят друг друга).

Отраслевые последствия

А вот наивная реализация поверх любой БД — «прочитай, если нет — вставь» — контракт нарушает на конкурентной записиОба писателя видят «записи нет», оба вставляют, второй ловит duplicate key, движок уходит в ретрай. Именно то, как каждая база закрывает эту гонку без потери контракта, и определяет её место в обзоре. MinIO: объектное хранилище, отказ от файловПопытка себя не оправдала: MinIO создает по новому отдельному файлу на жестком диске с метаданными для каждого объекта свечиБазовой реализацией было сохранение файлов на жесткий диск.

Я предположил что можно не менять модель данных вообще: JSON-документ остаётся JSON-документом, просто переезжает с локального диска в S3-совместимое объектное хранилище.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.