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

Эти 8 SQL-команд охватывают 90% повседневных запросов

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

👉 @SQLPortal

SQL-команды для анализа данных.

👉 @SQLPortal

Если вы работали с SQL или базами данных, то наверняка знаете: правильный запрос и правильные данные — это две совершенно разные вещи.

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

Представим простой вопрос: «Какую выручку мы получили за прошлый квартал?» В базе есть таблицы orders, invoices, payments и refunds.

Какие таблицы должен использовать агент? Какие столбцы определяют выручку? Нужно ли учитывать отменённые заказы? Как правильно объединить таблицы?

SQL-запрос может быть синтаксически корректным, но результат всё равно окажется неверным. Именно эту проблему пытается решить NVIDIA AutoOntology.

Это опенсорсный Python-фреймворк, который создаёт семантический слой поверх корпоративных баз данных. Он помогает ИИ-агентам понимать бизнес-понятия, столбцы таблиц, связи между ними и определения SQL-запросов.

Как это работает?

1. Определяет смысл структуры базы данных: AutoOntology анализирует метаданные базы, изучает столбцы, выявляет бизнес-понятия и определяет связи между таблицами. В результате формируется онтология, которая связывает понятия вроде «Клиент», «Заказ» и «Выручка» с соответствующими данными в базе.

2. Предоставляет агентам готовые определения вместо догадок: Для бизнес-метрик можно задать проверенные SQL-выражения, а связи между таблицами описать явно. Агенту больше не нужно каждый раз самостоятельно разбираться, как рассчитать выручку или объединить таблицы. Он может использовать уже подготовленные определения.

3. Добавляет проверку и сертификацию: Сгенерированная онтология — это отправная точка, а не абсолютная истина. Специалисты могут проверять и утверждать термины, описания и SQL-определения.

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

4. Передаёт контекст другим агентам: AutoOntology предоставляет возможности через API и MCP-сервер. Совместимые ИИ-агенты могут получать определения, проверять, можно ли ответить на вопрос, и выполнять запросы к данным.

В проекте используются PostgreSQL и pgvector для хранения каталога, онтологии и векторных представлений, FastAPI в качестве backend и настраиваемые языковые модели.

Зачем это разработчикам? Мы уже много внимания уделили тому, как улучшить рассуждения агентов, использование инструментов и поиск по документам. Но корпоративным ИИ-агентам также необходимо понимать смысл данных, с которыми они работают.

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

AutoOntology объединяет эти подходы, помогая делать работу ИИ-агентов с базами данных более обоснованной, последовательной и прозрачной.

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

https://github.com/NVIDIA/auto-ontology

👉 @SQLPortal

Проектирование баз данных (SQL и NoSQL)

Что такое проектирование баз данных? Проектирование баз данных — это процесс организации данных для эффективного хранения, поиска и управления ими. Он включает выбор подходящего типа базы данных (SQL или NoSQL), определение связей между данными и обеспечение их целостности.

SQL-базы данных (реляционные)

→ Хранят данные в структурированных таблицах со строками и столбцами.
→ Используют заранее определённую схему с фиксированной структурой.
→ Для запросов применяют SQL (Structured Query Language).
→ Обеспечивают соблюдение ACID-свойств: атомарность, согласованность, изоляцию и долговечность.

Примеры SQL-баз данных:

MySQL
PostgreSQL
Oracle Database
Microsoft SQL Server

Преимущества SQL:

→ Высокая согласованность данных.
→ Хорошо подходят для структурированных данных и сложных запросов.
→ Надёжная работа транзакций благодаря поддержке ACID.

Недостатки SQL:

→ Менее гибкие при работе с неструктурированными или часто меняющимися данными.
→ Горизонтальное масштабирование сложнее реализовать.

NoSQL-базы данных (нереляционные)

→ Хранят данные в гибких форматах: документах, парах «ключ — значение», широких столбцах или графах.
→ Используют схемы без жёсткой структуры или с динамической схемой.
→ Ориентированы на масштабируемость и высокую производительность.
→ Часто опираются на принципы BASE: преимущественная доступность, изменяемое состояние и eventual consistency (согласованность с течением времени).

Примеры NoSQL-баз данных:

MongoDB — документоориентированная.
Redis — хранилище «ключ — значение».
Cassandra — ширококолоночная.
Neo4j — графовая.

Преимущества NoSQL:

→ Высокая масштабируемость и скорость.
→ Гибкая схема для неструктурированных данных.
→ Хорошо подходят для Big Data и приложений реального времени.

Недостатки NoSQL:

→ Гарантии согласованности могут быть слабее, чем в SQL-базах.
→ Поддержка сложных запросов может быть ограничена.
SQL vs NoSQL
→ SQL: лучше подходит для структурированных данных и приложений, которым нужна высокая согласованность, например банковских систем.
→ NoSQL: подходит для неструктурированных и полуструктурированных данных, приложений реального времени и масштабных систем, например социальных сетей и IoT.

Примеры из реальной разработки

→ SQL: банковские системы, управление складскими запасами, ERP-системы.
→ NoSQL: платформы электронной коммерции, ленты социальных сетей, аналитика больших данных.

👉 @SQLPortal

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

Младшие разработчики спрашивают: «Какую базу данных выбрать?»

Старшие разработчики спрашивают: «Как будут перемещаться данные?»

Архитекторы спрашивают: «Что произойдёт, когда всё сломается?»

Несколько месяцев назад инженер из команды, которой я помогал, написал в чате обсуждения архитектуры: «Что выбрать для нового сервиса — Postgres или Mongo?»

Он один из самых сильных разработчиков, которых я знаю. И именно поэтому этот вопрос меня особенно расстроил.

Я терпеливый человек. Мне приходилось отвечать на него бесчисленное количество раз. Но это был уже третий сервис подряд, для которого команда выбирала базу данных ещё до того, как кто-нибудь описал хотя бы одну операцию чтения или записи.

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

Сейчас не 2006 год. На дворе 2026-й. Есть Managed Postgres, DynamoDB, Spanner, Cassandra, ClickHouse, Redis — всё доступно буквально в пару вызовов API.

Выбрать движок — самая простая часть. Тот, кто начинает с этого, пропускает самое сложное.

Ладно, хватит ворчать. Перейдём к вопросу, который он на самом деле хотел задать:

«Как выбрать базу данных, о которой я не пожалею через год?»

В целом любой выбор базы данных сводится к двум факторам.

Первый — нагрузка.

Как сервис читает и записывает данные? Каково соотношение чтения и записи в пиковые моменты? Преобладают точечные запросы по ключу, сканирование диапазонов или JOIN? Насколько устаревшие данные допустимы? Один регион или несколько?

Второй — команда.

Сможет ли дежурный инженер разобраться с этой базой в три часа ночи? Если никто в команде не умеет обслуживать «более продвинутую» базу, она автоматически становится более рискованным выбором.

Всё остальное — подбор движка под конкретные требования.

Вот как особенности нагрузки влияют на выбор:

Много операций записи → лог-структурированное хранение может быть эффективнее B-tree-индексов.
Сканирование диапазонов → хранилище с упорядоченными ключами лучше, чем система с хеш-разбиением.
Строгая согласованность → один ведущий узел с синхронной репликацией или алгоритм консенсуса.
Запись в нескольких регионах → разрешение конфликтов становится частью архитектуры.
Допустима высокая задержка актуализации данных → кеш может взять нагрузку на себя, и выбор основной базы становится менее критичным.

В следующий раз, когда кто-нибудь спросит: «Postgres или Mongo?»…

Не отвечайте. Спросите, как перемещаются данные.

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

👉 @SQLPortal

Один из самых интересных приёмов защиты данных, которые я встречал в production, — Temporal RLS.

Row-Level Security (RLS) — функция PostgreSQL, которая позволяет контролировать доступ пользователей к отдельным строкам таблицы непосредственно на уровне базы данных.

Вместо того чтобы полагаться на фильтрацию данных в коде приложения, RLS переносит контроль доступа внутрь самой БД.

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

Пример использования:

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

Вместо реализации логики в приложении или ограничений в BI-инструменте компания настроила всё непосредственно на уровне базы данных.

Как это работает?

Включаем RLS для таблицы.
Создаём политику, которая фильтрует строки.
Включаем FORCE ROW LEVEL SECURITY, чтобы даже владелец таблицы не мог обойти эти ограничения.

Даже если кто-то подключится к БД напрямую через psql, BI-инструмент или SQL-клиент, он увидит только записи старше 24 часов. Никаких исключений.

Преимущества:

Безопасность обеспечивается непосредственно на уровне источника данных.
Политики версионируются вместе с изменениями схемы.
Не требуется дополнительный код в приложении.

Вывод: RLS нужен не только для изоляции данных разных клиентов. С его помощью можно реализовать временные ограничения доступа, разграничение прав пользователей и даже контроль над мягким удалением записей.

И всё это — средствами самой базы данных. Какие необычные правила вы реализовывали с помощью RLS?

👉 @SQLPortal