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

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

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

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

ClickHouse в качестве ограничителя скорости​

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

Поэтому, когда Брэд столкнулся с требованиями по ограничению скорости, он подошел к делу по-другому: "Я спросил своего босса: 'Что ты думаешь об этой идее? Может быть, я могу попробовать это с ClickHouse?'" Идея была нестандартной - использовать аналитическую базу данных для решения проблемы, которая обычно относится к проблемам кэширования, - но она соответствовала их основным требованиям: обеспечивать отказ по умолчанию, не накладывать задержек и быть безопасной в обслуживании для небольшой команды. Решение использовало существующую инфраструктуру, где журналы доступа уже поступали в ClickHouse через Kafka. Вместо того чтобы обслуживать отдельный кластер Redis, они могли анализировать паттерны запросов прямо из данных журналов доступа и внедрять правила ограничения скорости в их существующий API ACL. Такой подход означал немного более высокую задержку, чем у Redis, который "по сути обманывает, создавая этот набор данных заранее," а не выполняя агрегационные запросы в режиме реального времени, но запросы все равно выполнялись за менее чем 100 миллисекунд.

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

  • Резкое улучшение по сравнению с инфраструктурой Redis
  • Встроенный TTL для автоматической очистки устранил накладные расходы на обслуживание
  • Гибкость SQL обеспечила сложные правила ограничения скорости помимо простых счетчиков
  • Использование существующего конвейера данных вместо необходимости выделенной инфраструктуры

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

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

Их предыдущая система использовала около 30 различных таблиц с предварительно агрегированными данными, сегментированными по фиксированным размерам: приложению, версии приложения и платформе. Для пользовательских свойств - пар ключ-значение, которые клиенты могли отправлять - они создали отдельные счетчики для каждой группы. Этот подход обеспечивал быструю работу панели инструментов, но имел одно серьезное ограничение. "Хотя это отлично подходит для быстрого разбора значений, я упоминал, что ограничение приводит к потере аналитического контекста," отметил Амир. Клиенты не могли выполнять сложный анализ пути клиента или задавать вопросы, такие как "сколько сессий началось с поискового термина 'исследование токена RSA'" и затем анализировать, что эти пользователи сделали дальше. Предварительно агрегированная структура разрушала последовательный контекст, необходимый для многопользовательского анализа, и каждое новое аналитическое измерение требовало инженерных работ для предварительной агрегации и хранения.

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

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

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

Видео источники​

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