> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Уроки — нестандартные сценарии использования

> Найдите решения самых распространённых проблем ClickHouse, включая медленные запросы, ошибки памяти, проблемы с подключением и неполадки конфигурации.

*Это руководство — часть подборки выводов, сделанных на встречах сообщества. Больше практических решений и полезных наблюдений вы можете [найти по конкретной проблеме](/docs/ru/resources/support-center/tips-and-tricks/community-wisdom).*
*Нужны советы по отладке проблемы в продакшене? Ознакомьтесь с руководством сообщества [Практические рекомендации по отладке](/docs/ru/resources/support-center/tips-and-tricks/debugging-insights).*

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

<div id="clickhouse-rate-limiter">
  ## ClickHouse как ограничитель частоты запросов
</div>

Когда 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 позволила задавать более сложные правила ограничения частоты запросов, чем простые счётчики
* Использование существующего конвейера данных без необходимости разворачивать отдельную инфраструктуру

<div id="customer-analytics">
  ## ClickHouse для клиентской аналитики
</div>

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

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

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

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

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

<div id="video-sources">
  ## Видео
</div>

* **[Нарушая правила: создаём ограничитель частоты запросов с ClickHouse](https://www.youtube.com/watch?v=wRwqrbUjRe4)** - Brad Lhotsky (Craigslist)
* **[ClickHouse как аналитическое решение в ServiceNow](https://www.youtube.com/watch?v=b4Pmpx3iRK4)** - Amir Vaza (ServiceNow)

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