Все началось с просьбы сделать отчеты в реальном времени. На первый взгляд задача выглядела простой, но довольно быстро выяснилось, что существующая архитектура для этого не подходит.
Проект был разбит на множество микросервисов, каждый из которых хранил данные в собственной PostgreSQL-базе. Чтобы строить сквозные отчеты, информацию нужно было где-то объединять.
В одной телеком‑компании, где я работал, возникла проблема класса «тихих» деградаций: абоненты массово жаловались, что при отличном уровне сигнала невозможно совершить или принять голосовой вызов.
Вендорские системы мониторинга при этом не фиксировали аварий, а оборудование не сигнализировало о сбоях. С точки зрения всех стандартных метрик сектор выглядел полностью работоспособным.
Однако в реальности на отдельных секторах базовых станций голосовой трафик внезапно исчезал, тогда как сам сектор продолжал оставаться «зеленым» во всех системах наблюдения.
Когда инженер слышит «нам нужно хранилище данных», задача редко звучит однозначно. Кто‑то задыхается на боевой OLTP‑базе под аналитической нагрузкой. Кто‑то впервые строит BI и не понимает, с какого края подходить. У кого‑то накопились данные из десятка систем‑источников, и существующих средств уже не хватает.
У всех «хранилище». А правильный технический ответ зависит от условий задачи.
CPU 80%, память на пределе, диск нагружен. Запросы тормозят. Расчёты не завершаются. Сервер на грани. Что же делать?
Расскажу как начинаю диагностику и как найти запрос, который создаёт нагрузку.
Если нода прямо сейчас перегружена, начинаем с system.processesЧитать полностью »
К написанию данной статьи меня подтолкнула другая статья:
«Не только sum() и uniq(): малоизвестные и очень полезные функции ClickHouse»
и вопрос автора: «В комментариях расскажите, какие „непопулярные“ функции кликхаус упростили вам жизнь.»
Недолго думая, я ответил: cityHash64().
Привет!
Меня зовут Натаров Иван. Я занимаюсь вопросами обработки, анализа и визуализации данных.
ClickHouse сегодня стал стандартом де-факто для аналитических задач, но часто начинающие специалисты тратят слишком много времени на погружение в технологию. Документация зачастую дает либо слишком поверхностное объяснение, либо уходит в технические детали, которые сложны для восприятия новичками.
В этой статье мы разберем фундамент ClickHouse - движок MergeTreeЧитать полностью »
В этой статье мы поговорим о том, как реализовать поведение атомарной вставки в ClickHouse. Рассмотрим несколько вариантов, подсветим их сильные и слабые стороны, а также, когда каждый из них применять.
Задача
Мы хотим добиться, чтобы не было случаев, когда мы начали вставку, а пользователь прочитал данные до её завершения и получил неактуальный (неполный) набор данных.
Неатомарная вставка = риск чтения некорректного набора данных.
Сценарии, когда такое может произойти:
Удалили партицию и хотели начать вставлять данные взамен удалённой, но пользователь обратился к этому интервалу.
Когда вы работаете с распределённой системой — будь то микросервисы, фронтенд + бэкенд или nginx + приложение — жизненно важно иметь ��озможность «протянуть» один и тот же идентификатор запроса через все её компоненты. Это позволяет сопоставлять логи из разных источников, быстро находить ошибки и проводить корреляционный анализ.
В nginx для этого из коробки есть переменная $request_id — 32-символьный hex-идентификатор (например, a1b2c3d4e5f678901234567890abcdef). Его можно передать бэкенду через proxy_set_header X-Request-ID $request_id; или fastcgi_param HTTP_X_REQUEST_ID $request_id;, а также сохранить в access-логах.
Все датасеты, конфигурации и результаты тестирования в данной статье актуализированы по состоянию на 2022 год. Если вам интересно, вы можете воспроизвести тестирование, скачав актуальные наборы данных и следуя последним инструкциям соответствующих проектов/бенчмарков (например, ClickHouse, StarRocks, TPC‑H, SSB). Мы будем признательны за обратную связь: поделитесь, пожалуйста, вашими результатами и замечаниями.
Делюсь практическим опытом внедрения Uptrace v2.0 — от разворачивания до оптимизации запросов. С цифрами, кодом и реальными кейсами.
Uptrace v2.0 использует новый JSON-тип ClickHouse для хранения трейсов, что даёт 10x ускорение запросов. Показываю на практике: установка за 5 минут, настройка трансформаций данных, экономия на retention policies. Бенчмарки на 500M span'ах: запросы стали выполняться за 0.3-0.5 сек вместо 4-7 сек.
