Комментарии 4
зависимость стоимости в центах от конфигурации сервера и оптимизатора
Эти "центы" в случае использования BAO включают в себя затраты на работу нейросетки? Родной оптимизатор СУБД ведь явно дешевле с точки зрения требуемых ресурсов.
С временем исполнения оптимизированного запроса понятно:
совокупное время работы каждого оптимизатора в минутах, включая время на формирование плана, обучение и выполнение запросов
А с "центами" как?
В Bao GPU используется только во время обучения, которое происходит параллельно основной нагрузке. Для инференса подобных маленьких моделей (меньше 10МБ) вполне достаточно CPU, что в работе и демонстрируется. Конечно, есть простые запросы, на которых оверхед нейросети заметен, но в среднем, тем более на сложных запросах, Bao лучше.
Графики с центами и временем нужно рассматривать параллельно - соответствующая пара столбцов на каждую конфигурацию. Условно, для конфигурации на PostgreSQL n1-2 будет стоимость 70 центов и прогонка займёт 450 минут.
При создании модели планировщика можно учитывать текущую нагрузку сервера, как параметр? Например, при высокой нагрузке будут строится планы с учетом этой нагрузки (например, без parallel workers, так как они сейчас все заняты, или меньше памяти под какой-то вариант плана - это уже модель сама решит, что поменять). Чтобы модель не только умно планы создавала, но умно реагировала на нагрузку сервера
Можно, поскольку вектор входных признаков моделей открыт к расширению. Bao, например, уже допом может учитывать текущее состояние кэша, как в целом и все другие модели. В предыдущей статье уже размышлял о "произвольности" векторизации и возможности брать все, что посчитаете нужным для конкретной задачи. Вообще говоря, применение ML в динамически меняющихся средах вполне оправдано и будет работать примерно так, как вы и описали.
Нейронные оптимизаторы запросов в реляционных БД (Часть 2): На пути к продуктивизации