Excel, Python или SQL — какой инструмент выбрать под задачу?

Логика часто одна и та же, меняется лишь подход к её реализации.

Сравниваем три инструмента на практике: фильтрацию, сортировку, агрегацию, обработку пропусков, вычисления и объединение данных.

Полезная шпаргалка для тех, кто работает с данными и хочет понимать, как решать одни и те же задачи в Excel, Python и SQL.

👉 @SQLPortal

Поиск узких мест в базе данных

Когда приложение начинает тормозить, первой под подозрение часто попадает база данных. Но высокая задержка на стороне БД не означает, что пора покупать более мощный сервер. Причина может быть в неэффективном запросе, блокировках, исчерпании пула соединений, дисковом I/O или нехватке ресурсов.

Разберёмся, как найти настоящую причину.

1. Найдите симптомы. Проверьте время выполнения запросов (особенно p95), количество активных соединений, число медленных запросов, загрузку CPU и дисковый I/O. Сопоставьте эти показатели с задержками приложения, всплесками трафика и недавними деплоями, чтобы понять, когда началась проблема.

2. Определите узкое место. Выясните, что именно происходит: база медленно выполняет запросы, ожидает снятия блокировок, исчерпала доступные соединения или упёрлась в ограничения ресурсов. Также важно различать время выполнения запроса и время ожидания свободного соединения или завершения другой транзакции.

3. Соберите данные. В PostgreSQL для диагностики пригодятся следующие инструменты:
pg_stat_statements — поиск ресурсоёмких запросов.
pg_stat_activity — просмотр активных запросов и сессий, ожидающих выполнения.
pg_locks — анализ блокировок.
EXPLAIN (ANALYZE, BUFFERS) — изучение плана выполнения запроса и активности буферов. Будьте осторожны: ANALYZE действительно выполняет запрос.

4. Найдите первопричину.

Медленные запросы: отсутствующие индексы, неэффективные JOIN, полное сканирование таблиц или неудачные планы выполнения.
Блокировки: долгие транзакции или одновременные обновления данных.
Исчерпание соединений: неправильная настройка пулов, простаивающие или утёкшие соединения.
Высокая дисковая нагрузка: интенсивное чтение и запись, большие сканирования или ограничения хранилища.
Нехватка ресурсов: ограничения по CPU, памяти или дисковой ёмкости.

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

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

6. Убедитесь, что проблема решена. Сравните задержки запросов, использование соединений, загрузку CPU, дисковый I/O и частоту ошибок приложения с показателями до инцидента. Проверьте, сохраняется ли улучшение при типичной нагрузке.

Последовательность диагностики:
Наблюдение → Локализация → Исследование → Диагностика → Исправление → Проверка

Примеры в этом материале основаны на PostgreSQL, но сам подход применим и к MySQL, SQL Server и Oracle. При этом диагностические инструменты и команды будут отличаться.
Не гадайте, в чём проблема с базой данных. Соберите доказательства, устраните причину и измерьте результат.

👉 @SQLPortal

SQL Mindmap: фундамент SQL на одной карте

Изучите основные концепции SQL с помощью наглядной интеллект-карты. В ней собраны ключевые темы для начинающих:

Основы баз данных:

SELECT — выборка данных
WHERE — фильтрация записей
JOIN — объединение таблиц
GROUP BY — группировка данных
Агрегатные функции: COUNT, SUM, AVG, MIN, MAX
ORDER BY — сортировка результатов
Подзапросы — запросы внутри других запросов

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

👉 @SQLPortal

Главный совет для разработчиков, которые только начинают работать с Postgres: всегда задавай statement timeout.

ALTER DATABASE mydatabase
SET statement_timeout = '60s';

👉 @SQLPortal

Redis — возможно, одно из крупнейших предательств в истории Open Source

В 2009 году итальянский разработчик Сальваторе Санфилиппо работал над стартапом, но MySQL оказался слишком медленным. В свободное время он создал собственную in-memory базу данных и бесплатно выложил её в открытый доступ.

Так появился Redis.

Его использовали Twitter, GitHub, Snapchat, Stack Overflow. Практически каждая крупная технологическая компания так или иначе внедрила Redis в свою инфраструктуру.
К 2020 году Сальваторе выгорел после 11 лет практически единоличной поддержки проекта. Он передал его компании Redis Labs и отошёл от разработки.

А затем, в марте 2024 года, Redis Labs изменила лицензию. Redis перестал быть Open Source в привычном понимании. Облачные провайдеры больше не могли свободно предлагать его в качестве управляемого сервиса без коммерческих соглашений с Redis Labs.

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

Всего через восемь дней Linux Foundation объявила о создании Valkey — форка Redis с открытой лицензией. Проект поддержали AWS, Google, Oracle, Ericsson и Snap. В течение нескольких недель к инициативе присоединились более 50 компаний.

Вскоре Fedora, Ubuntu, Debian и Arch начали отказываться от Redis в пользу Valkey. AWS перевела миллионы узлов на новую реализацию. Valkey достиг производительности 1,19 млн запросов в секунду — согласно приведённым в публикации данным, это на 230% быстрее версии Redis, от которой отказались.

Затем Redis попыталась вернуть доверие сообщества, снова привлекая Сальваторе к проекту. Он вернулся, выступал на Hacker News в защиту изменения лицензии и пытался восстановить доверие разработчиков.

Но сообщество уже начало двигаться дальше без него. Redis строил доверие Open Source 15 лет. Одно изменение лицензии — и всего за восемь дней потерял значительную часть этого доверия.

В мире Open Source сообщество — это не просто пользователи. Сообщество — главное конкурентное преимущество проекта.

👉 @SQLPortal

SQL MASTER TREE

Большая карта SQL, которая охватывает практически всё, что нужно знать разработчику или аналитику при работе с базами данных.

👉 @SQLPortal

Что такое SQL: базы данных, таблицы и реляционные концепции

👉 @SQLPortal

Вопрос с собеседования в Amazon по SQL

Что не так с этим SQL-запросом?

👉 @SQLPortal

Spring Boot API отвечает тайм-аутами, а PostgreSQL выглядит здоровым?

CPU в норме, медленных запросов нет. Причина может быть в исчерпании пула соединений HikariCP. Когда все соединения заняты, новые запросы ждут освобождения одного из них. Если время ожидания превышает connectionTimeout, получение соединения завершается ошибкой.

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

В статье разбираются:

• Причины исчерпания пула.
• Влияние долгих транзакций.
• Диагностика по метрикам HikariCP.
• Практические способы устранения проблемы.

Читать статью

👉 @SQLPortal

Дорожная карта изучения SQL

👉 @SQLPortal

Сохраняете данные в БД и публикуете событие в рамках одного запроса?

В таком случае вы рискуете столкнуться с проблемой Dual Write — когда одна операция успешно выполняется, а другая завершается ошибкой.

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

Решение — Transactional Outbox Pattern.

Этот паттерн позволяет атомарно сохранить бизнес-данные и событие в одной транзакции БД. Отдельный процесс затем забирает событие из Outbox и публикует его в брокер сообщений.

Главное преимущество — гарантированная согласованность записи в БД и события, а также доставка по модели at-least-once.

Важно: потребители должны быть готовы к повторной доставке событий и обрабатывать дубликаты.

👉 @SQLPortal

В каком порядке SQL выполняет запросы?
SQL-запрос выполняется не совсем в том порядке, в котором написаны его инструкции.

Логический порядок обработки запроса:

FROM и JOIN — определение источников данных и объединение таблиц.
WHERE — фильтрация строк.
GROUP BY — группировка данных.
HAVING — фильтрация полученных групп.
SELECT — выбор столбцов и вычисление выражений.
ORDER BY — сортировка результата.
LIMIT и OFFSET — ограничение количества возвращаемых строк и пропуск записей.

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

👉 @SQLPortal

SQL-запросы выполняются не в том порядке, в котором написаны.

Понимание того, как работают FROM, WHERE, GROUP BY, HAVING, SELECT и ORDER BY, помогает писать более качественные запросы, находить ошибки и оптимизировать производительность.

👉 @SQLPortal

Sharding, Partitioning и Replication: в чём разница?

В системном дизайне эти три понятия часто путают, хотя каждое решает свою задачу.

1. Partitioning (партиционирование)
Разделение большой таблицы на более мелкие части. Это помогает оптимизировать выполнение запросов и упростить управление данными.

2. Sharding (шардирование)
Распределение частей данных между несколькими серверами. Позволяет масштабировать хранилище и увеличить пропускную способность операций записи.

3. Replication (репликация)
Создание копий данных на нескольких серверах. Повышает доступность системы и позволяет распределять нагрузку на чтение.

Как запомнить разницу:

• Partitioning = разделить данные.
• Sharding = распределить данные.
• Replication = скопировать данные.

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

👉 @SQLPortal

Совет для SQL в production:

column = NULL работает не так, как многие разработчики ожидают.

Используйте:

column IS NULL

NULL означает неизвестное или отсутствующее значение, а не обычное значение, которое можно сравнивать с помощью =.

👉 @SQLPortal

Это лучшая статья про MVCC в MySQL, что я читал.

MySQL и Postgres используют разные инженерные подходы для решения одной и той же задачи: undo log против нескольких версий кортежей.

Ещё одна отличная работа от Jeremy Cole.

👉 @SQLPortal

WHERE vs HAVING в SQL: знаете разницу?

WHERE фильтрует отдельные строки до группировки, а HAVING — группы после выполнения агрегации.

Понимание разницы между ними помогает писать корректные SQL-запросы и решать реальные бизнес-задачи.

👉 @SQLPortal

Вы создали индекс для таблицы базы данных. Но запрос всё равно выполняется медленно.

Проверяете план выполнения и обнаруживаете, что PostgreSQL не использует индекс. Вот нюанс, который разработчики часто упускают из виду.

Рассмотрим такой индекс:

CREATE INDEX idx_orders ON orders (customer_id, status, created_at);

А теперь запрос:

SELECT * FROM orders WHERE status = 'PENDING';

Индекс начинается с customer_id, а запрос фильтрует данные только по status.

В зависимости от данных и выбранного плана выполнения PostgreSQL может не суметь эффективно использовать такой индекс для этого условия.

Порядок столбцов в составном индексе имеет значение.

Индекс — это не просто набор столбцов. Их порядок может определять, насколько эффективно база данных сможет использовать индекс.

Не спрашивайте только, существует ли индекс. Проверяйте, соответствует ли его структура шаблонам ваших запросов.

👉 @SQLPortal

18 практических работ по DevOps

Docker, Kubernetes, CI/CD, Terraform, Ansible, Helm, GitOps, мониторинг через Prometheus и Grafana, а также управление секретами и progressive delivery. Курс рассчитан на 16 недель.

В финале у вас будет не просто набор выполненных заданий, а собственный кластер с автоматизированным развёртыванием и мониторингом.

👉 @SQLPortal

Ловушка оператора NOT IN при использовании подзапросов в SQL

Оператор NOT IN может неожиданно повести себя при работе со значениями NULL. Если подзапрос возвращает хотя бы одно значение NULL, основной запрос может не вернуть ни одной строки.

Простой пример:

SELECT employee_name
FROM safety
WHERE id NOT IN (
    SELECT days_lost
    FROM safety
);

Если в столбце days_lost есть хотя бы один NULL, результат сравнения через NOT IN может стать UNKNOWN, а не TRUE или FALSE.

Поскольку WHERE возвращает только строки, для которых условие равно TRUE, результатом может оказаться пустая выборка.

Как избежать этой проблемы?

Исключите NULL из подзапроса:

SELECT employee_name
FROM safety
WHERE id NOT IN (
    SELECT days_lost
    FROM safety
    WHERE days_lost IS NOT NULL
);

Добавив IS NOT NULL, вы не позволяете значениям NULL влиять на сравнение. Простое, но эффективное решение!

👉 @SQLPortal