Хранение временных рядов: сравниваем и выбираем

Если сервис пишет метрики раз в секунду, за сутки набегает 86 400 значений на один ряд. Но одной этой цифры недостаточно, чтобы выбрать базу: важнее, сколько рядов у вас одновременно, как часто данные читают и нужно ли хранить исходную детализацию месяцами. Ниже сравниваем три варианта на версиях PostgreSQL 16, TimescaleDB 2.17 и ClickHouse 24.8 — это ориентир по возможностям, а не рекомендация ставить именно эти релизы.

Сначала опишите не объём, а запросы

Временной ряд — это значение, привязанное ко времени: температура датчика, задержка запроса, цена акции или число заказов в минуту. Одна система может хранить такие данные как обычные строки, другая — как специализированные колонки и блоки. На выбор влияют три вопроса: как данные поступают, как их читают и когда удаляют.

• Запись: значения приходят по одному, пачками или большими импортами? Нужны ли обновления уже записанных точек?
• Чтение: вы открываете последние значения одного объекта, строите графики по тысячам рядов или считаете агрегаты за год?
• Жизненный цикл: сколько хранить исходные данные, когда объединять их в более крупные интервалы и как удалять устаревшее?

Запишите несколько настоящих запросов из приложения и объём данных за типичный день. Не заменяйте их тестом «записать миллион строк»: он проверяет только часть задачи, а выбор базы определяют ещё чтение, агрегация и удаление.

Кардинальность — число уникальных комбинаций измерений у метрики, например «имя сервиса × регион × код ответа». Если метки содержат уникальный идентификатор запроса, комбинаций может стать почти столько же, сколько самих событий.

Три варианта и их цена

PostgreSQL 16: временные данные как часть приложения

Обычный PostgreSQL подходит, когда рядов умеренно много, объём понятен, а временные данные живут рядом с заказами, пользователями и настройками. Вы получаете транзакции, SQL, индексы и единое резервное копирование. Если таблица растёт, разделение на партиции по времени помогает организовать данные и удалять старые интервалы крупными частями.

Цена — вы сами проектируете схему, партиционирование, индексы, очистку и агрегаты. Индекс на каждой комбинации полей увеличит стоимость записи и место на диске. А запрос, который сканирует много истории и группирует значения по времени, может конкурировать за ресурсы с основными запросами приложения.

TimescaleDB 2.17: PostgreSQL с инструментами для рядов

TimescaleDB — расширение PostgreSQL. Оно сохраняет знакомую модель SQL и добавляет специализированную организацию временных данных, а также инструменты для задач вроде хранения и сжатия истории. Это компромисс для команды, которая хочет остаться в экосистеме Postgres, но не желает собирать весь конвейер для рядов вручную.

Цена — дополнительная зависимость и ещё один слой, который нужно обновлять и поддерживать. Проверьте совместимость выбранной версии расширения с версией PostgreSQL и облачной платформой: доступность расширений и поддерживаемые сочетания версий различаются. Не переносите рабочую базу только потому, что в описании продукта есть нужная функция: сначала прогоните типовые запросы на тестовом наборе.

ClickHouse 24.8: аналитика по большим объёмам

ClickHouse рассчитан на аналитические запросы по большим наборам данных. Колончатое хранение и обработка блоками хорошо подходят, когда нужно агрегировать историю сразу по множеству временных интервалов и измерений. Его часто выбирают как отдельное хранилище для событий и метрик, оставляя транзакционные данные в основной базе.

Цена — отдельная инфраструктура и другая модель эксплуатации. ClickHouse не стоит автоматически считать заменой PostgreSQL для операций приложения: заранее проверьте нужные гарантии записи, обновлений, удаления и восстановления. Для графика последних значений одного устройства специализированная аналитическая база может оказаться избыточной.

Выбирайте хранилище под запрос, который съедает больше всего ресурсов, а не под абстрактное число точек. Миллион редко читаемых значений и миллион метрик с высокой кардинальностью — разные задачи.

Как выбрать по рабочей нагрузке

Начните с наиболее простого варианта, который закрывает ваши реальные запросы, и усложняйте архитектуру только при измеряемой необходимости.

1. Оставьте данные в PostgreSQL, если приложению нужны транзакции и точечные чтения, а отчёты укладываются в приемлемое время. Проверьте, что запросы ограничены по времени и используют нужные индексы. Если чтение истории начинает мешать основной нагрузке, это сигнал пересмотреть схему или вынести аналитику.
2. Испытайте TimescaleDB, если хотите сохранить SQL и PostgreSQL, но ручное обслуживание временных таблиц стало обременительным. Сравните на одинаковой схеме запись, запросы и удаление старых данных. Результат проверяйте на той версии расширения и платформе, которые планируете запускать.
3. Выберите ClickHouse, если пользователи в основном строят сводные графики и отчёты по большой истории, а приложение может отправлять туда события отдельно от транзакционной базы. Сначала определите, как выдерживать задержку между записью события и его появлением в отчёте, а также как исправлять ошибочные данные.

Сравнивайте не только скорость. Зафиксируйте размер набора данных, распределение меток, долю чтения и записи, параллельность, нужный срок хранения и оборудование. Измерьте задержку записи, время нескольких типичных запросов, размер данных на диске и поведение при удалении старого интервала. Универсальных чисел «точек в секунду» здесь нет: результат зависит от схемы и нагрузки.

Что ломается на практике

Метки превращаются в уникальные идентификаторы

Идентификатор запроса, случайный токен или полный URL в метке создаёт новую комбинацию для каждого события. Растут индекс и накладные расходы на хранение, а запросы по метрикам становятся тяжелее. Оставляйте в измерениях ограниченный набор признаков, а уникальные значения храните отдельно, если они нужны для расследования.

Хранится всё, но никто не знает зачем

Исходные секунды удобны для диагностики, но не всегда нужны на всём горизонте. Определите срок хранения исходных данных и правила перехода к более крупным интервалам. Проверьте результат агрегации: среднее не заменяет максимум, если важно ловить короткие пики.

Дашборд незаметно сканирует всю историю

График может запрашивать слишком много точек и пересчитывать агрегаты при каждом открытии. Ограничьте временной диапазон, число отображаемых значений и частоту обновления. Если проблема повторяется, измеряйте именно запросы с дашборда, а не только скорость массовой загрузки.

План удаления не проверен

Удаление больших объёмов строк по одной может занять время и создать дополнительную нагрузку. Партиционирование или политики хранения помогают, но требуют правильной настройки и проверки. На тестовой копии убедитесь, что старые данные действительно исчезают, резервная копия восстанавливается, а очистка не блокирует важные запросы.

Что делать дальше

Соберите несколько дней реальных данных или репрезентативный тестовый набор, запишите пять самых частых запросов и проверьте на нём два наиболее подходящих варианта. Для PostgreSQL изучите раздел документации о декларативном партиционировании, для TimescaleDB — документацию по hypertables и политике хранения. До запуска в проде отдельно проверьте резервное копирование, восстановление, очистку и поведение при росте кардинальности.

Сравнение опирается на возможности конкретных версий PostgreSQL 16, TimescaleDB 2.17 и ClickHouse 24.8; это не утверждение, что они актуальны для любого нового развёртывания. Перед выбором сверьте текущие релизы и матрицу совместимости в документации.