Полное описание

Проблематика

Основная проблема заключается в отсутствии инструмента для проактивного контроля SQL-запросов к PostgreSQL, что приводит к критическим сбоям в работе баз данных:

1. Отсутствие средств автоматизированных рекомендаций по оптимизации запросов и структуры БД, что увеличивает время устранения проблем и накладывает зависимость от экспертных знаний.

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

Образ решения

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

o Предоставить возможность сравнения оценок «стоимостей» запросов до и после применения рекомендаций без реального выполнения запросов и изменения структуры базы данных.

o Прогнозирование ресурсоемкости запросов с детализацией по ключевым метрикам

o Генерация рекомендаций по оптимизации запросов и конфигурации PostgreSQL

o Предупреждение о потенциально опасных операциях в режиме реального времени

Функциональные требования

o Оценка «стоимости» запроса до выполнения

§ Анализ плана выполнения (EXPLAIN) без запуска запроса для прогнозирования времени, I/O и использования памяти.

§ Отображение метрик: ожидаемое время выполнения, объем сканируемых данных, уровень блокировок.

o Рекомендации по оптимизации

§ Для SQL-запросов: предложения по добавлению/изменению индексов, переписыванию текста запроса, устранению N+1 проблем.

§ Для БД: рекомендации по настройке параметров, например, work_mem, тюнинг autovacuum’а, секционирование таблиц, изменение структуры таблиц, дефрагментация таблиц и индексов.

§ Классификация рекомендаций по приоритету (высокий/средний/низкий) с оценкой потенциального ускорения.

o Предотвращение проблем с производительностью

§ Интеграция с CI/CD для анализа запросов на этапе разработки.

§ Выявление шаблонов проблемных запросов и формирование профилактических мер.

Дополнительные требования**

Рекомендации по работе с платформой**

FAQ по работе с платформой**

Формат загрузки решения**

Решение должно быть представлено на платформу не позднее __________ в следующем виде:

10. Ссылка на исходный код в VCS (системе контроля версий - GitHub, GitLab, Mercury или иные)

11. Ссылка на облачный диск (Яндекс, Google), где загружены:

a. Архив с исходным кодом проекта

b. Видео-демо работы проекта (видео, показывающее процесс работы вашего решения, с комментариями или без них, не длиннее 2 минут)

12. Ссылка на презентацию вашего проекта (облачный диск с файлом .pptx/.pdf или развернутая презентация на YouNote, Figma или иных сервисах)

13. Ссылка на ваше развернутое решение (при наличии) для его тестирования членами жюри.

Доп варианты загрузки

Основной процесс просмотра решения - прямо на выделенных машинах участников

Оптимальный состав команды**

o 1 Аналитик (DBA)

o 1 DBO

o 1 Backend-разработчик

o 1 DevRel*

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

Ограничения**

§ Используется ванильный (vanilla) PostgreSQL

§ Допускается расширение pg_stat_statements, другие расширения не допускаются

§ Итоговое решение должно работать на версиях PostgreSQL, начиная от 15 и выше

§ Решение должно работать под учетной записью с правами только на чтение. Выдача прав суперпользователя не предусмотрена.

Необходимые данные, дополнения, пояснения, уточнения от кейсодержателя

Не предоставлены.

Желаем удачи!

Ссылка на сайт Хакатон:

https://habr.com/ru/companies/vtb/news/935960/

Я в нем не могу участвовать. Я один из тех кто будет принимать ваши решения.

Если непонятна суть вопроса - разьясню. И вот за этот пустячок вам дадут 500 тыр.)

Имеет. Я даже примерно знаю как это решить. Но нам нельзя участвовать.так как организаторы.

Сегодня открытие Хакатона. Был на съёмках.