Хранилище истории ордеров: схема, оптимизация, pipeline

Разработка хранилища исторических данных ордеров

После года активной торговли вы замечаете: запросы к истории ордеров тормозят, full table scan занимает минуты, а отчёт по P&L за последний квартал не собрать без боли. Мы проектируем хранилище, которое решает эту проблему раз и навсегда. Оно выдерживает 10 000 событий в секунду и отвечает на аналитические запросы за миллисекунды. Это основа для анализа эффективности исполнения, бэктестинга, расчёта комиссий, налоговой отчётности и аудита торговых стратегий.

Какую схему базы данных выбрать для ордеров?

Ордер в торговой системе — это не просто запись «купил 1 BTC по 50000». Полная модель включает несколько типов событий. Хранение этих событий отдельно (Event sourcing) даёт полную воспроизводимость: вы всегда можете восстановить состояние любого ордера на любой момент времени. Для временных рядов ордеров оптимально использовать TimescaleDB или ClickHouse.

TimescaleDB — хороший выбор если уже используете PostgreSQL. Автоматически партиционирует таблицы по времени (hypertables), поддерживает непрерывные агрегации и политики компрессии. Ниже пример схемы для таблицы событий ордеров.

CREATE TABLE order_events ( event_id UUID DEFAULT gen_random_uuid(), event_time TIMESTAMPTZ NOT NULL, order_id UUID NOT NULL, exchange VARCHAR(32) NOT NULL, symbol VARCHAR(32) NOT NULL, event_type VARCHAR(32) NOT NULL, side VARCHAR(8), order_type VARCHAR(16), price NUMERIC(24, 8), quantity NUMERIC(24, 8), filled_qty NUMERIC(24, 8), avg_fill_price NUMERIC(24, 8), commission NUMERIC(24, 8), commission_asset VARCHAR(16), client_order_id VARCHAR(64), strategy_id VARCHAR(64), metadata JSONB ); SELECT create_hypertable('order_events', 'event_time', chunk_time_interval => INTERVAL '1 day'); 

Как оптимизировать запросы к истории ордеров?

Восстановление состояния ордера — частая операция. Вместо повторного вычисления из событий каждый раз, поддерживаем материализованную таблицу orders с текущим состоянием. Обновление этой таблицы происходит при каждом новом событии через триггер или application-side логику.

Аналитические запросы — типично это агрегации по стратегии, инструменту, периоду. Пример запроса P&L по стратегиям:

SELECT strategy_id, symbol, SUM(CASE WHEN side = 'BUY' THEN -filled_qty * avg_fill_price ELSE filled_qty * avg_fill_price END) as realized_pnl, SUM(total_commission) as total_fees, COUNT(*) as order_count FROM orders WHERE created_at BETWEEN CURRENT_DATE - INTERVAL '1 year' AND CURRENT_DATE AND status = 'FILLED' GROUP BY strategy_id, symbol ORDER BY realized_pnl DESC; 

TimescaleDB continuous aggregates позволяют предвычислить эти агрегации и обновлять их инкрементально.

Хранение fills отдельно

Для детального анализа execution quality критично хранить individual fills (частичные исполнения) отдельно от ордеров. Это позволяет рассчитывать VWAP исполнения, сравнивать с mid-price в момент исполнения (market impact), анализировать maker/taker ratio по стратегии.

Retention политики и архивация

Горячие данные хранятся без компрессии для максимальной скорости записи и чтения. Более старые данные компрессируются. Компрессия TimescaleDB даёт 10–20x уменьшение размера для временных рядов с повторяющимися значениями. Данные старше 2 лет можно экспортировать в Parquet-файлы на S3 с помощью pg_parquet или custom ETL, сохраняя возможность исторического анализа через Athena или ClickHouse.

Ingestion pipeline

Высокочастотная запись требует batching. Вместо INSERT на каждый event используем COPY для bulk inserts — в 10–50x быстрее. Накапливаем события в памяти (100 ms или 1000 событий) и записываем одним COPY. Unlogged tables для промежуточного буфера — WAL не пишется, скорость записи значительно выше. Connection pooling через PgBouncer позволяет обслуживать тысячи клиентов.

ALTER TABLE order_events SET ( timescaledb.compress, timescaledb.compress_segmentby = 'exchange, symbol', timescaledb.compress_orderby = 'event_time DESC' ); SELECT add_compression_policy('order_events', INTERVAL '30 days'); 

Мониторинг и алерты

Ключевые метрики для мониторинга хранилища:

Потеря ордеров — критический инцидент. Система должна иметь механизм reconciliation: периодически сравнивать локальную историю с данными биржи через REST API и заполнять пробелы.

Репликация и отказоустойчивость

Production-хранилище работает в режиме streaming replication PostgreSQL: primary для записи, replica для аналитических запросов. При падении primary — failover через Patroni с автоматическим переключением. RPO при правильной настройке synchronous_commit — нулевой. TimescaleDB Documentation рекомендует такую конфигурацию для критичных систем. Наша команда 10 лет занимается блокчейн-разработкой и внедряла подобные решения для фондов с оборотом $1B+.

Что входит в работу

• Документация схемы данных и архитектуры пайплайна.
• Код схемы TimescaleDB/ClickHouse, триггеров, политик компрессии.
• Настроенный ingestion pipeline с batching и connection pooling.
• Скрипты миграции и развёртывания (CI/CD).
• Дашборды мониторинга (Grafana + Prometheus).
• Runbook и обучение вашей команды (2–3 сессии).
• Пост-релизная поддержка на 2 недели.

Как мы разрабатываем хранилище

1. Анализ нагрузки — профилируем существующий трафик, определяем RPS и типичные запросы.
2. Проектирование схемы — выбираем между TimescaleDB и ClickHouse, проектируем hypertables и индексы.
3. Реализация pipeline — настраиваем batching, connection pooling, unlogged tables.
4. Настройка компрессии и retention — задаём политики для горячих и холодных данных.
5. Репликация и мониторинг — разворачиваем Patroni, настраиваем алерты и дашборды.
6. Тестирование под нагрузкой — симулируем 50 000 событий/с и проверяем p99 latency.
7. Документация и обучение — передаём код, схемы и runbook вашей команде.

Оценка проекта

Оценим ваш проект бесплатно в течение 2 рабочих дней. Пришлём рекомендации по архитектуре и смету в человеко-месяцах. Свяжитесь с нами — обсудим ваши сценарии использования и поможем спроектировать надёжное хранилище, которое не подведёт. Получите консультацию уже сегодня.