Комментарии 7
зависимость стоимости в центах от конфигурации сервера и оптимизатора
Эти "центы" в случае использования BAO включают в себя затраты на работу нейросетки? Родной оптимизатор СУБД ведь явно дешевле с точки зрения требуемых ресурсов.
С временем исполнения оптимизированного запроса понятно:
совокупное время работы каждого оптимизатора в минутах, включая время на формирование плана, обучение и выполнение запросов
А с "центами" как?
В Bao GPU используется только во время обучения, которое происходит параллельно основной нагрузке. Для инференса подобных маленьких моделей (меньше 10МБ) вполне достаточно CPU, что в работе и демонстрируется. Конечно, есть простые запросы, на которых оверхед нейросети заметен, но в среднем, тем более на сложных запросах, Bao лучше.
Графики с центами и временем нужно рассматривать параллельно - соответствующая пара столбцов на каждую конфигурацию. Условно, для конфигурации на PostgreSQL n1-2 будет стоимость 70 центов и прогонка займёт 450 минут.
При создании модели планировщика можно учитывать текущую нагрузку сервера, как параметр? Например, при высокой нагрузке будут строится планы с учетом этой нагрузки (например, без parallel workers, так как они сейчас все заняты, или меньше памяти под какой-то вариант плана - это уже модель сама решит, что поменять). Чтобы модель не только умно планы создавала, но умно реагировала на нагрузку сервера
Можно, поскольку вектор входных признаков моделей открыт к расширению. Bao, например, уже допом может учитывать текущее состояние кэша, как в целом и все другие модели. В предыдущей статье уже размышлял о "произвольности" векторизации и возможности брать все, что посчитаете нужным для конкретной задачи. Вообще говоря, применение ML в динамически меняющихся средах вполне оправдано и будет работать примерно так, как вы и описали.
Есть ли сравнения с коммерческими оптимизаторами? Честно говоря, сравнения с Постгресом не вполне значимы, оптимизатор у него слабый, с ростом соединений на втором-третьем уровне дерева плана выполнения стабильные bad estimations.
P.S. Насколько я помню, например, на оптимизатор DB2 в середине-конце 1990-х в IBM работал фактически небольшой НИИ.
Да, в этой итерации методов сравнения производились с неназванной ComSys/CommDB, чтобы результаты бенчмарков не становились оружием в руках исследователей. Можно их видеть на рисунках 5, 6 и 7 для Bao (везде сверху PostgreSQL, а снизу ComSys). Аналогично для Balsa рисунок 10. Как можно видеть, там улучшение тоже есть, хоть и не такое значительное.
Нейронные оптимизаторы запросов в реляционных БД (Часть 2): На пути к продуктивизации