Перейти к основному содержанию
Перейти к основному содержанию

Истории успеха

Это руководство является частью сборника выводов, полученных на встречах сообщества. Для дополнительных практических решений и идей вы можете искать по конкретной проблеме. Нужны советы по отладке проблемы в продакшене? Ознакомьтесь с руководством сообщества Debugging Insights.

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

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

Когда Craigslist понадобилось внедрить ограничение скорости запросов уровня tier-one для защиты своих пользователей, команда столкнулась с тем же выбором, что и любой другой инженерный коллектив: следовать общепринятым рекомендациям и использовать Redis или попробовать иной подход. Брэд Лхоцки (Brad Lhotsky), работавший в Craigslist, знал, что Redis — стандартный выбор: практически каждое руководство и пример по ограничению скорости запросов в интернете использует Redis, и неслучайно. У него есть богатые примитивы для операций по rate limiting, хорошо отработанные паттерны и доказанная надежность. Но опыт Craigslist с Redis не совпадал с учебниковыми примерами. «Наш опыт с Redis — это не то, что вы видели в фильмах... у нас возникает множество странных эксплуатационных проблем: мы перезагружаем узел в кластере Redis — и тут же всплеск задержек попадает на фронтенд». Для небольшой команды, ценящей простоту эксплуатации, эти операционные сложности становились серьезной проблемой.

Поэтому, когда к Брэдy обратились с требованиями по ограничению скорости запросов, он выбрал иной путь: «Я спросил у начальника: “Что вы думаете об этой идее? Может, мне попробовать сделать это на ClickHouse?”» Идея была нетипичной — использовать аналитическую базу данных для задачи, которая обычно решается на уровне кеширующего слоя, — но она закрывала их ключевые требования: fail open, отсутствие дополнительных задержек и эксплуатационная безопасность для небольшой команды. Решение опиралось на уже существующую инфраструктуру, в которой журналы доступа уже поступали в ClickHouse через Kafka. Вместо поддержки отдельного кластера Redis они могли анализировать паттерны запросов напрямую по данным access-log и внедрять правила rate limiting в существующий ACL API. Такой подход означал немного более высокую задержку, чем у Redis, который «немного жульничает, заранее инициализируя этот набор данных» вместо выполнения агрегирующих запросов в реальном времени, но при этом запросы все равно выполнялись менее чем за 100 миллисекунд.

Ключевые результаты:

  • Существенное улучшение по сравнению с инфраструктурой на Redis
  • Встроенный TTL для автоматической очистки устранил операционные накладные расходы
  • Гибкость SQL позволила реализовать сложные правила rate limiting, выходящие за рамки простых счетчиков
  • Задействован существующий pipeline обработки данных вместо ввода отдельной инфраструктуры

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

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

Их предыдущая система использовала около 30 различных таблиц с предагрегированными данными, сегментированными по фиксированным измерениям: приложение, версия приложения и платформа. Для пользовательских свойств — пар «ключ-значение», которые могли отправлять клиенты, — они создавали отдельные счётчики для каждой группы. Такой подход обеспечивал высокую скорость работы дашбордов, но имел серьёзное ограничение. «Хотя это и отлично подходит для быстрого разбиения значений, упомянутое ограничение приводит к значительной потере аналитического контекста», отметил Амир. Клиенты не могли выполнять сложный анализ клиентского пути (customer journey) или задавать вопросы вроде «сколько сессий началось с поискового запроса "research RSA token"» и затем анализировать, что эти пользователи делали дальше. Предагрегированная структура разрушала последовательный контекст, необходимый для многошагового анализа, а каждое новое аналитическое измерение требовало работы инженеров по предварительной агрегации и хранению данных.

Когда ограничения стали очевидны, ServiceNow перешла на ClickHouse и полностью избавилась от этих ограничений, связанных с предварительными вычислениями. Вместо того чтобы заранее просчитывать каждую переменную, они разбили метаданные на отдельные точки данных и вставляли всё напрямую в ClickHouse. Они использовали очередь асинхронных вставок ClickHouse, которую Амир назвал «действительно потрясающей», чтобы эффективно обрабатывать ингестию данных. Такой подход означал, что клиенты теперь могли создавать собственные сегменты, свободно анализировать данные в любом разрезе и выполнять сложный анализ клиентского пути, который раньше был невозможен.

Ключевые результаты:

  • Динамическая сегментация по любым измерениям без предварительных вычислений
  • Сложный анализ клиентского пути стал возможен
  • Клиенты смогли создавать собственные сегменты и свободно анализировать данные в любом разрезе
  • Больше нет инженерных узких мест при появлении новых аналитических требований

Видеоматериалы​

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