Розробка сховища історичних даних ордерів
Після року активної торгівлі ви помічаєте: запити до історії ордерів гальмують, 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 зменшення розміру — це в 10-20 разів краще, ніж зберігання без компресії. Дані старші 2 років експортуються в Parquet-файли на S3, реалізуючи архівацію ордерів, при цьому зберігаючи можливість історичного аналізу через Athena або ClickHouse.
Ingestion pipeline (пайплайн завантаження)
Високочастотний запис вимагає batching. Замість INSERT на кожен event використовуємо COPY для bulk inserts — у 10-50 разів швидше. Накопичуємо події в пам'яті (100 ms або 1000 подій) і записуємо одним COPY. Unlogged tables для проміжного буфера — WAL не пишеться, швидкість запису значно вища. Connection pooling через PgBouncer дозволяє обслуговувати тисячі клієнтів. Ефективний інгейшн пайплайн ордерів критично важливий для high-frequency trading.
Приклад налаштування компресії в 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 — нульовий. Гарантуємо цілісність даних завдяки synchronous_commit та Patroni кластеру. Ми гарантуємо надійність, підтверджену досвідом впровадження у фондах з обігом понад $1 млрд. Наша команда — понад 10 років досвіду в блокчейн-розробці, 30+ реалізованих проектів.
Що входить в роботу
- Документація схеми даних та архітектури пайплайну.
- Код схеми 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 робочих днів. Вартість впровадження починається від $5,000, а економія на інфраструктурі може сягати 60%. Надішлемо рекомендації з архітектури та кошторис у людино-місяцях. Зв'яжіться з нами — обговоримо ваші сценарії використання та допоможемо спроектувати надійне сховище, яке не підведе. Отримайте консультацію вже сьогодні.