Комментарии 9
А вот это интересно
Первый вопрос, сколько понадобится ядер, чтобы оптимизация плана работало с приемлемой скоростью в реальном времени? Промышленная СУБД может обслуживать тысячи запросов в секунду на нескольких ядрах.
Скорее всего это может быть background process, который идёт по уже построенным планам, которые используются наиболее часто
В этой статье рассмотрены пионеры области, что отметил в заключении. Поэтому думать о серьёзном внедрении таких решений в прод я бы не стал. По скорости работы на единичных запросах стандартные оптимизаторы проигрывают нейросетевым. Однако в реальности есть много динамики - данные и структура БД постоянно меняются, частые запросы кэшируются, индексы перестраиваются и т.д. и т.п. В этих условиях нейросетям становится плохо и решение всех этих проблем - предмет следующих статей. Там уже будут показаны модели, протестированные в боевых условиях, которые либо сравниваются, либо превосходят существующие оптимизаторы по скорости и качеству работы на одном и том же железе.
Видимо, я недостаточно точно задал вопрос. Откинем пока условия промышленной эксплуатации, инфраструктуру и вопросы динамики.
Допустим есть пакет запросов и статическая БД заданного объема. На условном SQL Server elapsed time и CPU time будут такими-то на N ядрах. Сколько потребуется ядер, чтобы достигнуть того же результата по времени на нейросети?
Для DQ, относительно сложной RL-модели, используют 32 ядра при сравнении стандартного и нейросетевого оптимизатора.
В других моделях чётко не указывали результаты эксперимента в связи с изменением количества ядер, что на самом деле является интересным вопросом. Могу, исходя из опыта, предположить, что в связи с небольшой способностью параллелиться на CPU, маленькие нейросети будут сравнительно эффективнее отрабатывать на небольших мощностях, порядка 8 ядер. Скорость инференса растёт нелинейно, следовательно, может быть момент, когда очередное добавленное CPU позволит перебрать варианты быстрее и получить лучший результат с использованием обычных оптимизаторов. Однако, это утверждение нужно проверять.
Видимо, в этом основная проблема, подход слишком ресурсозатратный. Для сравнения, 2005 год, SQL Server на физических 8 ядрах обслуживает запросы от 1500 пользователей онлайн с приемлемым качеством (небольшой процент плохих планов корректируется руками). Каждое ядро лицензируется и обходится примерно в $3-5К. Если сюда добавить 32 ядра для небольшого улучшения оптимизации, то цена решения может стать неприемлемой.
Нейронные оптимизаторы запросов в реляционных БД (Часть 1)