Системный дизайн: База данных

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

- один для обработки веб- и мобильного трафика — веб-уровень (web tier);
- другой для базы данных — уровень данных (data tier).

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

Какую базу данных использовать?

Можно выбрать между традиционной реляционной базой данных — RDBMS, или SQL-базой данных — и нереляционной базой данных — NoSQL.

Реляционные базы данных представляют и хранят данные в виде таблиц и строк. С помощью SQL можно выполнять операции JOIN между различными таблицами базы данных.

Нереляционная база данных может быть подходящим выбором, если:

- приложению требуется сверхнизкая задержка;
- данные неструктурированы или не имеют связей;
- требуется только сериализация и десериализация данных — JSON, YAML и т. д.;
- необходимо хранить огромные объёмы данных.

👉 @SQLPortal

Немного разобрался с тем, как работают блокировки в PostgreSQL. Главный вывод: разные SQL-команды захватывают разные режимы блокировок, и многие из них специально сделаны совместимыми друг с другом, чтобы минимизировать конкуренцию за блокировки.

Даже обычный SELECT захватывает блокировку, которая препятствует выполнению некоторых «тяжёлых» операций (например, VACUUM FULL, REINDEX и т. п.). Оказалось, существует удивительно много сочетаний SQL-команд, которые могут или не могут выполняться одновременно.

И ещё: вот отличный сайт, который наглядно показывает в виде графа, какие SQL-команды могут выполняться параллельно.

👉 @SQLPortal

Вопрос по SQL:

Что вернёт этот запрос?

👉 @SQLPortal

Избегать SQL — значит избегать настоящего бэкенда.

API меняются.
Фреймворки уходят в историю.
Базы данных переживают миграции, переписывания и смену стека.

Большинство проблем с производительностью на бэкенде возникают не из-за медленного кода приложения.

Обычно виноваты:

* плохие запросы;
* отсутствующие индексы;
* неудачная схема БД;
* слабая модель данных;
* неправильные паттерны чтения и записи.

Отсутствующий индекс не лечится микросервисами.

Дублирование данных не исправляется кэшем.

Медленные отчёты не ускоряются переписыванием API.

Если ты не понимаешь ACID, уровни изоляции, блокировки, дедлоки, индексы, партиционирование и планы выполнения запросов, рано или поздно система начнёт разваливаться под нагрузкой.

SQL — это не опция.

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

Изучи SQL.

Всё остальное строится поверх него.

👉 @SQLPortal

pg_cron — это расширение PostgreSQL, которое запускает задачи по расписанию прямо внутри базы, используя стандартный синтаксис cron. Если ты пишешь фоновые джобы, которые в основном сводятся к SQL-запросам, проще отдать это Postgres’у через pg_cron. Получается проще, стабильнее и без внешнего планировщика.

Настройка
В managed PostgreSQL (например, Crunchy Bridge и похожие провайдеры) pg_cron обычно уже доступен.
Если поднимаешь Postgres сам, ставишь пакет:

sudo apt install postgresql-18-cron

Дальше подключаешь расширение при старте сервера через postgresql.conf:

shared_preload_libraries = 'pg_cron'
cron.database_name = 'postgres'


shared_preload_libraries обязателен — без него расширение не загрузится.

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

Создание задач
Основная функция — cron.schedule. У неё несколько перегрузок, поведение зависит от количества аргументов.

Типичный вариант из трёх частей:
имя задачи
cron-расписание
SQL-команда

Пример:

SELECT cron.schedule(
  'nightly_vacuum',
  '0 3 * * *',
  'VACUUM ANALYZE big_table'
);

Управление и мониторинг
Список задач лежит в cron.job.

Там есть:
имя
расписание
SQL
активна ли задача

История запусков — cron.job_run_details.

Там видно:
время старта
длительность
успех или ошибка

Повторов при ошибке нет. Задача просто логируется и ждёт следующего запуска.

Частые кейсы
чистка старых логов
nightly VACUUM для горячих таблиц
агрегация метрик по часам
перенос старых строк в архив
обновление materialized views

Реже используемые сценарии
Иногда pg_cron используют не только для базы:
батчинг запросов к внешним API (в связке с http)
ETL-процессы и выгрузка в data warehouse (например, через pg_lake)
прогрев кэша через pg_prewarm перед пиками нагрузки

👉 @SQLPortal

БОЛЬШОЙ SQL-ГРЕХ

Использовать операторы NOT IN или IN, когда в данных присутствует NULL.

В SQL оператор IN — это сокращённая запись нескольких условий OR, а сравнение value = NULL всегда возвращает UNKNOWN. Из-за этого запрос может вернуть неожиданный результат или вообще пустую выборку.

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

Всегда тестируйте SQL-запросы с NULL, чтобы убедиться, что они работают так, как ожидается.

👉 @SQLPortal

Как импортировать большой dump mysql-dump.sql.gz размером более 10 ГБ?

gunzip < mysql-dump.sql.gz | mysql -u <user> -p <database>

Этот вариант работает медленно. Некоторые говорят, что подход на картинке быстрее. Так ли это?

Вопрос: как добавить SQL statements в начало и конец dump прямо во время выполнения импорта?

#MySQL #DBA Tips

👉 @SQLPortal

SQL number functions помогают очищать, вычислять и агрегировать числовые данные: округлять значения, задавать границы, находить остаток от деления, возводить числа в степень и сравнивать итоговые значения с помощью AVG, SUM, MIN и MAX.

👉 @SQLPortal

SQL-вопрос:

Что вернёт этот запрос?

👉 @SQLPortal

Бесплатная книга по Deep Learning

Один из самых лучших учебников по глубокому обучению теперь доступен бесплатно в онлайн-формате. Внутри вас ожидает материал по нейронным сетям, компьютерному зрению, Keras, Transformers, генеративному ИИ.

Каждый раздел здесь сопровождается практическими примерами, а сам код можно запускать прямо в браузере через Google Colab.

👉 @SQLPortal

Наткнулся на интересный кейс на Хабре — DBA с 15-летним опытом решил создать собственную систему мониторинга СУБД.

Так появился Lumen — инструмент для мониторинга SQL Server и PostgreSQL, вдохновлённый Spotlight for SQL Enterprise.

Он собирает данные о сессиях, блокировках, запросах, планах выполнения, памяти, дисках, бэкапах и репликации. Есть Playback для разбора прошлых инцидентов, 100 встроенных правил алертов и отдельный AI Operator на базе локальной LLM, который следит за состоянием серверов и помогает разбирать возникающие проблемы.

Выглядит как довольно интересный проект для DBA и тех, кто плотно работает с базами данных.

https://habr.com/ru/articles/1080080/

👉 @SQLPortal

SQL Debugging: вопрос с собеседования

Этот запрос должен возвращать всех клиентов, а также их отправленные заказы, если они есть.

Что с ним не так? Сработает ли такой запрос? Если нет, как его исправить?

👉 @SQLPortal