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