В мире современных облачных платформ и сервисов аналитика играет ключевую роль в обеспечении качественного обслуживания клиентов и мониторинге работоспособности систем. Компания Cloudflare, являющаяся одним из лидеров в области интернет-безопасности и производительности, столкнулась с необходимостью масштабировать свои аналитические и отчётные решения. Этот вызов был успешно решён благодаря внедрению TimescaleDB — расширения для PostgreSQL, оптимизированного для обработки временных рядов данных. В этой статье будет подробно рассмотрен опыт Cloudflare по интеграции TimescaleDB, а также причины выбора этого решения вместо традиционных систем аналитики типа ClickHouse или базового PostgreSQL. Cloudflare изначально использовал PostgreSQL для транзакционных задач и ClickHouse для аналитических нагрузок.
PostgreSQL оставался основным инструментом для хранения конфигураций и управления продуктовыми данными, благодаря своей надёжности и проверенной архитектуре, насчитывающей более 30 лет развития. ClickHouse, добавленный в стек около 2017 года, обеспечивал высокую скорость обработки огромных объёмов данных (миллионы строк в секунду) с очень низкой задержкой при запросах. Однако, как и любые системы, ClickHouse требовал сложной инфраструктуры для эффективного использования, что не всегда соответствовало текущим требованиям продуктов. Ключевым моментом стало развитие продукта Digital Experience Monitoring (DEX) в Cloudflare, который предназначен для наблюдения за состоянием устройств, сетей и приложений внутри Zero Trust среды. Первоначально задача состояла в создании минимально жизнеспособного продукта (MVP) с упором на быстрый запуск и получение обратной связи от пользователей.
Для этого было решено минимизировать количество компонентов и использовать знакомые технологии, чтобы снизить стоимость поддержки и ускорить разработку. Вместо внедрения сложного конвейера на базе ClickHouse с несколькими вентиляторами и брокерами сообщений, Cloudflare выбрал PostgreSQL для хранения как конфигурационных данных, так и данных логов устройств. Логика состояла в том, что система не должна быть излишне сложной и изначально рассчитана на экстремальные нагрузки, которых можно было избежать при правильном планировании и ограничении по продуктовым лимитам (например, частота отправки логов, количественные ограничения по синтетическим тестам). При этом структура таблиц была оптимизирована под специфику временных рядов. Например, таблица для хранения состояния устройств не имела традиционного первичного ключа, поскольку запросы выполнялись преимущественно по временным диапазонам и фильтрации по идентификаторам устройств и аккаунтов.
Для устранения дубликатов при повторной отправке логов создавались уникальные индексы на комбинацию device_id, account_id и timestamp. Более того, грамотный порядок колонок в мультиколоночных индексах существенно улучшал производительность запросов, особенно учитывая, что временной столбец обычно используется с неравенствами, а остальные с равенствами. Масштабирование нагрузки вплоть до миллиардов записей привело к необходимости оптимизировать аналитические запросы. Одним из ключевых подходов стала предварительная агрегация данных, так называемое даунсемплирование. Вместо того чтобы постоянно запрашивать сырые данные, которые растут в объёме по экспоненте, агрегационные таблицы позволяли свести миллионы рядов к нескольким сотням значений за фиксированный интервал.
Это обеспечивало ускорение запросов почти в тысячи раз, делая визуализации в дашбордах максимально отзывчивыми. Осознавая ограничения PostgreSQL в части управления разделами таблиц и автоматизации агрегации, команда Cloudflare начала искать улучшения и наткнулась на TimescaleDB. Это расширение PostgreSQL объединяет в себе удобство реляционной базы и производительность специализированных систем для временных рядов. Одной из ключевых особенностей TimescaleDB является гипертаблица (hypertable), которая автоматически управляет партиционированием данных и позволяет создавать непрерывные агрегации, обновляющиеся в фоновом режиме и даже в реальном времени, что решало ранее возникавшую проблему с устаревшими материализованными представлениями. Кроме того, TimescaleDB предлагает встроенное сжатие данных, способное уменьшать размер таблиц более чем в 30 раз без ущерба для производительности запросов.
Это достигается за счёт перевода данных в колоночный формат и использования разрежённых индексов (sparse indexes), которые позволяют быстро отсеивать ненужные блоки при чтении. Уменьшение ввода-вывода за счёт сжатия позитивно сказывалось на общей скорости обработки. После внедрения TimescaleDB в тестовой среде Cloudflare провел масштабные сравнения с обычным PostgreSQL. Результаты показали прирост производительности от 5 до 35 раз в зависимости от типа задач и временных диапазонов. Особенно заметно ускорялись запросы на большие периоды (неделя и более), где сочетание сжатия и колоночного хранения раскрывало весь свой потенциал.
Оптимизации для поддержки высокой пропускной способности включали переход с массовых одиночных вставок на COPY, что значительно повышало скорость загрузки данных. Дополнительно в целях повышения производительности были отключены некоторые гарантии сохранности данных, такие как синхронная репликация и принудительная запись на диск (fsync), что было приемлемо при наличии возможности повторной обработки данных. Этот опыт внедрения TimescaleDB в Cloudflare оказался настолько успешным, что команда аналитики и отчётности Zero Trust (ART) начала использовать эту платформу в качестве слоя агрегации для объединения данных из разных источников, включая ClickHouse и PostgreSQL. Их система использовала регулярные задания, которые агрегировали и загружали сводные данные с последующей организацией непрерывных агрегаций и сжатием. Такой подход позволил масштабировать отчётность по миллионам строк в секунду, включая высококардинальные признаки, вроде IP-адресов.
Общий урок, который вынесла команда Cloudflare, связан с подходом к проектированию систем. Решение не форсировать масштаб и сложность вначале, а придерживаться простоты и минимализма, позволило быстро выйти на рынок с рабочим продуктом, избежать ненужных затрат и в итоге подобрать лучшие технологии по мере реальных потребностей. Использование TimescaleDB сочетает в себе проверенную надежность PostgreSQL и возможности современной аналитики, что делает его идеальным компромиссом между производительностью и простотой поддержки. Смелость отказаться от предварительной оптимизации и сосредоточиться на основных задачах привела к тому, что DEX и другие продукты Cloudflare достигли высоких KPI при меньших затратах ресурсов. TimescaleDB занял своё место в технологическом стеке как инструмент, который позволяет объединить данные конфигураций и аналитики в одной базе, избежать создания лишних компонентов и упростить операционное сопровождение.
В итоге, опыт Cloudflare наглядно демонстрирует преимущества подхода, где выбор базы данных осуществляется не только по параметрам производительности, но и с учётом удобства эксплуатации, стоимости и гибкости. TimescaleDB в этом контексте выступает как инструмент нового поколения для обработки временных рядов и аналитики, способный обеспечить масштабирование и быстродействие при сохранении всего арсенала возможностей стандартного PostgreSQL. Для команд, ищущих баланс между скоростью разработки, простотой архитектуры и мощной аналитикой в условиях интенсивного роста данных, опыт Cloudflare и использование TimescaleDB представляют ценный кейс и хорошее направление к развитию. Узнайте больше о TimescaleDB, посетив официальный сайт решения, и оцените, как оно может помочь в оптимизации ваших аналитических задач и построении эффективных отчётных систем.
