4784. В отчёте при повторном запуске через секунду появились новые строки из-за параллельной вставки на уровне READ COMMITTED. Какой уровень изоляции гарантирует стабильность повторного чтения?
Anonymous Quiz
20%
READ UNCOMMITTED
19%
READ COMMITTED
42%
REPEATABLE READ
19%
SERIALIZABLE
Вы запускаете отчётный запрос, который выполняется несколько секунд. Пока он работает, другой процесс вставляет новые заказы. При уровне изоляции READ COMMITTED ваш запрос видит только те данные, которые были зафиксированы на момент начала чтения каждой строки, но из-за того, что вставки происходят параллельно, при повторном запуске того же запроса могут появиться новые строки (фантомы). Это называется фантомное чтение.
Что такое уровень изоляции SERIALIZABLE?
Самый строгий уровень изоляции транзакций. Он гарантирует, что параллельные транзакции выполняются так, как если бы они шли последовательно (одна за другой).
Предотвращает все аномалии: грязное чтение, неповторяемое чтение и фантомы.
В вашем случае: транзакция с отчётом при старте как бы «замораживает» состояние базы, и даже если другие транзакции вставляют новые строки, они не будут видны до конца текущей транзакции. Повторный запуск того же запроса в новой транзакции увидит изменения, но внутри одной транзакции результат будет стабильным.
❌ Почему не подходят другие варианты:
A (READ UNCOMMITTED) — разрешает грязное чтение (видны незафиксированные изменения), вообще не решает проблему.
B (READ COMMITTED) — предотвращает грязное чтение, но допускает неповторяемое чтение и фантомы.
C (REPEATABLE READ) — предотвращает неповторяемое чтение (те же строки не меняются), но некоторые СУБД (например, PostgreSQL) на этом уровне не предотвращают фантомы, если не используется SERIALIZABLE. В MySQL с InnoDB REPEATABLE READ предотвращает фантомы благодаря gap-блокировкам, но это особенность реализации. Стандарт SQL предписывает предотвращение фантомов только на уровне SERIALIZABLE.
Реальный кейс
В системе аналитики отчёты формировались на уровне изоляции READ COMMITTED. Бухгалтер запускал отчёт по выручке, смотрел цифры, через 5 минут перезапускал — сумма менялась на несколько тысяч. Причина: параллельно шли начисления бонусов и новые заказы. Переключили отчётные транзакции на SERIALIZABLE — результат стал стабильным в рамках сессии, но производительность упала из-за блокировок. Компромисс: пошли на ежечасное обновление материализованного представления вместо реального времени.
Что должен зафиксировать аналитик:
Для отчётов, требующих строгой согласованности (финансы, аудит) — указывать требование к уровню изоляции SERIALIZABLE или использовать механизм снэпшотов (MVCC).
Допустимость времени выполнения — SERIALIZABLE может быть медленнее из-за блокировок.
Альтернатива: выполнять отчёты на реплике в режиме READ ONLY с уровнем SERIALIZABLE или делать снимок данных (экспорт) на момент начала формирования отчёта.
Вывод: Выбор уровня изоляции влияет на согласованность и производительность. Аналитик должен требовать спецификации уровня изоляции для критичных отчётов, особенно в финансовой сфере. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
4785. В таблице user_logins есть дубликаты. Нужно оставить только самый ранний вход для каждого пользователя в каждый день. Какой запрос это сделает?
Anonymous Quiz
13%
DELETE ... NOT IN (SELECT MIN(id) ...)
5%
DELETE с JOIN по времени
43%
WITH ranked AS (...) DELETE ... WHERE rn > 1
38%
DELETE с подзапросом > MIN(login_time)
Почему C — правильный?
Оконная функция ROW_NUMBER() нумерует строки внутри группы (user_id, день) в порядке возрастания login_time. Самый ранний вход получает номер 1. Затем удаляются все строки с номером больше 1 (rn > 1). Это стандартный, производительный и надёжный способ дедупликации, поддерживаемый всеми современными СУБД (PostgreSQL, MySQL 8+, SQL Server, Oracle).
Пример реального кода (вариант C):
```sql
WITH ranked AS (
SELECT id, user_id, login_time,
ROW_NUMBER() OVER (
PARTITION BY user_id, DATE(login_time)
ORDER BY login_time
) AS rn
FROM user_logins
)
DELETE FROM user_logins
WHERE (user_id, login_time) IN (
SELECT user_id, login_time FROM ranked WHERE rn > 1
);
```
Почему не подходят другие варианты:
A (NOT IN MIN(id)) — предполагает, что минимальный id соответствует самому раннему времени, но это не гарантировано (id может быть сгенерирован позже). Также NOT IN с подзапросом опасен при NULL и медленен на больших таблицах.
B (JOIN по времени) — может случайно удалить и самую раннюю запись, если существует более ранняя в тот же день. Синтаксис не универсален.
D (подзапрос > MIN) — некорректный синтаксис для массового удаления, выполняется построчно, очень медленно.
Реальный кейс:
В системе логов из-за ретраев образовались дубликаты: один пользователь в одну секунду имел несколько записей. Аналитик написал запрос с ROW_NUMBER() и удалил 8 млн дубликатов за 1 секунду. Вариант с NOT IN упал по таймауту.
Вывод для аналитика:
ROW_NUMBER() — ключевой инструмент для дедупликации, выбора первой/последней записи в группе. Это must-have в арсенале аналитика, работающего с SQL. 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
4786. Нужно найти клиентов, у которых сумма покупок за всё время превышает 1 000 000 рублей. Какой запрос правильный?
Anonymous Quiz
15%
SELECT client_id FROM sales WHERE SUM(amount) > 1000000
55%
SELECT client_id FROM sales GROUP BY client_id HAVING SUM(amount) > 1000000
17%
SELECT client_id, SUM(amount) > 1000000 FROM sales GROUP BY client_id
13%
SELECT client_id FROM sales GROUP BY client_id WHERE SUM(amount) > 1000000
Нужно отфильтровать сгруппированные данные по агрегатной функции (SUM). WHERE применяется до группировки и не может использовать агрегаты. HAVING — после группировки и предназначен именно для фильтрации групп.
Разбор вариантов:
A (WHERE SUM(...)) — синтаксическая ошибка, WHERE не видит агрегат.
B — корректно: сначала группируем по client_id, считаем сумму, потом оставляем только те группы, где сумма > 1 000 000.
C — вернёт для каждого клиента булево значение, но не отфильтрует строки.
D — WHERE нельзя использовать после GROUP BY (порядок: WHERE → GROUP BY → HAVING).
Реальный кейс:
В аналитике продаж часто спрашивают: «Покажи клиентов, купивших больше чем на N рублей». Новички пишут WHERE SUM(amount) > N и получают ошибку. Правильный запрос с HAVING выполняется мгновенно, если есть индекс на client_id.
Вывод для аналитика:
WHERE — фильтрует строки до группировки.
HAVING — фильтрует группы после агрегации.
Запомните порядок: FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY.
Please open Telegram to view this post
VIEW IN TELEGRAM
ПОДПИСКИ НА ИИ-КАНАЛЫ ЕСТЬ, А СВЕЖИХ ИДЕЙ — НОЛЬ !?
* Твои подписки устарели (outdated). Пора сделать АПГРЕЙД своего информационного поля.
Сегодняшний ИИ — это не «10 крутых промтов» и не новость про ChatGPT-5. Это рабочие связки, реальные кейсы, свежие инструменты, которые сэкономят тебе часы уже на этой неделе.
Проблема не в том, что ты мало читаешь. А в том, что ты читаешь не тех ...
Мы собрали свежую ПОДБОРКУ каналов, где авторы реально работают с технологиями здесь и сейчас. Никаких повторов и воды. Только практика, кейсы, новые тулы и разборы, которые имеют значение.
📂 Добавляй ПАПКУ — и получи полный АПГРЕЙД своей ленты:
➡️ https://t.me/addlist/r5VfG-YYZB9mNzM8
* Сделай свою подписку умнее, пока другие читают вчерашние новости и не бойся перемен ...
Отписаться можно в любой момент. Остаться — тоже ✔️
* Твои подписки устарели (outdated). Пора сделать АПГРЕЙД своего информационного поля.
Сегодняшний ИИ — это не «10 крутых промтов» и не новость про ChatGPT-5. Это рабочие связки, реальные кейсы, свежие инструменты, которые сэкономят тебе часы уже на этой неделе.
Проблема не в том, что ты мало читаешь. А в том, что ты читаешь не тех ...
Мы собрали свежую ПОДБОРКУ каналов, где авторы реально работают с технологиями здесь и сейчас. Никаких повторов и воды. Только практика, кейсы, новые тулы и разборы, которые имеют значение.
📂 Добавляй ПАПКУ — и получи полный АПГРЕЙД своей ленты:
➡️ https://t.me/addlist/r5VfG-YYZB9mNzM8
* Сделай свою подписку умнее, пока другие читают вчерашние новости и не бойся перемен ...
Отписаться можно в любой момент. Остаться — тоже ✔️
🔥1
ХОЧЕШЬ ИДТИ В НОГУ С ТЕХНОЛОГИЯМИ ?! … или наблюдать, как другие зарабатывают на ИИ? - РЕШАТЬ ТЕБЕ !
ИИ станет твоим главным инструментом, а не загадкой 🗝
Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя и заодно попали в эту ПОДБОРКУ сами ✔️
Что внутри? Только лучшее из Мира IT & AI :
* ИИ — не хайп, а реальные инструменты и внедрения
* Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает профессионалов прямо сейчас
* AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ
Делимся знаниями и аудиторией - растём вместе ⚡️ Забирай бесплатно ПАПКУ с ТОП ИИ Каналами
Твой доступ к подборке и бонусам:
➡️ Просто добавь Папку - никаких смс или регистраций. Отписаться можно в любой момент. Остаться — тоже ✔️ * Ссылка - https://t.me/addlist/r5VfG-YYZB9mNzM8
ИИ станет твоим главным инструментом, а не загадкой 🗝
Больше не нужно мониторить сотни источников в надежде найти адекватных авторов. Мы сделали это за тебя и заодно попали в эту ПОДБОРКУ сами ✔️
Что внутри? Только лучшее из Мира IT & AI :
* ИИ — не хайп, а реальные инструменты и внедрения
* Технологии — тренды, обзоры, инсайты от первых лиц
* Карьера — как найти работу, вырасти и не выгореть
* HR Tech — кто и как нанимает профессионалов прямо сейчас
* AI Life hacks — как выжить и зарабатывать за границей с помощью возможностей ИИ
Делимся знаниями и аудиторией - растём вместе ⚡️ Забирай бесплатно ПАПКУ с ТОП ИИ Каналами
Твой доступ к подборке и бонусам:
➡️ Просто добавь Папку - никаких смс или регистраций. Отписаться можно в любой момент. Остаться — тоже ✔️ * Ссылка - https://t.me/addlist/r5VfG-YYZB9mNzM8
🔥2❤1👍1
4787. Платёжный шлюз иногда присылает повторный callback об успешной оплате. Из-за этого деньги списываются дважды. Какое требование нужно добавить в интеграцию?
Anonymous Quiz
1%
Увеличить таймаут ожидания callback
98%
Идемпотентность обработки: проверять уникальный идентификатор платежа перед списанием
1%
Отключить повторные callback на стороне шлюза
0%
Добавить ручное подтверждение оператором каждого платежа
Платёжные системы часто работают по протоколу at‑least‑once (гарантия доставки, но с возможными дублями). Сетевые сбои, перезапуски сервисов, таймауты могут привести к тому, что один и тот же успешный платёж уведомит ваш сервис дважды. Если ваша система просто списывает деньги по каждому вызову, клиент заплатит дважды. Скандал, возвраты, штрафы.
Решение — идемпотентность:
Обработчик платежа должен быть спроектирован так, чтобы повторная обработка того же платежа не меняла состояние системы (не списывала деньги повторно, не создавала дубликат заказа). Для этого нужно:
Каждому платежу присвоить уникальный идентификатор (например, payment_id).
При получении callback проверить, не обрабатывался ли уже этот payment_id.
Если обрабатывался — просто вернуть успех, ничего не делая.
Если нет — выполнить списание и запомнить payment_id в БД или кэше.
Пример кода (вариант B):
```python
def payment_callback(payment_id, amount):
# Ключ идемпотентности — payment_id
if redis.exists(payment_id):
return {"status": "already_processed"}
# Блокируем ключ на время обработки (например, 24 часа)
redis.setex(payment_id, 86400, "processed")
# Выполняем списание (только один раз)
debit_account(amount)
return {"status": "success"}
```
❌ Почему не другие варианты:
A (увеличить таймаут) — не решит проблему дублей, таймаут относится к ожиданию ответа, а не к повторным вызовам.
C (отключить повторные callback) — невозможно, внешний шлюз не позволит, да и это снизит надёжность (при сбое уведомление не придёт вообще).
D (ручное подтверждение) — убивает автоматизацию, требует персонала, не масштабируется.
Реальный кейс:
Интернет-магазин подключил платёжный агрегатор. В первые же дни у нескольких клиентов списалось вдвое больше. Причина — агрегатор в целях надёжности дублировал callback при таймауте подтверждения (магазин отвечал чуть дольше 3 секунд). После внедрения проверки по payment_id дубликаты перестали наносить урон.
Вывод для аналитика:
Идемпотентность — обязательное требование для интеграций с внешними системами, которые могут вызывать один и тот же коллбек несколько раз (а это почти все платёжные, SMS, email, push-сервисы). Аналитик должен явно прописывать в требованиях: «Обработчик должен быть идемпотентным, используя уникальный идентификатор события». 🎯
Please open Telegram to view this post
VIEW IN TELEGRAM
Вы уже выбрали где будете продвигаться в 2026 году ?
Все разделись на разные лагеря, кто-то:
— Продвигает Телеграм
— Уходит в Мах
— Развивает ВК и Нельзяграм, и другие площадки
Кто бы что не говорил, но наступает эра многоканальности и важно не расслабляться!
Поэтому мы с коллегами для вас подготовили в закрытом канале готовые инструкции по продвижению🚀
Что вас ждет?
• Как набрать первую 1000 подписчиков в Telegram бесплатно
• Жирная статья «30 актуальных способов трафика в Телеграм»
• Как бесплатно привлекать подписчиков из Threads и получать заявки системно
• АВИТО: Как найти рабочую связку за 15000р
• Как получать заявки из Pinterest
• Как набрать подписчиков в свой блог в Дзене
• Секретные связки, которые обеспечивают поток заявок за 7 дней
• База проверенных блогеров для рекламы в тг
• Простые инструменты ИИ для ускорения работы и генерации лидов
• Шаблоны сообщений для закрытия клиентов на продажу по переписке
• Схема продаж на холодную аудиторию
• Примеры лидмагнитов, которые продают за вас
• Фишки в продвижении во ВКонтакте
• Движуха в МАХ, где можно набрать подписчиков бесплатно!
• Подборка сервисов по поиску каналов для рекламы в МАХ
И многое другое!
Чек-листы, полезные статьи, уроки, подкасты - как находить клиентов в новых реалиях и не сливать бюджет на рекламу впустую!
👇👇👇
https://t.me/addlist/DZdPxDwua4VhN2Zi
Все разделись на разные лагеря, кто-то:
— Продвигает Телеграм
— Уходит в Мах
— Развивает ВК и Нельзяграм, и другие площадки
Кто бы что не говорил, но наступает эра многоканальности и важно не расслабляться!
Поэтому мы с коллегами для вас подготовили в закрытом канале готовые инструкции по продвижению
Что вас ждет?
• Как набрать первую 1000 подписчиков в Telegram бесплатно
• Жирная статья «30 актуальных способов трафика в Телеграм»
• Как бесплатно привлекать подписчиков из Threads и получать заявки системно
• АВИТО: Как найти рабочую связку за 15000р
• Как получать заявки из Pinterest
• Как набрать подписчиков в свой блог в Дзене
• Секретные связки, которые обеспечивают поток заявок за 7 дней
• База проверенных блогеров для рекламы в тг
• Простые инструменты ИИ для ускорения работы и генерации лидов
• Шаблоны сообщений для закрытия клиентов на продажу по переписке
• Схема продаж на холодную аудиторию
• Примеры лидмагнитов, которые продают за вас
• Фишки в продвижении во ВКонтакте
• Движуха в МАХ, где можно набрать подписчиков бесплатно!
• Подборка сервисов по поиску каналов для рекламы в МАХ
И многое другое!
Чек-листы, полезные статьи, уроки, подкасты - как находить клиентов в новых реалиях и не сливать бюджет на рекламу впустую!
Чтобы получить доступ к материалам:
1. Подпишитесь на всех экспертов из папки
2. Перейдите в закрытый канал с названием «ПОДАРКИ»
👇👇👇
https://t.me/addlist/DZdPxDwua4VhN2Zi
Please open Telegram to view this post
VIEW IN TELEGRAM
4788. При моделировании процесса выдачи кредита аналитик использовал два параллельных блока проверки: скоринг и проверку кредитной истории. Заявка отправляется на следующий шаг.
Anonymous Quiz
10%
XOR-шлюз
80%
AND-шлюз (fork + join)
3%
OR-шлюз
7%
Event-шлюз
Самый недооценённый навык сейчас —
умение правильно ставить задачи ИИ.
Можно дать один и тот же запрос -
и получить либо «воду»,
либо результат, который экономит часы работы.
ИИ — это про мышление
Я собрал папку с теми, кто реально умеет с этим работать — иногда захожу, чтобы держать уровень.
https://t.me/addlist/apNCMgFIc6g2NjVi
Вы как используете ИИ: поиграться или уже в работе?
умение правильно ставить задачи ИИ.
Можно дать один и тот же запрос -
и получить либо «воду»,
либо результат, который экономит часы работы.
И дело не в инструменте.
А в том, как ты формулируешь.
Чем точнее вопрос — тем сильнее результат.
ИИ — это про мышление
Я собрал папку с теми, кто реально умеет с этим работать — иногда захожу, чтобы держать уровень.
https://t.me/addlist/apNCMgFIc6g2NjVi
Вы как используете ИИ: поиграться или уже в работе?
Две независимые проверки (скоринг и кредитная история) должны выполняться параллельно. Процесс может идти дальше только после того, как обе проверки завершены. Это классический случай fork/join.
Как это выглядит в BPMN:
Fork (AND-шлюз с одним входом и несколькими выходами) — разделяет поток на две параллельные ветки.
Join (AND-шлюз с несколькими входами и одним выходом) — ждёт завершения всех входящих веток, прежде чем продолжить.
Почему не подходят другие шлюзы:
A (XOR) — выбирает только один путь из нескольких. Не подходит, так как нужны обе проверки.
C (OR) — активирует один или несколько путей. Но слияние OR может продолжаться после завершения любой из веток, что не гарантирует выполнение обеих.
D (Event) — выбирает путь на основе наступления события (таймер, сообщение), не подходит для параллельных задач.
Реальный кейс:
В банке процесс выдачи кредита изначально был последовательным: сначала скоринг, потом кредитная история. Время ожидания — 2 минуты. Аналитик перерисовал процесс с AND-шлюзом, и проверки стали выполняться параллельно. Время сократилось до 1 минуты. Экономия времени клиентов — 50%.
Что должен зафиксировать аналитик:
Если задачи не зависят друг от друга и могут выполняться одновременно — используйте AND-шлюз.
Не забывайте про join, иначе процесс «зависнет» в нескольких параллельных потоках.
В спецификации к каждой ветке укажите, какие данные нужны для следующего шага.
Вывод: AND-шлюз — ключевой элемент для параллельного выполнения независимых задач. Аналитик, умеющий применять fork/join, оптимизирует время протекания процесса (cycle time).
Please open Telegram to view this post
VIEW IN TELEGRAM
Подарки от маркетологов, которые заменят десятки курсов!
🎁 Чек-листы, инструкции, воронки, скрипты —
всё, что можно взять и сразу применить в реальной практике:
— привлечь клиентов уже за первую неделю
— выстроить стабильный поток заявок
— быстрее найти работающие связки в разных соц.сетях ( Телеграм, МАХ, ВКонтакте, Авито, Дзен, Нельзяграм, Тредс, Pinterest)
Подпишись на подборку и получи доступ к материалам👇
https://t.me/addlist/DZdPxDwua4VhN2Zi
🎁 Чек-листы, инструкции, воронки, скрипты —
всё, что можно взять и сразу применить в реальной практике:
— привлечь клиентов уже за первую неделю
— выстроить стабильный поток заявок
— быстрее найти работающие связки в разных соц.сетях ( Телеграм, МАХ, ВКонтакте, Авито, Дзен, Нельзяграм, Тредс, Pinterest)
Подпишись на подборку и получи доступ к материалам👇
https://t.me/addlist/DZdPxDwua4VhN2Zi
4789. Компания обновила REST API, добавив обязательное поле в запрос. Старые клиенты сломались. Какой подход предотвратил бы поломку?
Anonymous Quiz
22%
Версионирование через параметр запроса ?version=1
4%
Версионирование через заголовок Accept
40%
Поддержка нескольких версий API одновременно с grace period
34%
Версионирование через путь /v1/resource