5 
Содержание
OpenReplay заменил Postgres на ClickHouse, чтобы обрабатывать миллиарды событий и до 6 ТБ данных в сутки на одной вертикально масштабируемой машине. Sub-second запросы и автоматическое удаление старых данных через TTL избавили команду от ручных скриптов и блокировок таблиц. Решение особенно ценно для self-hosted платформ, где операционная нагрузка должна оставаться минимальной. При выборе хранилища важно понимать, как именно меняется нагрузка на команду поддержки и на клиентов, которые сами разворачивают систему: снижается количество ручных операций, исчезает необходимость согласовывать очистку данных по выходным и упрощается планирование ресурсов.
Проблемы Postgres при росте событий
В 2019 году OpenReplay хранил все данные в Postgres на AWS. Метаданные сессий обрабатывались нормально, но таблицы поведенческих событий быстро стали узким местом. Запросы поиска сессий, которые комбинируют несколько типов событий с условиями, даже после индексов и шардинга возвращались за 3-10 секунд вместо целевой секунды.
Шардинг добавил операционной сложности без устойчивого результата. Очистка данных по ретеншену требовала скриптов, vacuum и перезапусков, которые блокировали таблицы. Поскольку платформа self-hosted, каждую очистку приходилось согласовывать с клиентами по выходным. Объём таблиц событий достигал 1 ТБ, а сжатие почти отсутствовало.
Эти ограничения делали Postgres непригодным для аналитики событий в реальном времени. Любое увеличение нагрузки грозило срывом всего ingestion-пайплайна. При оценке такого решения стоит учитывать, что вертикальный рост объёмов событий приводит не только к замедлению запросов, но и к росту рисков при выполнении регламентных работ: блокировка таблиц может затронуть работу всех пользователей платформы одновременно, а необходимость ручного вмешательства увеличивает вероятность ошибок и простоев.
Преимущества ClickHouse в ingestion и хранении
Переход на ClickHouse позволил хранить все события в одной таблице и сжимать их до 1-2 ГБ вместо терабайта. Запросы на сжатых данных выполняются быстро, а среднее время ответа на поиск сессий упало до секунды. Крупнейшие клиенты теперь загружают миллиарды событий и около 6 ТБ в сутки на одной машине без горизонтального масштабирования.
Главное отличие — TTL. Ретеншен задаётся один раз при установке и работает автоматически. Для одних клиентов это месяц, для других — год. Postgres-скрипты и weekend-координация с клиентами исчезли. Объектное хранилище обрабатывает файлы записей по тем же правилам, а Postgres оставили только под метаданные.
Такая модель снижает операционную нагрузку и для команды OpenReplay, и для конечных пользователей, которые разворачивают платформу у себя. При принятии решения о миграции важно оценить, насколько критична для компании предсказуемость затрат на поддержку: автоматическое удаление данных по TTL устраняет необходимость планировать окна обслуживания и снижает риск влияния регламентных операций на работу клиентов. В то же время вертикальное масштабирование требует наличия достаточно мощных серверов, поэтому перед переходом стоит проверить, насколько имеющаяся инфраструктура способна выдержать пиковую нагрузку без добавления узлов.
Materialized views вместо Go-воркеров
Раньше трансформации данных между таблицами делали Postgres-триггеры или Go-воркеры. Любое изменение структуры таблицы требовало правки кода и отладки, что занимало до двух дней. Сейчас цепочка materialized views выполняет все преобразования прямо на вставке. Достаточно изменить схему в ClickHouse — пайплайн обновляется без правки кода.
Время на изменения сократилось до половины дня. Часть потока всё ещё обрабатывается Go, но централизация логики в базе упростила поддержку и уменьшила количество точек отказа. При сравнении подходов важно понимать, что перенос логики трансформаций в materialized views уменьшает зависимость от внешнего кода и снижает количество мест, где может возникнуть ошибка при обновлении структуры. Это особенно значимо для self-hosted решений, где каждая правка требует координации с клиентами и тестирования в изолированных окружениях.
Что переносимо на российские контуры
Self-hosted модель OpenReplay и акцент на минимальные операционные затраты хорошо ложатся на российские условия. Компании, которым важны контроль данных и работа без внешних SaaS, получают готовый пример вертикального масштабирования под высокую ingest-нагрузку. TTL и materialized views решают типичные задачи ретеншена и трансформаций без сложных скриптов и координации с клиентами.
Ограничение — вертикальное масштабирование подходит только при наличии мощных узлов. Если кластер уже шардированный, придётся пересчитывать стоимость и сложность миграции. В остальном подход даёт чёткий ориентир: централизация аналитики в ClickHouse сокращает и время разработки, и операционную нагрузку. Перед внедрением стоит оценить, достаточно ли в компании экспертизы по ClickHouse для настройки и мониторинга, а также насколько критична возможность быстро менять схемы хранения без остановки сервиса.
Источник
Это краткий разбор материала ClickHouse. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: OpenReplay перешёл с Postgres на ClickHouse для терабайтов событий.
Курс по теме — Построение DWH на ClickHouse
