Перейти к основному содержанию
Это руководство — часть подборки выводов, сделанных на встречах сообщества. Больше практических решений и полезных наблюдений вы можете найти по конкретной проблеме. Нужны советы по отладке проблемы в продакшене? Ознакомьтесь с руководством сообщества Практические рекомендации по отладке. В этих историях показано, как компании добивались успеха, используя ClickHouse для своих задач, а иногда даже выходя за рамки привычных категорий баз данных и доказывая, что порой «неподходящий» инструмент оказывается именно тем, что нужно.

​
ClickHouse как ограничитель частоты запросов

Когда Craigslist понадобилось внедрить ограничение частоты запросов уровня tier-one, чтобы защитить пользователей, перед командой встал тот же выбор, с которым сталкиваются многие инженеры: пойти по проторённому пути и использовать Redis или попробовать что-то другое. Brad Lhotsky, работавший в Craigslist, знал, что Redis — стандартный вариант: почти во всех руководствах и примерах по ограничению частоты запросов в интернете Redis используется не случайно. У него богатый набор примитивов для таких операций, устоявшиеся паттерны и проверенная временем надёжность. Но практический опыт Craigslist с Redis не был похож на то, что обычно описывают в учебных примерах. “Наш опыт с Redis совсем не такой, как в кино… мы сталкивались со множеством странных проблем в эксплуатации: перезагружаешь узел в кластере Redis — и какой-нибудь всплеск задержки тут же бьёт по фронтенду.” Для небольшой команды, которая ценит простоту сопровождения, такие операционные сложности стали серьёзной проблемой. Поэтому, когда Brad получил требования по ограничению частоты запросов, он пошёл другим путём: “Я спросил босса: ‘Как тебе такая идея? Может, попробовать сделать это на ClickHouse?’” Идея была нестандартной — использовать аналитическую базу данных для задачи, которую обычно решают на уровне кэширования, — но она отвечала их ключевым требованиям: fail open, отсутствие штрафа по задержке и безопасная в эксплуатации архитектура для небольшой команды. Решение опиралось на существующую инфраструктуру, где access logs уже поступали в ClickHouse через Kafka. Вместо поддержки отдельного кластера Redis они могли анализировать шаблоны запросов напрямую по данным access logs и передавать правила ограничения в существующий ACL API. Такой подход давал немного большую задержку, чем Redis, который “в каком-то смысле жульничает, заранее поднимая этот набор данных в памяти”, а не выполняя агрегирующие запросы в реальном времени, но запросы всё равно укладывались в 100 миллисекунд. Ключевые результаты:
  • Значительное улучшение по сравнению с инфраструктурой на Redis
  • Встроенный TTL для автоматической очистки устранил накладные расходы на сопровождение
  • Гибкость SQL позволила задавать более сложные правила ограничения частоты запросов, чем простые счётчики
  • Использование существующего конвейера данных без необходимости разворачивать отдельную инфраструктуру

​
ClickHouse для клиентской аналитики

Когда ServiceNow потребовалось модернизировать свою платформу мобильной аналитики, перед командой встал простой вопрос: «Зачем менять то, что и так работает?» Амир Ваза из ServiceNow понимал, что существующая система надёжна, но требования клиентов уже переросли её возможности. «Мотивация заменить существующую надёжную модель на самом деле исходит со стороны продукта», — объяснил Амир. ServiceNow предлагала мобильную аналитику как часть своего решения для веба, мобильных приложений и чат-ботов, но клиентам была нужна аналитическая гибкость, выходящая за рамки предварительно агрегированных данных. Их прежняя система использовала около 30 разных таблиц с предварительно агрегированными данными, сегментированными по фиксированным измерениям: приложение, версия приложения и платформа. Для пользовательских свойств — пар ключ-значение, которые клиенты могли передавать, — они создавали отдельные счётчики для каждой группы. Такой подход обеспечивал высокую производительность панели мониторинга, но имел серьёзное ограничение. «Хотя это отлично подходит для быстрого разбиения по значениям, как я уже говорил, из-за этого теряется значительная часть аналитического контекста», — отметил Амир. Клиенты не могли проводить сложный анализ клиентского пути или задавать вопросы вроде «сколько сеансов началось с поискового запроса “research RSA token”», а затем анализировать, что эти пользователи делали дальше. Предварительно агрегированная структура разрушала последовательный контекст, необходимый для многошагового анализа, а каждое новое аналитическое измерение требовало инженерной работы по предварительной агрегации и хранению данных. Когда эти ограничения стали очевидны, ServiceNow перешла на ClickHouse и полностью избавилась от таких ограничений предварительных вычислений. Вместо того чтобы заранее вычислять каждую переменную, они разбили метаданные на отдельные точки данных и вставляли всё напрямую в ClickHouse. Они использовали очередь async insert в ClickHouse, которую Амир назвал «просто потрясающей», чтобы эффективно организовать ингестию данных. Благодаря этому подходу клиенты получили возможность создавать собственные сегменты, свободно анализировать данные по любым измерениям и выполнять сложный анализ клиентского пути, который раньше был невозможен. Ключевые результаты:
  • Динамическая сегментация по любым измерениям без предварительных вычислений
  • Стал возможен сложный анализ клиентского пути
  • Клиенты получили возможность создавать собственные сегменты и свободно анализировать данные
  • Больше никаких инженерных узких мест при появлении новых аналитических требований

​
Видео

Эти истории показывают, как отказ от устоявшихся представлений о базах данных может привести к прорывным решениям, расширяющим границы возможного для аналитических баз данных.
Последнее изменение 10 июня 2026 г.