Разработка хранилища исторических данных ордеров
После года активной торговли вы замечаете: запросы к истории ордеров тормозят, 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 политики и архивация
| Тип данных | Период хранения | Формат | Компрессия |
|---|---|---|---|
| Hot | Последние 30 дней | ClickHouse / TimescaleDB (native) | Нет |
| Warm | 31–730 дней | Сжатые чанки (10–20x) | Включена |
| Cold | Старше 2 лет | Parquet на S3 | Плюс |
Горячие данные хранятся без компрессии для максимальной скорости записи и чтения. Более старые данные компрессируются. Компрессия 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 позволяет обслуживать тысячи клиентов.
Пример настройки компрессии в TimescaleDB
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'); Мониторинг и алерты
Ключевые метрики для мониторинга хранилища:
| Метрика | Норма | Алерт |
|---|---|---|
| Write latency (p99) | < 10ms | > 50ms |
| Query latency (p99) | < 100ms | > 500ms |
| Replication lag | < 1s | > 10s |
| Disk usage growth | Предсказуемо | Аномальный рост |
| Failed inserts | 0 | Любые |
Потеря ордеров — критический инцидент. Система должна иметь механизм 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 недели.
Как мы разрабатываем хранилище
- Анализ нагрузки — профилируем существующий трафик, определяем RPS и типичные запросы.
- Проектирование схемы — выбираем между TimescaleDB и ClickHouse, проектируем hypertables и индексы.
- Реализация pipeline — настраиваем batching, connection pooling, unlogged tables.
- Настройка компрессии и retention — задаём политики для горячих и холодных данных.
- Репликация и мониторинг — разворачиваем Patroni, настраиваем алерты и дашборды.
- Тестирование под нагрузкой — симулируем 50 000 событий/с и проверяем p99 latency.
- Документация и обучение — передаём код, схемы и runbook вашей команде.
Оценка проекта
Оценим ваш проект в течение 2 рабочих дней. Пришлём рекомендации по архитектуре и смету в человеко-месяцах. Свяжитесь с нами — обсудим ваши сценарии использования и поможем спроектировать надёжное хранилище, которое не подведёт. Получите консультацию уже сегодня.







