Primary source
Prometheus TSDB
Базовые принципы хранения метрик: локальные блоки, retention, compaction и remote write.
Time Series Databases (TSDB) удобно выбирать по четырем осям: модель данных, storage engine, ключевой сценарий и операционная модель. Эта глава дополняет Database Selection Framework и помогает быстро понять, когда нужен специализированный TSDB-движок, а когда разумнее взять SQL/columnar базу и использовать ее как time-series платформу.
Карта выбора TSDB: 4 оси
1. Модель данных и язык запросов
Нативная TSDB, SQL-расширение поверх RDBMS, слой над distributed store или columnar OLAP как TSDB.
От этой оси зависит, насколько легко писать ad-hoc аналитику, делать join и подключать BI.
2. Способ хранения
Append-only/LSM, партиционирование по времени, row vs column layout, встроенное сжатие и downsampling.
Это определяет write throughput, стоимость хранения и скорость агрегатов по большим time-window.
3. Ключевой сценарий
Мониторинг, IoT телеметрия, финансовые таймсерии, логи/метрики для продуктовой аналитики.
Разные сценарии требуют разного баланса между latency, retention, cardinality и гибкостью запросов.
4. Операционная модель
Self-hosted, managed cloud, гибрид с разными storage tiers.
Влияет на TCO, требования к SRE-команде и скорость эволюции платформы наблюдаемости/аналитики.
Основные семейства TSDB
1. Специализированные TSDB «с нуля»
Системы, изначально спроектированные под временные ряды и высокий поток записи.
Характерные свойства
- Append-only write path и оптимизация под ingest-throughput.
- Сжатие по времени/значениям, retention/TTL и downsampling из коробки.
- Time-bucket агрегаты и оконные функции как базовый сценарий.
Типичные представители
InfluxDB, Prometheus, VictoriaMetrics, M3, Thanos, Graphite/Whisper
Когда использовать
- Инфраструктурный мониторинг и application metrics.
- IoT-телеметрия с относительно простой схемой меток.
- Сценарии, где write path и retention важнее сложных join.
Trade-offs
- Сложная реляционная аналитика обычно ограничена.
- Рост high-cardinality меток может резко увеличить стоимость хранения.
2. TSDB как расширение реляционной БД
Подход, где time-series возможности добавляются к SQL-движку (например, PostgreSQL).
Характерные свойства
- SQL как основной язык запросов и интеграция с существующими BI-инструментами.
- Партиционирование по времени, hypertables/continuous aggregates и space-sharding.
- Join с OLTP-таблицами и единая data model для метрик и доменных сущностей.
Типичные представители
TimescaleDB, PipelineDB-подобные паттерны, kdb+
Когда использовать
- Нужны сложные SQL-запросы и регулярные join с транзакционными данными.
- Команда уже сильна в PostgreSQL-экосистеме.
- Важно снизить число разных технологий в стеке.
Trade-offs
- Максимальный ingest часто ниже, чем у узкоспециализированных TSDB.
- При экстремальном масштабе сложность тюнинга быстро растет.
3. TSDB поверх распределенных storage-систем
Time-series слой поверх HBase/Cassandra/Bigtable-подобных хранилищ для экстремального масштаба.
Характерные свойства
- Горизонтальное масштабирование до очень больших объемов и длительного retention.
- Отказоустойчивость и replication задаются нижележащим KV/column-store слоем.
- Архитектура чаще всего многокомпонентная и требует явного capacity planning.
Типичные представители
OpenTSDB (HBase), KairosDB/Cassandra-паттерны, самодельные TSDB-схемы
Когда использовать
- Телеком/облака/SaaS с триллионами точек и длительным хранением.
- Нужна линейная scale-out модель по мере роста кластера.
- Команда готова к операционной сложности распределенного стека.
Trade-offs
- Высокая сложность администрирования и тюнинга.
- Медленный путь от идеи до production из-за числа движущихся частей.
4. Колоночные аналитические БД, используемые как TSDB
General-purpose columnar системы, которые на практике часто становятся metrics/log/time-series хранилищем.
Характерные свойства
- Сильное колоночное сжатие и быстрые агрегаты по длинным временным окнам.
- Гибкие ad-hoc запросы и BI-friendly SQL для аналитики поверх событий.
- Хороший компромисс между ingest и сложностью аналитических запросов.
Типичные представители
ClickHouse, Apache Druid, Apache Pinot, MPP DWH (Vertica и др.)
Когда использовать
- Логи + метрики + BI в едином аналитическом контуре.
- Нужны сложные срезы, cohort/retention анализ и продуктовые отчеты.
- Важно поддерживать гибкую ad-hoc аналитику для data/product команд.
Trade-offs
- Это не всегда полноценная замена мониторинговой TSDB для алертинга.
- Для low-latency operational мониторинга часто нужен отдельный слой.
Быстрый сценарный выбор
Инфраструктурный мониторинг
Нативная TSDB (Prometheus/VictoriaMetrics) + long-term слой
Сильная экосистема для алертинга, SLO и dashboard-driven эксплуатации.
IoT-телеметрия и события устройств
Нативная TSDB или SQL-расширение (TimescaleDB) по уровню аналитики
Ключевые факторы: ingest-rate, cardinality тегов и политика retention/downsampling.
Финансовые/квантовые таймсерии
SQL/columnar подход (kdb+, ClickHouse, TimescaleDB)
Нужны точные агрегаты, window functions и сложные аналитические запросы.
Логи/метрики + BI и ad-hoc аналитика
Columnar analytics (ClickHouse/Druid/Pinot)
Обычно выигрывает по гибкости SQL и скорости больших аналитических сканов.
Self-hosted vs Cloud managed
Self-hosted
- Максимальный контроль над storage layout, индексами и upgrade-политикой.
- Подходит, если есть зрелая SRE/DBA практика и требования к кастомной эксплуатации.
- TCO зависит от компетенций команды и качества автоматизации.
Managed cloud
- Быстрый старт, меньше операционной нагрузки и predictable SLA от провайдера.
- Хорошо для команд, где скорость поставки важнее глубокой платформенной кастомизации.
- Нужно заранее считать egress, retention-tier и lock-in риски.
Рекомендации для первого выбора
Начинай выбор с workload-профиля: ingest/sec, cardinality, retention, query patterns.
Отделяй operational monitoring (алерты в реальном времени) от product analytics (сложные срезы).
Фиксируй SLO на запись/чтение и проверяй их на реалистичных данных, а не на synthetic benchmark.
Если нужен гибкий SQL и join с бизнес-данными, сначала проверь TSDB-путь через PostgreSQL/columnar SQL.
Планируй downsampling и tiered storage заранее: это главный рычаг снижения стоимости TSDB.
Частые ошибки при выборе TSDB
Пытаться закрыть одним движком и мониторинг, и глубокую BI-аналитику без явной декомпозиции контуров.
Выбирать TSDB только по максимальному ingest throughput, игнорируя стоимость запросов и хранения.
Игнорировать high-cardinality риск в метках (labels/tags) до момента production-инцидентов.
Откладывать стратегию retention/downsampling до тех пор, пока кластер не упрется в бюджет.
Оценивать решения без учета операционной модели (self-hosted vs managed cloud).