Let’s Encrypt перенесла аналитику в ClickHouse: когда отчёты мешают работе сайта

17 сентября 2026 года Let’s Encrypt описала переход своей аналитики на ClickHouse. Сервису требовалось исследовать большой поток событий, а запросы к рабочей базе конкурировали с основной нагрузкой. Отдельное хранилище упростило анализ и поиск данных при разборе инцидентов.

Это история крупной инфраструктуры, но знакомая ситуация возникает и у магазина: покупатели оформляют заказы, а сотрудник запускает тяжёлую выгрузку за два года. И база, от которой зависит продажа, одновременно пытается стать аналитической системой.

Подозрение появляется, когда сайт замедляется в одно и то же время: после запуска отчёта, экспорта заказов или обновления управленческой панели. Проверять нужно совпадение по журналам и метрикам. Фраза «наверное, не хватает сервера» слишком расплывчата для решения.

Попросите разработчика сопоставить длительность запросов, нагрузку на диски и процессор, блокировки в базе и время оформления заказа. Важен конкретный виновник. Иногда проблему создаёт один запрос без подходящего индекса, и перенос всей аналитики окажется дорогим обходным путём.

Первый шаг — убрать лишнюю работу. Отчёту по выручке не всегда нужны полные описания товаров и все комментарии менеджеров. Ограничение периода, выбор нужных полей и подготовленные итоги часто уменьшают нагрузку без новой инфраструктуры.

Следующая возможность — запускать расчёты по расписанию и сохранять результат. Если руководителю достаточно вчерашних данных, нет смысла пересчитывать многолетнюю историю при каждом открытии страницы. Но покупателям нельзя показывать такой же вчерашний остаток: требования у этих задач разные.

Отдельное аналитическое хранилище стоит обсуждать, когда запросы регулярно перебирают большие объёмы, отчётов становится больше, а рабочая база уже оптимизирована. ClickHouse — один из вариантов для такого класса задач. Сам факт его использования известным проектом не заменяет расчёт под конкретный магазин.

При переносе важно договориться, что считать продажей: создание заказа, оплату или отгрузку. Как учитывать частичный возврат? К какому дню отнести оплату после полуночи? Без этих правил быстрый отчёт может уверенно показывать неправильную выручку.

Отдельно проверяют повторную загрузку событий. Если одно уведомление об оплате пришло дважды, сумма не должна удвоиться. Если заказ исправили задним числом, изменение обязано попасть в расчёт. Я бы включила такие случаи в приёмку раньше красивых графиков.

Кроме сервера для новой базы, появятся расходы на передачу данных, резервирование, мониторинг и поддержку. Нужен ответ, кто заметит остановку обмена и где пользователь увидит время последнего обновления отчёта.

Начать разумно с одного действительно тяжёлого отчёта. Сверить его с учётной системой, измерить влияние на сайт, проверить восстановление после сбоя. Только затем переносить остальные: так развитие аналитики не превращается в большой проект с неизвестной пользой.

On September 17, 2026, Let's Encrypt described migrating its analytics to ClickHouse. The service needed to process a massive stream of events, but queries against the production database competed with the main workload. A separate storage system simplified analysis and data retrieval during incident investigations.

This is a story of large-scale infrastructure, but a similar situation arises in online stores: customers place orders while an employee runs a heavy two-year data export. The database that drives sales simultaneously tries to function as an analytical system.

Suspicion arises when the site slows down at the same time: after running a report, exporting orders, or updating the management dashboard. Verification requires cross-referencing logs and metrics. The vague phrase 'probably not enough server capacity' is insufficient for resolving the issue.

Ask your developer to correlate query duration, disk and CPU load, database locks, and order completion times. Identifying the specific culprit is crucial. Sometimes a single query lacking a proper index causes the issue, making a full migration of analytics an expensive workaround.

The first step is to eliminate unnecessary work. A revenue report does not always require full product descriptions or all manager comments. Limiting the time period, selecting only the necessary fields, and using pre-aggregated results often reduce the load without requiring new infrastructure.

The next option is to schedule calculations and save the results. If management only needs yesterday's data, there is no need to recalculate years of history every time a page is opened. However, customers cannot be shown yesterday's stock levels: these tasks have different requirements.

A separate analytical storage should be considered when queries regularly scan large volumes, the number of reports grows, and the operational database is already optimized. ClickHouse is one option for this class of tasks. The fact that a well-known project uses it does not replace a calculation tailored to a specific store.

During migration, it is crucial to agree on what constitutes a sale: order creation, payment, or shipment. How should partial returns be handled? To which day should a payment made after midnight be attributed? Without these rules, a fast report can confidently display incorrect revenue figures.

Separately verify event reprocessing. If a payment notification arrives twice, the total amount must not double. If an order is corrected retroactively, the change must be reflected in the calculation. I would include such cases in acceptance testing before prioritizing pretty charts.

In addition to the server for the new database, you will incur costs for data transfer, backup, monitoring, and support. You need to know who will detect an interruption in data exchange and where the user can see the timestamp of the last report update.

Start with one genuinely heavy report. Compare it with the accounting system, measure its impact on the website, and test recovery after a failure. Only then migrate the remaining reports; this way, analytics development does not turn into a large project with uncertain benefits.