Сиры дані з блокчейну або бірж накопичуються швидко — десятки гігабайт на день для активно парсимих джерел. Типовий проєкт: парсинг 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 тижнів при міграції існуючих даних. Вартість розраховується індивідуально під ваш обсяг і складність. Зв'яжіться з нами — обговоримо деталі.