Сырые данные из блокчейна или бирж накапливаются быстро — десятки гигабайт в день для активно парсимых источников. Типичный проект: парсинг 5000 кошельков каждые 10 секунд — это 43 млн строк в день. Через полгода объём достигает 7.8 млрд строк. Хранить это в обычном PostgreSQL в одной таблице означает деградацию запросов через несколько месяцев. Мы проектируем системы хранения на TimescaleDB или ClickHouse под конкретные паттерны запросов и объёмы. Выбор между этими базами — прагматический, не религиозный. Стоимость хранения после компрессии снижается на 80%, а запросы ускоряются в десятки раз. Наши клиенты часто сталкиваются с ростом объёмов после трёх месяцев эксплуатации: запросы начинают выполняться десятки секунд, стоимость хранения растёт. Мы предлагаем архитектуру, которая масштабируется линейно — добавляем новые ноды без даунтайма. Получите консультацию по выбору СУБД для ваших данных.
Когда выбирать TimescaleDB, а когда ClickHouse?
TimescaleDB — расширение PostgreSQL. Добавляет hypertables (автоматическое партиционирование по времени), continuous aggregates (инкрементальные материализованные представления), compression. Вы остаётесь в PostgreSQL-экосистеме: стандартный SQL, ACID транзакции, JOIN с обычными таблицами, привычный инструментарий.
ClickHouse — колоночная OLAP база. Данные хранятся по столбцам, что даёт огромный выигрыш при агрегациях по подмножеству колонок. Скорость GROUP BY и SUM на миллиардах строк — на порядок выше PostgreSQL. Слабая сторона: нет транзакций, UPDATE/DELETE — дорогие операции, JOIN работает иначе.
| Критерий | TimescaleDB | ClickHouse |
|---|---|---|
| Паттерн запросов | Сложные JOIN, OLTP+OLAP mix | Аналитика, агрегации по большим диапазонам |
| Запись | INSERT в транзакции, UPSERT | Batch insert, eventual дедупликация |
| Чтение точечное | Быстро (B-tree индексы) | Медленнее (нет эффективных точечных) |
| Аналитика | Хорошо | Намного быстрее |
| Обновления | Стандартный UPDATE | Дорого (ReplacingMergeTree) |
| Операционная сложность | Умеренная | Выше |
| Объём данных | До ~1TB эффективно | Эффективно с 100GB+ |
Рекомендация для парсинга on-chain данных:
- TimescaleDB — если данные нужны для продуктовой логики (балансы, позиции, аккаунты), есть JOIN с реляционными данными, нужны ACID-гарантии
- ClickHouse — если это аналитический pipeline (trading сигналы, агрегированная статистика, исторический анализ), запросы работают с большими диапазонами дат
В production часто комбинируют: TimescaleDB для горячих/операционных данных + ClickHouse для аналитического warehouse. Такая связка даёт до 90% экономии на хранении холодных данных. Получите консультацию — мы поможем выбрать оптимальную СУБД.
Как настроить компрессию в TimescaleDB?
Базовая концепция: обычная таблица PostgreSQL превращается в hypertable — под капотом создаются чанки (partitions) по временному измерению. Каждый чанк — отдельный файл, старые чанки можно компрессировать или архивировать.
CREATE TABLE trades ( time TIMESTAMPTZ NOT NULL, exchange TEXT NOT NULL, symbol TEXT NOT NULL, price NUMERIC(20, 8) NOT NULL, volume NUMERIC(20, 8) NOT NULL, side CHAR(4) NOT NULL ); SELECT create_hypertable('trades', 'time', chunk_time_interval => INTERVAL '1 day'); CREATE INDEX ON trades (symbol, time DESC); Continuous aggregates заменяют дорогие realtime GROUP BY на инкрементальные материализованные представления. Теперь запрос SELECT * FROM trades_1m WHERE bucket > NOW() - INTERVAL '1 day' — это SELECT из материализованного представления, не агрегация по raw данным.
Старые данные компрессируются почти без потери функциональности (кроме UPDATE/DELETE):
ALTER TABLE trades SET ( timescaledb.compress, timescaledb.compress_orderby = 'time DESC', timescaledb.compress_segmentby = 'symbol' ); SELECT add_compression_policy('trades', INTERVAL '7 days'); Типичная степень сжатия для биржевых данных: 10–20x. 100GB raw -> 5–10GB compressed. Экономия на хранении достигает 80% для данных старше месяца. Ознакомьтесь с документацией TimescaleDB для деталей.
Архитектура ClickHouse
Выбор engine — критический момент. Для парсинг-данных чаще всего используются MergeTree, ReplacingMergeTree (дедупликация) и SummingMergeTree (агрегаты).
CREATE TABLE trades ( time DateTime64(3), exchange LowCardinality(String), symbol LowCardinality(String), price Decimal(20, 8), volume Decimal(20, 8), side Enum8('buy' = 1, 'sell' = 2) ) ENGINE = MergeTree() PARTITION BY toYYYYMM(time) ORDER BY (symbol, exchange, time); ORDER BY в ClickHouse — это одновременно и первичный ключ (sparse index), и физический порядок хранения. Выбирайте по паттернам запросов: если чаще фильтруете по (symbol, time) — именно такой ORDER BY.
ClickHouse materialized views — триггерные, обновляются при insert (не по расписанию как в TimescaleDB). Уникальная функция — ASOF JOIN для джойна по ближайшему значению времени.
Типы данных. Используйте LowCardinality(String) для полей с малой кардинальностью (exchange, symbol, side) — экономия 2–10x по размеру и ускорение фильтрации. Decimal вместо Float для финансовых значений — нет проблем с точностью.
Партиционирование. По месяцам (toYYYYMM) — стандарт для большинства финансовых данных. Позволяет дропать старые партиции без DELETE.
| Параметр | TimescaleDB | ClickHouse |
|---|---|---|
| Тип полей | Стандартные PostgreSQL | LowCardinality, Decimal, Enum |
| Индексация | B-tree по символу+время | ORDER BY (sparse index) |
| Сжатие | 10–20x (compression policy) | 5–10x (LZ4, ZSTD) |
| Партиционирование | По дням (chunk_interval) | По месяцам (toYYYYMM) |
Почему важно комбинировать TimescaleDB и ClickHouse?
Хранение всех данных в одной СУБД — компромисс. TimescaleDB отлично держит точечные запросы и OLTP-загрузку, но проигрывает в аналитике при 100+ миллиардах строк. ClickHouse, наоборот, неэффективен для частых обновлений и транзакций. Комбинируя их, вы получаете: операционные данные на TimescaleDB (горячий слой 30 дней) и аналитический слой на ClickHouse (история за всё время). Затраты на инфраструктуру снижаются на 40% за счёт разнесения нагрузки. Получите консультацию по выбору СУБД для ваших данных.
Что входит в нашу работу
- Аудит текущих данных и типовых запросов
- Проектирование схемы (hypertable / MergeTree) с выбором партиционирования, индексов и компрессии
- Скрипты миграции с контролем целостности
- Настройка continuous aggregates или materialized views
- Интеграция с Grafana: дашборды по размеру таблиц, количеству частей, времени выполнения запросов
- Документация по эксплуатации и рекомендации по дальнейшему масштабированию
- Обучение команды заказчика
Процесс работы
- Аналитика — собираем метрики нагрузки, объёмов, частоты запросов. Определяем горячие и холодные данные.
- Проектирование — выбираем СУБД, схему и политики ретенции/компрессии.
- Реализация — разворачиваем кластер, пишем ETL-пайплайн.
- Тестирование — нагрузочное тестирование на объёмах, близких к реальным.
- Деплой — миграция данных, подключение мониторинга, передача документации.
Сроки и стоимость
Сроки: от 1 недели на проектирование схемы до 3 недель при миграции существующих данных. Стоимость рассчитывается индивидуально под ваш объём и сложность. Свяжитесь с нами — обсудим детали.