
Привет! В прошлой статьеЧитать полностью »

Привет! В прошлой статьеЧитать полностью »
Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где:
API отвечало слишком долго
CPU базы был загружен почти на 100%
При этом всем, инфраструктура мощная: достаточное количество RAM, NVMe-диски ну и конечно же CPU последних поколений. Но проблема почти всегда оказывалась в SQL-запросах.
Я хочу поделиться реальным опытом, как мы оптимизировали PostgreSQL в десятки раз
Один из самых типичных запросов в системе:
Читать полностью »
К написанию данной статьи меня подтолкнула другая статья:
«Не только sum() и uniq(): малоизвестные и очень полезные функции ClickHouse»
и вопрос автора: «В комментариях расскажите, какие „непопулярные“ функции кликхаус упростили вам жизнь.»
Недолго думая, я ответил: cityHash64().
Проблема N+1 стара как мир. Инструментов много: Debugbar хорош локально, Telescope тяжеловат для продакшена. Мне хотелось решения, которое будет «стучать» в Slack или Telegram именно тогда, когда проблема случилась на проде, и при этом сразу показывать пальцем на виновную строку кода.
Основная магия происходит через подписку на события базы данных в Laravel. В сервис-провайдере пакета мы слушаем QueryExecuted:
DB::listen(function (QueryExecuted $query) {
// 1. Проверяем дубликаты (N+1) по хэшу SQL
// 2. Замеряем время выполнения (Slow Query)
// 3. Если порог превышен — запускаем репортеры
});
Работая с аналитикой, мы часто сталкиваемся с одной и той же проблемой: данные есть, но исследовать их неудобно.
Представим типичную ситуацию. Есть таблица с десятками колонок и миллионами строк. Нужно понять, почему изменился какой-то показатель — например, выручка или конверсия. Обычно это превращается в цепочку SQL-запросов: сначала агрегируем данные по стране, потом по городу, потом по конкретному сегменту пользователей и тд.
Если таких гипотез несколько, количество запросов быстро растёт с геометрической прогрессией. Каждый новый уровень детализации требует отдельного SQL.
Аналитик данных — это специалист, который умеет открывать доставать данные, очищать и фильтровать их, проводить исследование, визуализировать и интерпретировать результаты обработки данных. Его главная задача — помочь бизнесу принимать решения, основанные не на интуиции, а на фактах и цифрах (data‑driven подход).
Аналитик данных может ответить на вопросы, критически важные для любой компании:
Что произошло? (Например, насколько выросли продажи после прошлой рекламной кампании)
Почему это произошло?Читать полностью »
Привет!
Меня зовут Натаров Иван. Я занимаюсь вопросами обработки, анализа и визуализации данных.
ClickHouse сегодня стал стандартом де-факто для аналитических задач, но часто начинающие специалисты тратят слишком много времени на погружение в технологию. Документация зачастую дает либо слишком поверхностное объяснение, либо уходит в технические детали, которые сложны для восприятия новичками.
В этой статье мы разберем фундамент ClickHouse - движок MergeTreeЧитать полностью »

Доброго времени суток! Моя первая статья, не судите строго) В следующий раз, постараюсь учесть все, что вы напишите в комментариях.
Всем привет! В этой статье рассмотрим наиболее полную реализацию паттерна Transactional Outbox, которую можно будет легко расширять и применять в продакшне. Данная статья будет полезна как для разработчиков, которые еще не встречались с данным паттерном, так и тем, кто уже применял его в своей работе.
Прежде чем перейти к определению паттерна, определим ключевых акторов:
Паблишер - процесс, инициирующий изменения и создающий события.
Консьюмер - процесс, обрабатывающий эти события.
Здравствуйте, уважаемые читатели !
В серии статей хочу рассказать о создании основного функционала MVP (Minimum Value Product) системы по управлению цифровыми активами для базы данных PostGIS. Полный перечень возможностей разрабатываемого проекта представлен на картинке ниже.