TimescaleDB¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: TimescaleDB 2.20.x на PostgreSQL 17; self-hosted, функции зависят от edition. Проверка источников: 2026-11-02.

1. Архитектура и модель данных¶

FACT. PostgreSQL extension организует time-series в hypertables/chunks и добавляет continuous aggregates/columnstore facilities. Это наследование PostgreSQL transaction model в поддерживаемой комбинации версий, а не новая generic distributed database.

flowchart LR
  Insert --> Hypertable
  Hypertable --> Chunks[Time chunks]
  Chunks --> WAL[PostgreSQL WAL]
  Chunks --> Refresh[Aggregate refresh job]
  Refresh --> Aggregate[Continuous aggregate]

2. Физическое хранение и путь записи¶

Hypertable маршрутизирует строки по time dimension в chunks; rowstore сохраняет PG tuples/WAL. Columnstore/compression перестраивает представление старых chunks по собственным settings и edition. В 2.20 используются новые APIs/названия; старые примеры compression нельзя смешивать с текущими cloud-only defaults.

Источники механизма: документация 1, документация 4.

3. Индексы и путь чтения¶

Индексы существуют на chunks и подчиняются PostgreSQL access methods. Time range обеспечивает chunk exclusion; без time predicate можно обойти много chunks. Segment/order configuration для columnstore определяет pruning/compression. Unique index на hypertable должен включать все partitioning columns.

Источники механизма: документация 1.

4. Транзакции и consistency guarantees¶

Локальные транзакции и isolation основаны на PostgreSQL; DML/continuous refresh и background jobs — разные transaction boundaries. Continuous aggregate не становится немедленно полной копией raw data: refresh window, watermark и real-time aggregation setting определяют видимость. Default real-time mode зависит от версии — задавать явно.

Источники механизма: документация 2.

5. Репликация, partitioning и sharding¶

Обычный self-hosted instance использует PostgreSQL replication; chunks не являются удалёнными shards автоматически. Историческую возможность distributed hypertables нельзя выдавать за гарантированную функцию выбранного 2.20 baseline. Managed services и deprecated multi-node функции рассматриваются отдельно.

Источники механизма: документация 4.

6. Конкурентная запись и конфликты¶

Concurrent inserts в активные chunks используют PG locks/MVCC. Late data и исправления попадают в старые ranges и требуют refresh aggregate; columnstore updates могут потребовать дополнительной работы/совместимости API. Idempotency uniqueness должна включать time partition key или обеспечиваться отдельным реестром.

Источники механизма: документация 1, документация 2.

7. Отказы и восстановление¶

Base backup/WAL restore охватывает PostgreSQL, extension metadata и jobs в совместимой версии. После restore проверить chunk catalog, aggregate refresh status и job scheduling. Удалённый retention chunk нельзя восстановить из replica, повторившей drop; нужен backup/raw archive.

Источники механизма: документация 4.

8. Масштабирование и ограничения¶

Chunk interval выбирают по active indexes, ingest rate, query range и lifecycle. Слишком мелкие chunks повышают planning/catalog costs, слишком крупные увеличивают maintenance и активный working set. Hot tenant/time может потребовать дополнительного model design, а не произвольного числа dimensions.

9. Performance trade-offs¶

Continuous aggregates уменьшают повторный scan ценой refresh/invalidations. Retention raw и aggregate window должны быть согласованы: refresh удалённого raw диапазона может убрать ранее рассчитанные агрегаты. Columnstore экономит bytes, но добавляет rewrite/late-update cost.

10. Мониторинг и эксплуатация¶

PG metrics плюс timescaledb_information.hypertables/chunks/jobs/job_stats и continuous aggregate views. Следить за failed jobs, refresh lag, old chunks, размером active indexes и WAL. Lifecycle порядок compression/retention/refresh проверять на копии с late data.

11. Сценарии FinTech и iGaming¶

INFERENCE. Time-series платежной telemetry, odds measurements и operational counters с SQL joins. Authoritative ledger может сосуществовать в PG, но time-series retention не должна удалять audit. High-cardinality player dimensions оценивать по index/aggregate costs.

12. Когда не выбирать¶

Не выбирать как автоматический global sharding слой. Не использовать continuous aggregates без явного lateness/refresh contract. Если нужен только разовый локальный Parquet analysis, отдельная always-on база может быть излишней.

13. Вопросы на собеседовании¶

Почему unique event_id недостаточен на hypertable? Уникальность должна учитывать все partitioning columns; global dedup требует отдельного решения.

Почему aggregate не исправился после late insert? Диапазон мог не попасть в refresh policy.

Retention raw безопасен для aggregates? Только при согласованной refresh/retention политике и проверенной семантике.

14. Практические SQL/config примеры¶

CREATE TABLE telemetry (
  ts timestamptz NOT NULL, tenant_id bigint NOT NULL,
  event_id uuid NOT NULL, value double precision NOT NULL,
  PRIMARY KEY (ts, tenant_id, event_id)
);
SELECT create_hypertable('telemetry', by_range('ts'));

Extension устанавливается отдельно. PG syntax parsed; наличие/сигнатура TimescaleDB функций runtime не проверены. Выбран совместимый API создания hypertable, без cloud-only DDL.

15. Дополнительные источники¶

Типичные ошибки проектирования¶

Смешивать commit, видимость projection и backup; приписывать формату функции query engine; игнорировать версии и cleanup horizon. Product-specific ошибки и безопасные альтернативы разобраны в разделах 4–9.

Практические упражнения¶

Составьте журнал одной записи: какие файлы/metadata появляются до публикации, что увидит reader при сбое и какой cleanup безопасен. Затем предложите restore drill с проверкой итоговой полноты, включая поздние исправления.