14500
Присоединяйтесь к нашему каналу и погрузитесь в мир баз данных Связь: @devmangx РКН: https://clck.ru/3H4Wo3
Очистка данных в SQL — это не только удаление дубликатов
Перед анализом данных важно привести их в порядок: исправить текстовые значения, обработать NULL, проверить типы данных, унифицировать категории, найти некорректные значения и провести проверки качества.
И главное правило: перед UPDATE или DELETE сначала проверь, какие строки попадут под изменение.
Чистые данные — основа корректной аналитики.
👉 @SQLPortal
SQL выполняет запросы не в том порядке, в котором ты их пишешь
Понимание логического порядка выполнения SQL-запроса помогает разобраться, как работают FROM, JOIN, WHERE, GROUP BY, HAVING, SELECT и ORDER BY.
Разберись, как SQL выбирает таблицы, фильтрует строки, группирует данные, применяет условия к группам и сортирует результат. Полезная шпаргалка для точного анализа данных и написания запросов.
👉 @SQLPortal
8 приёмов очистки данных в SQL
Работа с пропусками, удаление дубликатов, приведение текста к единому формату и проверка записей помогают подготовить данные к анализу.
Сохраняйте шпаргалку, чтобы меньше ошибок в данных попадало в ваши отчёты.
👉 @SQLPortal
Steampipe: SQL-запросы к облачной инфраструктуре
Какие ресурсы остались без обязательных тегов? Есть ли публично доступные S3-бакеты? В каких Kubernetes namespaces отсутствуют NetworkPolicies?
Для ответа необязательно переключаться между консолями и писать отдельные скрипты. Steampipe — open-source инструмент, который позволяет запрашивать данные из AWS, Kubernetes и других сервисов с помощью SQL.
Через плагины он обращается к API сервисов и представляет данные в виде таблиц. Можно фильтровать ресурсы, объединять результаты и проверять инфраструктуру привычными запросами.
Полезен для инвентаризации, поиска ошибок конфигурации и разовых проверок безопасности.
Руководство по Steampipe
👉 @SQLPortal
Бесплатная база по работе с данными
Книга создателя pandas с подробным разбором NumPy, pandas, очистки данных, визуализации и временных рядов. Весь материал сопровождается практическими примерами, исходники и датасеты доступны на GitHub.
https://wesmckinney.com/book/
👉 @SQLPortal
SQL или Python для анализа данных? Освойте оба.
SQL удобен для выборки, фильтрации, объединения и агрегации данных в БД. Python — для очистки, исследовательского анализа, автоматизации и сложных вычислений.
Эти инструменты дополняют друг друга: подготовьте выборку с помощью SQL, а затем исследуйте и визуализируйте её в Python.
👉 @SQLPortal
Аналитика данных строится на простом процессе:
Сначала данные извлекаются, преобразуются и загружаются с помощью ETL. Затем их обработка организуется в data pipelines (конвейеры данных), ошибки и неточности устраняются до начала анализа.
После этого с помощью Data Mining (интеллектуального анализа данных) в больших наборах данных выявляются закономерности, тенденции и полезные инсайты.
👉 @SQLPortal
SQL — это набор взаимосвязанных инструментов для работы с данными.
Запросы, JOIN, фильтрация, группировка, оконные функции, транзакции, управление доступом и структурой БД помогают решать разные части одной задачи.
Когда понимаешь, как они связаны, SQL становится понятной системой, а не набором команд для заучивания.
👉 @SQLPortal
SQL и DAX: одни данные, разные задачи
• SQL помогает извлекать, фильтровать, объединять и агрегировать данные в базе. Подходит для подготовки наборов данных и расчётов на стороне СУБД.
• DAX используется для вычислений в табличных моделях, например в Power BI. Меры учитывают контекст фильтрации и пересчитываются при выборе срезов и элементов отчёта.
SQL готовит данные, DAX помогает анализировать их интерактивно. Это полезный ориентир, хотя возможности обоих языков шире и частично пересекаются.
👉 @SQLPortal
Excel, Python или SQL: что выбрать для работы с данными?
Задачи часто одинаковые: фильтрация, сортировка, агрегация, обработка пропусков, вычисления и объединение таблиц. Отличаются инструменты и способ решения.
• Excel — для работы с таблицами вручную, формул и быстрого анализа.
• Python с pandas — для автоматизации, сложных преобразований и обработки данных из разных источников.
• SQL — для выборки, объединения и агрегации данных прямо в базе.
Сравните одни и те же операции в трёх инструментах: так проще увидеть общую логику и переносить навыки между ними.
👉 @SQLPortal
Практические уроки для Backend, Data Engineering и DevOps
Площадка с пошаговыми туториалами и облачными окружениями. Изучаем теорию и сразу выполняем команды без настройки локальной среды. В каталоге PostgreSQL, Redis, Docker, Kubernetes, Airflow, Spark и ClickHouse.
https://prepare.sh/
👉 @SQLPortal
Git пригодится и тем, кто пишет SQL
Храните запросы, миграции и схемы БД в репозитории: так проще отслеживать изменения, возвращаться к предыдущим версиям и обсуждать правки с командой.
В шпаргалке — базовые команды: создание репозитория, коммиты, ветки, слияние, stash и работа с удалённым репозиторием. Сохраните для работы над SQL-проектами.
👉 @SQLPortal
Числовые функции SQL: от округления до итогов 🔢
Они помогают обрабатывать числа и выполнять вычисления:
• ROUND — округлить до нужного количества знаков.
• CEIL / CEILING и FLOOR — округлить вверх или вниз до целого.
• ABS — получить модуль числа.
• MOD или % — найти остаток от деления.
• POWER — возвести число в степень.
Агрегатные функции обобщают данные: AVG вычисляет среднее, SUM — сумму, MIN и MAX — минимальное и максимальное значения. Названия и синтаксис отдельных функций зависят от СУБД.
👉 @SQLPortal
SQL помогает получить данные. Статистика — понять, что они означают
20 статистических понятий для работы с отчётами, метриками и аналитическими запросами.
👉 @SQLPortal
Pandas: Python для повседневных задач аналитика 🐼
Загрузить файлы с неаккуратными данными, изучить их структуру, очистить столбцы, сгруппировать результаты и объединить наборы данных — всё это можно сделать с Pandas.
Библиотека помогает подготовить данные для отчётов и машинного обучения, а также получить первые аналитические выводы.
👉 @SQLPortal
Amazon RDS: как AWS управляет реляционными базами данных
В production недостаточно просто хранить данные. Нужно настраивать резервное копирование, устанавливать обновления, масштабировать ресурсы, следить за производительностью и обеспечивать отказоустойчивость.
Amazon RDS (Relational Database Service) — управляемый сервис AWS, который упрощает развёртывание и обслуживание реляционных баз данных. AWS берёт на себя значительную часть инфраструктурных задач, а разработчики могут сосредоточиться на приложении и данных.
RDS поддерживает несколько популярных СУБД:
• Amazon Aurora
• PostgreSQL
• MySQL
• MariaDB
• Oracle Database
• Microsoft SQL Server
Как это работает?
• Выбираете движок базы данных.
• Настраиваете вычислительные ресурсы и хранилище.
• Настраиваете сеть через Amazon VPC.
• Задаёте учётные данные и параметры безопасности.
• Создаёте экземпляр базы данных.
• Подключаете приложение.
• RDS помогает автоматизировать многие задачи обслуживания.
Ключевые возможности RDS
• Резервное копирование. Автоматическое создание бэкапов и восстановление данных в пределах настроенных возможностей хранения резервных копий.
• Обновления. Установка поддерживаемых обновлений СУБД в соответствии с настройками обслуживания.
• Отказоустойчивость. В конфигурации Multi-AZ база может иметь резервный экземпляр в другой зоне доступности. При сбое основного экземпляра сервис поддерживает автоматическое переключение на резервный.
• Масштабирование. Можно изменять вычислительные ресурсы и объём хранилища по мере роста нагрузки.
• Мониторинг. Интеграция с Amazon CloudWatch позволяет отслеживать производительность и использование ресурсов.
RDS и Aurora — в чём разница? Amazon Aurora — облачная реляционная СУБД, доступная через Amazon RDS. Она совместима с PostgreSQL и MySQL и разработана с учётом особенностей инфраструктуры AWS.
Безопасность
Для защиты баз данных используются:
• Изоляция сети через Amazon VPC.
• Security Groups для контроля сетевого доступа.
• Интеграция с IAM для поддерживаемых сценариев.
• Шифрование данных при хранении и передаче.
• Аутентификация и разграничение прав доступа.
Главный принцип — выдавать минимально необходимые права и по возможности не открывать базу данных напрямую в публичный интернет.
Где используют Amazon RDS? Веб-приложения, интернет-магазины, SaaS-платформы, корпоративные системы, backend API и приложения с транзакционными нагрузками.
Главное преимущество RDS — возможность использовать привычные реляционные базы данных, не управляя вручную всей инфраструктурой и значительной частью рутинных операций обслуживания.
👉 @SQLPortal
SQL, Python и PySpark: 50 операций с данными в сравнении
Фильтрация, JOIN, агрегации, оконные функции и преобразования данных — посмотрите, как одни и те же задачи решаются в трёх технологиях.
Сохраняйте шпаргалку, чтобы быстрее находить знакомые операции при переходе между инструментами.
👉 @SQLPortal
Партиционирование и шардинг: в чём разница?
Оба подхода делят данные на части, но решают разные задачи. Партиционирование — разделение одной логической таблицы на секции. В типичном случае они находятся в одной СУБД и используют ресурсы одного сервера.
Основные способы:
• Range — по диапазонам, например заказы по годам.
• List — по заданным значениям, например регионам US, EU и APAC.
• Hash — по хешу ключа распределения.
Если условия запроса позволяют, СУБД исключает ненужные секции из обработки — это называется partition pruning. Вместо всей таблицы читается только подходящая часть.
Партиционирование упрощает обслуживание, загрузку и удаление старых данных. Но ускорение зависит от запросов и ключа разбиения: само по себе оно не делает любой запрос быстрее. Устройство индексов тоже зависит от СУБД: они могут быть локальными или глобальными.
Шардинг — распределение данных между несколькими узлами или базами. Каждый шард использует собственные вычислительные ресурсы и хранилище. Например, клиентов распределяют по хешу customer_id. Приложение, прокси или сама распределённая СУБД определяет, куда отправить запрос. Если ключ шарда неизвестен, может потребоваться обращение к нескольким шардам.
Шардинг позволяет распределить нагрузку и объём данных, но усложняет:
• JOIN между шардами;
• транзакции, затрагивающие несколько узлов;
• перераспределение данных;
• борьбу с перегруженными шардами;
• маршрутизацию и эксплуатацию.
Эти подходы можно сочетать: таблицы внутри каждого шарда тоже могут быть партиционированы.
Обязательной цепочки «одна БД → партиции → реплики → шардинг» нет. Решение выбирают по узкому месту: объёму данных, нагрузке на чтение и запись, требованиям к задержкам и обслуживанию.
👉 @SQLPortal
Большая коллекция из практических рекомендаций по защите приложений. Внутри: SQL Injection, XSS, JWT, OAuth2, Kubernetes, Docker, API Security, а теперь ещё и безопасность агентов MCP и RAG.
https://cheatsheetseries.owasp.org
👉 @SQLPortal
Что происходит между GET /users/123 и ответом API?
Несколько сотен миллисекунд могут включать установку соединения, балансировку нагрузки, проверку авторизации, обращение к кэшу и базе данных. Код контроллера занимает лишь часть этого времени.
В статье разобран путь запроса в приложении на Spring Boot:
• DNS и TLS.
• Балансировка нагрузки.
• Spring Security и JWT.
• Попадание и промах кэша Redis.
• Ожидание соединения из пула.
• Запросы к PostgreSQL.
• Взаимодействие с Kafka.
• Источники задержек на каждом этапе.
Не каждый запрос проходит все эти шаги: соединение может переиспользоваться, кэш — исключить обращение к БД, а Kafka участвует только там, где это предусмотрено логикой приложения.
vishipatil/what-actually-happens-when-you-call-a-rest-api-12a0f6d3fbc8">Читать на Medium
👉 @SQLPortal
Кэш ускоряет приложение, но ошибки в кэшировании снижают его надёжность.
Частые антипаттерны:
• Кэшировать всё подряд. Выбирайте часто запрашиваемые данные и заранее определяйте, насколько устаревшими они могут быть.
• Не задавать TTL. Без срока действия или надёжной инвалидации устаревшие значения могут оставаться в кэше неограниченно долго.
• Обновлять БД и кэш без согласованной стратегии. Одна запись проходит, другая падает — данные расходятся. Продумайте порядок обновления, инвалидацию и обработку сбоев: write-through и write-behind сами по себе не гарантируют согласованность.
• Не учитывать отказ кэша. Предусмотрите резервный сценарий. Но помните: переключение всего трафика на БД может перегрузить её — нужны ограничения нагрузки.
• Не планировать инвалидацию. Заранее решите, когда удалять или обновлять записи и как распространять изменения между экземплярами приложения.
В архитектуре, где БД — источник истины, кэш должен ускорять доступ к данным, а не определять их корректность.
👉 @SQLPortal
SQL, Pandas и Power BI: 10 операций для работы с данными
Фильтрация, объединение таблиц, ранжирование и накопительные итоги — одни и те же задачи можно решать разными инструментами.
Сравните подходы, чтобы понять общую логику операций и легче переключаться между SQL, Pandas и Power BI.
👉 @SQLPortal
SQL начинается с SELECT, но логика запроса — с FROM
Логический порядок обработки запроса:
• FROM / JOIN — определить источники и объединить таблицы.
• WHERE — отфильтровать строки.
• GROUP BY — сформировать группы.
• HAVING — отфильтровать группы.
• SELECT — вычислить выражения и выбрать столбцы.
• DISTINCT — убрать дубликаты, если указан.
• ORDER BY — отсортировать результат.
• LIMIT / OFFSET — ограничить выдачу и пропустить строки.
Поэтому псевдоним из SELECT обычно доступен в ORDER BY, но не в WHERE: на этапе фильтрации он ещё не определён.
Это логический порядок, а не физический план выполнения. Оптимизатор может обрабатывать данные иначе, сохраняя смысл запроса.
👉 @SQLPortal
Из Excel в Python: знакомые задачи с pandas 🐼
Фильтрация, сортировка, группировка и объединение таблиц — всё, что вы делаете в Excel, можно выполнять и в pandas.
• Фильтры → отбор строк по условиям.
• Сортировка → sort_values().
• Группировка и итоги → groupby() и agg().
• Сводные таблицы → pivot_table().
• Поиск соответствий между таблицами → merge().
• Работа с пропусками → isna(), fillna() и dropna().
Знакомая логика помогает освоиться, а код позволяет автоматизировать обработку и повторять её на новых данных.
👉 @SQLPortal
Масштабирование базы данных: 6 подходов, которые стоит знать
Рост данных и трафика требует разных решений. Прежде чем масштабировать базу, определите, что ограничивает производительность: CPU, память, диски, запросы или количество соединений.
• Вертикальное масштабирование — добавить серверу CPU, RAM и более быстрые диски.
• Реплики для чтения — распределить запросы на чтение между копиями базы, учитывая задержку репликации.
• Шардинг — распределить данные между несколькими узлами.
• Партиционирование — разделить большую таблицу на части, чтобы упростить обслуживание и ускорить подходящие запросы.
• Кэширование — сократить повторные обращения к базе.
• Пул соединений — переиспользовать подключения и ограничивать их количество.
У каждого подхода свои ограничения и цена сложности. Выбирайте по измерениям и характеру нагрузки. Сохраните шпаргалку для работы и подготовки к собеседованию по System Design.
👉 @SQLPortal
SQL проще изучать, если разделить его по задачам
• Определять структуру таблиц: CREATE, ALTER, DROP.
• Получать данные: SELECT, WHERE, ORDER BY.
• Добавлять, изменять и удалять записи: INSERT, UPDATE, DELETE.
• Управлять доступом: GRANT, REVOKE.
• Управлять транзакциями: BEGIN, COMMIT, ROLLBACK.
• Объединять таблицы: JOIN.
Считать итоги: GROUP BY, COUNT, SUM, AVG, MIN, MAX.
Начните с конкретной задачи — так проще понять, какие конструкции нужны и как они работают вместе.
👉 @SQLPortal
Дубликаты в SQL: способ зависит от задачи
• DISTINCT убирает повторяющиеся сочетания выбранных столбцов из результата запроса.
• GROUP BY объединяет строки в группы и позволяет посчитать повторы через COUNT(*).
• ROW_NUMBER() нумерует строки внутри группы, чтобы выбрать, какую запись оставить.
Убрать повторы из выдачи и удалить записи из таблицы — разные задачи. Перед DELETE проверьте выборку удаляемых строк и сделайте резервную копию.
👉 @SQLPortal
Быстрый SQL начинается с продуманных запросов
1. Выбирайте только нужные столбцы. Вместо SELECT * перечисляйте поля: это уменьшает объём передаваемых данных.
2. Создавайте подходящие индексы. Учитывайте столбцы, используемые в WHERE, JOIN и ORDER BY.
3. Избегайте функций над индексируемыми столбцами в условиях. Вместо YEAR(date) = 2024 используйте диапазон дат — он может позволить использовать обычный индекс.
4. Используйте EXISTS для проверки существования строк. Но не считайте его всегда быстрее IN: сравнивайте планы выполнения.
5. Ограничивайте выдачу через LIMIT или TOP. Это сокращает результат, но не обязательно объём работы базы данных.
6. Сравнивайте JOIN и подзапросы. Выбирайте вариант с нужной семантикой и лучшим планом: объединение не всегда быстрее и может размножать строки.
7. Отсекайте ненужные строки через WHERE. Чем меньше данных обрабатывается дальше, тем лучше; фактический порядок операций определяет оптимизатор.
8. Не используйте DISTINCT без необходимости. Удаление дубликатов требует ресурсов. Проверьте, не возникают ли они из-за ошибочного объединения.
9. Выбирайте UNION ALL, если удалять дубликаты не нужно. В отличие от UNION, он сохраняет все строки и не тратит ресурсы на устранение повторов.
10. Анализируйте планы выполнения. Используйте EXPLAIN и, где доступно, EXPLAIN ANALYZE, чтобы находить узкие места. Помните: EXPLAIN ANALYZE действительно выполняет запрос.
👉 @SQLPortal
Команды SQL проще запомнить по назначению
• DDL — создание и изменение структуры БД: CREATE, ALTER, DROP.
• DML — добавление, изменение и удаление данных: INSERT, UPDATE, DELETE.
• DCL — управление правами доступа: GRANT, REVOKE.
• TCL — управление транзакциями: COMMIT, ROLLBACK, SAVEPOINT.
• DQL — получение данных: SELECT.
В некоторых классификациях SELECT относят к DML, не выделяя DQL отдельно.
👉 @SQLPortal
Чтобы запросы оставались быстрыми, понятными и справлялись с ростом объёма данных, нужны хорошие привычки при их написании.
Вот 15 принципов, которые стоит применять на практике:
1. Избегайте SELECT *: выбирайте только нужные столбцы.
2. Отфильтровывайте ненужные строки с помощью WHERE.
3. Понимайте разницу между INNER JOIN и LEFT JOIN.
4. Используйте CTE вместо громоздких подзапросов для улучшения читаемости.
5. Не маскируйте ошибки логики лишним DISTINCT.
6. Используйте UNION ALL, если удалять дубликаты не требуется.
7. Освойте оконные функции для сложных расчётов.
8. Согласовывайте типы данных, чтобы избежать неявных преобразований.
9. Сравнивайте планы для EXISTS и IN: первый не всегда быстрее.
10. Убирайте ORDER BY, если сортировка не нужна.
11. Используйте CROSS JOIN только когда действительно нужно декартово произведение.
12. Учитывайте, что функции над индексированными столбцами могут мешать использованию обычного индекса.
13. Используйте CASE для понятной условной логики.
14. Изучайте план выполнения через EXPLAIN; помните, что EXPLAIN ANALYZE действительно выполняет запрос.
15. Проверяйте корректность на небольших наборах данных, а производительность — на объёмах, близких к реальным.
👉 @SQLPortal