Кейс TSKLab: выбор СУБД под высоконагруженный сервис телеметрии

Когда мы в TSKLab проектировали сервис телеметрии, вопрос не стоял «какая база данных самая быстрая». Гораздо важнее было понять, какая СУБД выдержит наш конкретный профиль: непрерывный поток событий с переменной интенсивностью, жёсткие требования к хранению и аналитике, и при этом не потребует армии администраторов. В этой статье — честный разбор нашего пути и критериев, которые оказались решающими.

Почему выбор СУБД для телеметрии нельзя делать «по привычке»

Телеметрия выглядит просто только на схеме. В реальности это поток событий с разной частотой, высоким числом тегов, всплесками записи, строгими требованиями к срокам хранения и постоянными запросами вида «дай последние 15 минут», «сравни с прошлым часом», «найди аномалию по группе устройств». Если выбрать СУБД без учёта этих сценариев, система быстро упрётся в I/O, индексный шум, дорогие агрегации или слишком сложную эксплуатацию.

На первых прототипах мы использовали обычный PostgreSQL, и пока поток был ровным, всё работало. Но как только появились всплески и запросы вида «покажи аномалии за последние 5 минут по 10 тысячам устройств», стало ясно, что без time-series оптимизаций не обойтись. Задача для TSKLab формулировалась так:

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

Какие варианты рассматривали

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

С точки зрения именно телеметрии наиболее практичной развилкой обычно становятся PostgreSQL/TimescaleDB против ClickHouse. PostgreSQL в чистом виде хорош как стартовая база, а ClickHouse силён там, где основная ценность — быстрая аналитика по большим объёмам событий. TimescaleDB занимает промежуточную, но очень удобную позицию: это не отдельная база, а расширение PostgreSQL, которое добавляет механики для временных рядов — hypertable, автоматическое партиционирование по времени, компрессию и материализованные агрегаты. Для нас это означало возможность не уходить с проверенного стека, но получить производительность, близкую к специализированным time-series решениям.

Что оказалось важнее всего в сервисе телеметрии

Мы оценивали не абстрактную «производительность», а практические критерии, которые напрямую влияли на стабильность сервиса и скорость разработки.

1. Скорость записи под пиковую нагрузку

Телеметрия часто приходит неравномерно: днём — обычный поток, ночью — пакетные выгрузки, при инцидентах — лавина событий. База должна принимать такие всплески без деградации всей системы. В нашем сервисе пиковая нагрузка могла вырастать в 5–10 раз за минуту — например, при массовом переподключении устройств после сбоя сети. Мы тестировали TimescaleDB на таких всплесках: при правильно настроенных чанках и асинхронной записи деградация была минимальной, а задержка на уровне p99 оставалась в пределах десятков миллисекунд. Чистый PostgreSQL на тех же объёмах начинал страдать от autovacuum и блокировок, что сразу отражалось на хвостовых задержках.

2. Стоимость хранения

История телеметрии растёт быстро. Если база не умеет эффективно сжимать старые данные или выносить их в удобные сегменты, хранение становится дорогим и неудобным. В TimescaleDB мы включили компрессию на чанках старше двух дней и получили сжатие в 10–15 раз на типовых числовых метриках. Это позволило держать сырые данные за несколько месяцев без раздувания дискового пространства и без необходимости сразу выносить их в холодное хранилище.

3. Удобство запросов

Инженерам нужны не только сырые события, но и отчёты, интервальные агрегаты, выборки по устройствам, тегам, версиям прошивок, типам ошибок. Если для каждого запроса нужно писать сложный обходной SQL или отдельный пайплайн — это плохой сигнал. Мы активно использовали continuous aggregates для дашбордов: материализованные представления, которые автоматически обновлялись по расписанию, сократили время ответа с десятков секунд до единиц миллисекунд. При этом запросы оставались привычным SQL, без необходимости изучать новый диалект.

4. Управляемый ретеншен

Телеметрия редко хранится «всё и навсегда». Обычно разные уровни данных живут разное время: сырьё — дни или недели, агрегаты — месяцы, а часть метрик — почти постоянно. Мы настроили политики автоматического удаления старых чанков и сжатия прямо в базе, без внешних скриптов. Это работало предсказуемо и не требовало ручного вмешательства даже при изменении номенклатуры метрик.

5. Простота эксплуатации

Если база требует слишком много ручной настройки, вся экономия на лицензии и «бесплатности» быстро уходит в операционные расходы. TimescaleDB управляется как обычный PostgreSQL — те же инструменты резервного копирования, мониторинга, те же метрики. Команда, уже знакомая с PostgreSQL, смогла начать работу без длительного обучения, а все time-specific настройки свелись к выбору интервала чанков и политик сжатия.

Почему TSKLab остановился на гибридном подходе

Для высоконагруженного сервиса телеметрии один инструмент редко закрывает всё одинаково хорошо. Поэтому в TSKLab рассматривали архитектуру, где:

• операционный слой держит актуальные данные и недавнюю историю;
• аналитический слой обслуживает тяжёлые отчёты и длительные срезы;
• между ними есть понятное правило передачи и агрегации данных.

На раннем этапе самым практичным решением оказался PostgreSQL + TimescaleDB как единая рабочая база для приёма телеметрии и быстрых интервальных запросов. Это дало возможность не ломать привычный SQL-подход, а использовать time-series механики: hypertables, автоматическое разбиение по времени, компрессию и continuous aggregates. Важный нюанс: TimescaleDB по умолчанию отправляет анонимную телеметрию о своём использовании (можно отключить параметром timescaledb.telemetry_level). К нашей прикладной телеметрии это отношения не имеет, но при развёртывании в закрытом контуре мы этот параметр сразу выключали — из соображений безопасности и контроля. Такой подход позволил не усложнять архитектуру сразу, а оставить ClickHouse как очевидного кандидата на будущее для тяжелой аналитики.

Почему не только PostgreSQL

Обычный PostgreSQL — сильный универсал, но у телеметрии есть своя физика данных. Когда в таблице появляются миллионы строк в день, стандартных индексов и партиций уже недостаточно для комфортной работы без строгой дисциплины в схеме и запросах. Мы на практике убедились: на чистом PostgreSQL таблица с 500 млн строк и агрегатами за месяц превращалась в узкое место — запросы уходили в десятки секунд, а индексы распухали до размеров самих данных. Ручное партиционирование помогало, но требовало постоянного внимания и переписывания запросов под секции.

Где PostgreSQL начинает проигрывать

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

Когда PostgreSQL всё ещё разумный выбор

• если нагрузка пока умеренная;
• если нужен один универсальный стек;
• если команда не хочет добавлять отдельную аналитическую платформу;
• если проект должен быстро стартовать без сложной миграции.

То есть PostgreSQL — хороший базовый фундамент, но для телеметрии в чистом виде он часто требует дополнительных механизмов. TimescaleDB здесь закрывает важный пробел, оставаясь в экосистеме PostgreSQL.

Что даёт TimescaleDB в реальном проекте

TimescaleDB оказался наиболее удобным для сценария TSKLab по трём причинам, которые мы проверили на практике.

1. Hypertable вместо монолитной таблицы

Данные автоматически раскладываются по временным чанкам. Это упрощает запись, ускоряет выборки по диапазонам времени и уменьшает боль от больших таблиц. Мы настроили размер чанка в один день для активной таблицы — это позволило эффективно использовать кэш, быстро удалять старые данные и избегать ситуаций, когда один индекс блокирует всю таблицу.

2. Continuous aggregates

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

3. Компрессия старых данных

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

Практический вывод

Если телеметрия — это не просто «события, которые надо сложить в таблицу», а рабочий контур с дашбордами, окнами, сравнениями и ретеншеном, TimescaleDB часто даёт лучший баланс между SQL-удобством и time-series-производительностью. Мы получили предсказуемую производительность и не потеряли гибкость запросов.

Где сильнее ClickHouse

ClickHouse особенно хорош там, где телеметрия уже переросла роль просто operational storage и стала источником тяжёлой аналитики. Его сила — в быстрых сканах больших объёмов, columnar-архитектуре и высокой эффективности на агрегатных запросах. Многие используют ClickHouse как time-series базу для observability, product analytics, финансовых тиковых данных и IoT-телеметрии. Мы тестировали ClickHouse на исторических данных за полгода: агрегаты по минутам для 100 млн записей выполнялись в разы быстрее, чем в TimescaleDB. Но для оперативной вставки и точечных запросов по последним значениям он требовал более аккуратной схемы и не давал такого же удобства, как SQL с индексами.

ClickHouse стоит выбирать, если:

• основной сценарий — аналитика по большим массивам;
• запросы почти всегда агрегатные;
• объёмы уже слишком велики для удобной работы в одной PostgreSQL-системе;
• есть готовность выстроить отдельный слой загрузки и модели данных.

Ограничения ClickHouse:

• это не замена классической OLTP-базе;
• сложнее поддерживать привычные транзакционные сценарии;
• нужно аккуратнее проектировать схему под аналитические запросы.

Для TSKLab это означало следующее: ClickHouse полезен как второй этап или отдельный аналитический контур, но как единственная база для всего жизненного цикла телеметрии он не был самым удобным стартом.

Как выглядела логика выбора в TSKLab

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

Шаг 1. Определили тип нагрузки

Телеметрия поступает непрерывно, но не всегда одинаково. Основной объём — запись и быстрый просмотр свежих данных, а не тяжёлая ad hoc-аналитика. Мы замерили соотношение: около 80% операций — вставки и короткие чтения по времени, и только 20% — аналитические запросы с агрегацией.

Шаг 2. Проверили запросы

Большая часть запросов сводилась к:

• последним значениям;
• агрегатам по минутам и часам;
• группировке по устройствам, сервисам и типам событий;
• сравнении периодов.

Этот паттерн хорошо ложился на time-series оптимизации, а не на колоночную аналитику.

Шаг 3. Оценили порог роста

Стало ясно, что в будущем объёмы вырастут до уровня, где старые сырые данные нужно будет отдельно агрегировать и хранить в сжатом виде. Мы экстраполировали рост до 1 млрд записей в год и поняли, что без автоматического партиционирования и компрессии эксплуатация станет слишком дорогой.

Шаг 4. Посмотрели на команду

Команде нужен был стек, который:

• легко внедряется;
• быстро объясняется новым инженерам;
• не требует смены парадигмы;
• даёт понятный SQL и прогнозируемое сопровождение.

Знакомство с PostgreSQL было у всех, а TimescaleDB не требовал переучивания.

Шаг 5. Сделали выбор

По сумме факторов победил PostgreSQL-совместимый путь с TimescaleDB, а ClickHouse был оставлен как очевидный кандидат на последующее расширение аналитического контура. Мы провели двухнедельный пилот с реальной нагрузкой, который подтвердил правильность решения: задержки были стабильны, запросы просты, а эксплуатация не отличалась от привычного PostgreSQL.

Типовая ошибка: выбирать СУБД только по цифрам бенчмарка

Это одна из самых дорогих ошибок. Быстрый синтетический тест не показывает:

• как база ведёт себя через 6 месяцев;
• сколько стоят миграции схемы;
• насколько сложно писать и читать запросы;
• как быстро команда начнёт делать обходные решения;
• насколько удобно мониторить и обслуживать систему.

Мы сами чуть не попали в эту ловушку, когда увидели впечатляющие цифры ClickHouse на потоковую вставку. Но наши реальные запросы на 90% состояли из точечных чтений и небольших интервалов, где важнее latency, а не throughput. Для телеметрии важнее не абсолютная «скорость в вакууме», а стабильность под вашим реальным профилем нагрузки.

Практический чек-лист выбора СУБД под телеметрию

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

• Определить объём записи в секунду и в сутки.
• Зафиксировать типы запросов: свежие данные, агрегации, отчёты, поиск аномалий.
• Понять срок жизни сырых данных и агрегатов.
• Проверить, нужна ли транзакционность на уровне отдельных событий.
• Оценить, кто будет сопровождать систему: одна команда или несколько.
• Решить, нужна ли одна база или допустим гибрид.
• Проверить, как быстро будет расти схема и количество измерений.
• Заранее определить метрики успеха: latency записи, время отчёта, стоимость хранения, время восстановления.

Как не ошибиться с архитектурой хранения

Рекомендация 1. Не храните всё в одной «широкой» таблице без причин

Для телеметрии лучше моделировать данные компактно и однотипно. Чем проще строка, тем легче ей жить в больших объёмах. В одной из первых версий мы хранили все метрики в одной таблице с JSON-полем для тегов. Это быстро привело к тому, что запросы по тегам требовали сканирования всей таблицы. Переход на плоскую схему с отдельными колонками для ключевых тегов и TimescaleDB решил проблему.

Рекомендация 2. Разделяйте сырые данные и агрегаты

Сырые события нужны не всегда. Часто выгоднее хранить их ограниченное время, а для долгого периода держать промежуточные агрегаты. Мы настроили политику: сырые данные — 7 дней, поминутные агрегаты — 90 дней, часовые — год. Это дало баланс между детализацией и стоимостью хранения.

Рекомендация 3. Сразу думайте о ретеншене

Если вопрос «что удалять и когда» возникает после запуска, значит архитектура уже недописана. Мы закладывали политики хранения на этапе проектирования схемы, и это избавило от авралов при росте данных.

Рекомендация 4. Не игнорируйте мониторинг

Для телеметрии особенно важны:

• скорость вставки;
• размер чанков/партиций;
• рост индексов;
• время выполнения ключевых запросов;
• доля компрессированных данных.

Мы добавили эти метрики в общий мониторинг и настроили алерты на отклонения — это позволило ловить деградацию до того, как она становилась заметна пользователям.

Итоговый выбор TSKLab

Если коротко, логика была такой:

Для высоконагруженного сервиса телеметрии TSKLab выбрал путь, в котором TimescaleDB закрыл основной production-сценарий, а ClickHouse остался логичным кандидатом для дальнейшего усиления аналитики. Такой подход снизил риск преждевременного усложнения архитектуры и сохранил запас для роста. Решение принималось не на основе теоретических сравнений, а после двухнедельного пилота с реальной нагрузкой, который подтвердил стабильность и удобство.

Вывод

Под телеметрию не существует универсальной «лучшей СУБД». Есть СУБД, которые лучше подходят под конкретный профиль нагрузки, команду и этап развития продукта. Для TSKLab наиболее практичным оказался PostgreSQL-совместимый time-series путь через TimescaleDB: он дал быстрый старт, понятный SQL, удобную работу с временными рядами и нормальную траекторию масштабирования. А для тяжёлой аналитики и больших исторических срезов на горизонте остаётся ClickHouse.

FAQ

Что выбрать для телеметрии: PostgreSQL или ClickHouse?

Если нужен универсальный operational-слой и привычный SQL, лучше начать с PostgreSQL или TimescaleDB. Если основная задача — тяжёлая аналитика по большим объёмам, сильнее будет ClickHouse. Мы рекомендуем стартовать с PostgreSQL+TimescaleDB, а ClickHouse подключать, когда агрегации по месяцам станут узким местом.

Чем TimescaleDB отличается от обычного PostgreSQL?

TimescaleDB — это расширение PostgreSQL для временных рядов и событийных данных. Оно добавляет механики вроде hypertable, компрессии и continuous aggregates, сохраняя полную совместимость с экосистемой PostgreSQL. Для инженера это означает, что не нужно переучиваться, а можно сразу использовать time-series оптимизации.

Можно ли хранить телеметрию только в ClickHouse?

Можно, если у проекта аналитическая природа и нет жёсткой зависимости от OLTP-сценариев. Но для многих продуктовых систем это слишком резкий старт: потребуется отдельный слой загрузки, другая модель запросов и более высокая квалификация команды. Мы рассматривали такой вариант, но отложили его до момента, когда аналитическая нагрузка станет доминирующей.

Когда стоит разделять горячие и холодные данные?

Практически всегда, если объём телеметрии растёт каждый день. Сырые данные редко нужны одинаково долго, как агрегаты. Мы ввели разделение сразу: горячие данные (последние дни) на быстром хранилище, холодные — сжатые и на более дешёвых дисках. Это дало экономию без потери доступности.

Нужна ли отдельная аналитическая база сразу?

Не всегда. Для старта часто достаточно одной продуманной time-series базы, а отдельный аналитический контур добавляют, когда этого требует рост объёмов и числа отчётов. В нашем случае ClickHouse остался в планах на будущее, а текущие задачи полностью закрыл TimescaleDB.