• сразу пишут "большой правильный запрос",

• делают несколько JOIN подряд,

• не проверяют объёмы данных,

• не смотрят кардинальность,

• а потом говорят: "База тормозит".

Но чаще всего тормозит не база.
Тормозит наше понимание модели данных.

Для начала, важно понять логику. Таблицы - это реализация, а нам надо понять:

• что является сущностью,

• что является атрибутом,

• что является справочником,

• где факт, а где классификатор.

Затем, не надо делать сразу финальный запрос, который должен вернуть результат со сложной логикой:

Сначала:

• SELECT COUNT(*)

• LIMIT 100

• группировки по статусам

• проверка на NULL

• проверка дублей

Каждый JOIN нужно проверять отдельно:

• сколько строк было до соединения,

• сколько стало после,

• не раздули ли вы данные в 10 раз.

Это экономит часы.

Самый важный вопрос:

• по чему соединяются таблицы?

• это 1:1, 1:N или N:N?

• есть ли составные ключи?

Очень часто "медленный запрос" - это не индексы и не сервер,
а просто не тот ключ в JOIN.

Если запрос со сложной логикой и при запуске висит - не нужно грешить на "неповоротливость базы "

Нужно спросить:

• есть ли индексы на поля соединения?

• используется ли фильтрация до JOIN?

• не делаем ли мы unnecessary full scan?

База редко "плохая".
Она просто делает ровно то, что ты ей сказал.

Важно искать живые примеры:
Очень правильный шаг — смотреть запросы коллег.
Это даёт:

• понимание договорённостей,

• понимание "какие данные считаются валидными",

• понимание негласных ограничений.

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

Знакомство с новой БД — это не проверка твоего SQL.
Это проверка твоего мышления.

Новичку важно понять:

• база не обязана быть удобной

• справочники не обязаны быть очевидными

• описание не равно пониманию

И если запрос выполняется час —
в 80% случаев проблема не в сервере,
а в отсутствии структуры в голове.

Для новичка не стоит пытаться доказать, что ты умеешь писать сложные запросы.
Попробуй сначала понять:

• что здесь является "фактом",

• что "состоянием",

• что "справочником",

• и что вообще считается "актуальной записью".

Когда появляется понимание модели —
запросы начинают работать быстрее.
И технически, и логически.

Потому что быстрая БД начинается
не с индексов,
а с правильных вопросов.

В моем канале Аналитика FM все про мышление аналитика, про инструменты аналитика.
Мы рассматриваем SQL и Python в применении к данным.

Этот канал я веду с нуля подписчиков. Если тебе тоже интересно погрузиться в мир аналитики, подписывайся!

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

Vast Data, базирующаяся в "Ганей Тааруха" в Тель-Авиве и имеющая широкую деятельность в США, стала в последние годы одной из основных инфраструктурных компаний эры искусственного интеллекта. Компания предоставляет решения для хранения, обработки и извлечения огромных объемов информации - критического базового слоя для ИИ-моделей, суперкомпьютеров и облачных инфраструктур.

Перевод с иврита

ИСТОЧНИК

Есть метрики, которые принципиально живут без пользователя.

- Выручка за день.
- Количество заказов.
- Средний чек.
- Сумма транзакций по категориям.

Это агрегаты "по событиям".
Им не важно, кто именно сделал действие - важно, что действие произошло.

Бизнес часто живёт именно на этом уровне, и на старте ему кажется, что этого достаточно.

Проблемы с клиентскими метриками возникают в тот момент, когда появляется аналитика "на повторы".

- Повторные покупки.
- Возвраты клиентов.
- LTV.
- Retention.
- Конверсия по шагам воронки.

Все эти метрики - не про события.
Они про людей.

А без user_id "человек" в данных перестаёт существовать.

И когда user_id отсутствует, бизнес начинает выкручиваться.

Вместо user_id появляются:

• номер телефона

• email

• cookie

• device_id

• хэш паспорта

• комбинации из "телефон + дата рождения + регион"

Это не плохие решения.
Это компромиссы.

Каждый такой "заменитель пользователя" решает одну задачу и ломает другую.

Телефон:
- отлично для CRM
- плохо для веба и офлайна

Cookie:
- хорошо для сессий
- бесполезно для долгой аналитики

Email:
- стабилен
- но есть одноразовые email-ы

Device_id:
- у клиента может быть несколько устройств
- может жить до переустановки приложения
- может стоять запрет на трекинг

В итоге бизнес не считает "пользователей".
Он считает версии пользователей.

Из-за этого появляются странные эффекты:

• пользователей стало больше, но денег больше не стало

• retention упал, но продажи выросли

• конверсия пляшет, а поведение вроде то же

И это не всегда ошибка данных.
Это ограничение идентификации.

Важно понимать:
отсутствие user_id - это не техническая проблема, а продуктовая.

Она говорит о том, как система была спроектирована изначально:

• думали ли о пользователе как о сущности

• или думали только о событиях и операциях

Поэтому аналитика без user_id возможна.
Но она всегда:

• менее точная

• более приближённая

• и требует аккуратной интерпретации

Хуже всего - считать "пользовательские" метрики и делать вид, что всё ок.

Лучше честно сказать:

Мы считаем это так, потому что другого способа у нас нет

Данные могут существовать без user_id.
Запросы SQL может работать без user_id.
Отчёты можно построить без user_id.

Но аналитика поведения - нет.

НО... Главный НО...

Наличие user_id не спасет вас от того, что клиента "на входе" не идентифицировали и завели ему новый идентификатор. Либо при объединении клиентских баз у вас не задвоится один и тот же клиент.

Это повседневные процессы бизнеса. И уникальность клиента зависит от культуры ведения данных в базе, от технических процессов и бизнес процессов.

Для дедупликации клиентских записей существуют системы класса CDI (Customer Data Integration). Такие системы помогают идентифицировать клиента и вести его мастер карточку.

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.
Присоединяйся!

А пока подписывайся на мой канала Аналитика FM.
Его я веду с нуля подписчиков.
В этом канале я публикую информацию об инструментах аналитика (SQL, Python)
О мышлении аналитика, о метриках, об ошибках.
Публикую чек-листы по стандартным видам работы аналитика.
Присоединяйся!

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

Продажи "просели".
Конверсия "стала хуже".
Клиенты "ведут себя странно".

Это язык боли, а не требований.

И тут аналитик хочет обезопасить себя со всех сторон:
- написать запрос
- вытащить все данные
- построить отчёт "на всякий случай"
- показать цифры и сказать: "Вот"

Но в реальности это почти всегда заканчивается одинаково:
- "А это не совсем то"
- "А можно по-другому?"
- "А мы вообще не это имели в виду"

Когда бизнес не знает, что ему нужно,
аналитик не исполнитель,
аналитик - переводчик.

Ты начинаешь переводить бизнесовые ощущения в конкретные показатели, и смотреть как эти показатели подтверждают/опровергают эти ощущения. Ты переводишь эмоции в конкретные метрики. Подсознательное ощущение "что-то не так", ты переводишь в конкретные вопросы к данным.

И вот на этом этапе SQL становится не просто инструментом, а следствием мышления.

Очень часто проблема не в том, что запрос неправильный.
А в том, что вопроса не существовало.

Например:

• "Продажи упали" - относительно чего?

• "Конверсия плохая" - на каком этапе?

• "Клиенты уходят" - кто именно и когда?

Пока бизнес не ответил хотя бы на это - любой запрос будет случайным.
Или аналитик с приличным бэкграундом, задаст их сам себе, задаст эти вопросы данным и получит развернутый ответ, чтобы у бизнеса были аргументированные показатели.

И это самый важный навык аналитика. Аналитик не должен просто писать сложные JOIN-ы, он должен уметь задавать вопросы так, чтобы:
- стало понятно, что именно ищем
- появилось ощущение направления
- сузилось пространство неопределенности.

И да - бывает, что бизнес так и не может сформулировать запрос.

Тогда аналитик делает не отчёт, а гипотезу.

Я предполагаю, что проблема может быть здесь.
Давайте проверим это.

Это нормальная практика.
Гораздо честнее, чем молча строить отчёт "на всякий случай".

Самое важное:
если бизнес не знает, что ему нужно - это не ошибка бизнеса.

Это точка, где аналитика становится ценностью!

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!

Рассмотрим задачу.

Есть таблица заказов. Нужно:

1. Взять только оплаченные заказы

2. Посчитать сумму заказов по пользователям

3. Оставить пользователей, у которых сумма больше 10 000

4. Отсортировать по убыванию суммы

Как это выглядит в SQL

SELECT

user_id,

SUM(amount) AS total_amount

FROM orders

WHERE status = 'paid'

GROUP BY user_id

HAVING SUM(amount) > 10000

ORDER BY total_amount DESC;

Что происходит на самом деле?

Хотя запрос написан сверху вниз, выполняется он иначе:

1. FROM — база берёт таблицу orders

2. WHERE — отфильтровывает только status = 'paid'

3. GROUP BY — группирует строки по user_id

4. SUM(amount) — считает сумму внутри каждой группы

5. HAVING — отбрасывает группы с суммой ≤ 10 000

6. SELECT — формирует финальные колонки

7. ORDER BY — сортирует результат

SQL не идёт шаг за шагом как сценарий. Для него каждый запрос - это единый слепок результата

Ты не "живешь" внутри процесса, ты его декларируешь.

Теперь тот же самый запрос в Python (pandas)

Чтобы не увеличивать объем строк с подключением к БД, сделаем так, что наши данные мы читаем из CSV файла

1. Ты загружаешь данные. Ты их уже видишь. Они лежат в память, у них есть текущее состояние.

import pandas as pd

df = pd.read_csv('orders.csv')

2. Фильтрация

paid_orders = df[df['status'] == 'paid']

paid_orders.head()

Здесь отфильтровали данные, можно посмотреть, что получилось, можно вернуться назад.
Это состояние сохранилось.

3. Группировка и агрегация

grouped = (

paid_orders

.groupby('user_id')['amount']

.sum()

.reset_index(name='total_amount')

)

grouped.head()

Ты видишь промежуточный результат:

• пользователей

• их суммы

• можешь проверить аномалии

4. Фильтр по агрегату

filtered = grouped[grouped['total_amount'] > 10000]

filtered.head()

5. Сортировка

result = filtered.sort_values('total_amount', ascending=False)

result

Ключевая разница

SQL

- нет "текущего состояния"
- каждый запрос - это новый расчет
- описываем, что хотим получить
- оптимизатор решает как

Python

- данные живут в памяти
- каждый шаг меняет состояние
- на каждом шаге можно остановиться, посмотреть, вернуться, ветвить логику

На практике аналитик:
- думает как в Python
- реализует как в SQL
- и постоянно переключается между этими моделями

Получается, что SQL и Python - это два разных способа мышления.
SQL говорит нам - вот результат
Python - вот процесс.

Python - это процедурный подход.
Аналитик говорит КАК делать:
- возьми данные
- отфильтруй
- посчитай
- отсортируй
- покажи результат
Здесь происходить управление процессом: мы ведем данные по шагам

SQL - декларативный подход.
Аналитик не говорит КАК делать, он говорит, что хочет получить.

В разбираемом примере мы говори:

Хочу видеть сумму заказов по пользователям,
только оплаченные,
только больше 10 000

Для SQL есть входные данные, правила отбора, финальный результат.
SQL не живет во времени, он живет в описании результата

Ну а в моем канале Аналитика FM не только об инструментах аналитика, но и об аналитическом мышлении, метриках, логики.

Присоединяйся!