Доклад про то, почему тяжело автоматически оптимизировать БД всякими млями-шемелями. Спойлер: проблемы в основном организационные, мощных технических деталей нет.

Сами проблемы обозначены на 13 минуте (до этого идет слишком затянутое введение) и на 41-ой. Вкратце:

  • нет нормального препрода (слишком дорого),
  • тяжело воспроизводить проблемы,
  • нет связи с метриками самого приложения,
  • нужно знать неявные связи между несколькими БД (например, если другие БД используются для геошардирования или бэкапов),
  • тяжело сгенерировать тест производительности, соответствующий реальности,
  • хорошо бы автоматически игнорировать нерелевантную информацию при обучении модели
  • надо интегрироваться с другими инструментами (например, учитывать миграции, написанные программистами).

Ну еще с человеками тяжело взаимодействовать разумеется. Им надо добавить кнопку одобрения изменений с доказательствами полезности, показывать круглые числа с ноликами на конце, показывать “уровень здоровья” базы, чтобы у них была мотивация менять что-то, знать когда они кофе идут наливать и т.п.

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

Еще докладчик посетовал, что автонастройка RDS от AWS толком ничего полезного не делает.

В конце было хоть что-то связанное с МЛ — оказывается, если спросить совета у ChatGPT по настройке БД, то он мало чего путного посоветует (как неожиданно).