Комментарии 3
Как интересно :) Не будем изучать детали, рассмотрим бэкенд как черный ящик :) Даже в случае сравнительно "простых" запросов SQL существуют некие размеры выборок, после которых план катастрофически портится и появляется в общем-то ненужный фуллскан, которого более или менее опытный специалист может избежать. Подобные оптимизационные мероприятия сильно зависят от контекста (то бишь предметной области, количеств сущностей в ней и т.п.). Видимо, обучаемая система и формирует в себе в конце концов некие зависимости эффективности предлагаемых запросов от параметров выборки.
Но сколько там в твиттере тех запросов, сто? Сто пятьдесят? Похоже на работу ради работы, ой, ради любопытства. И непонятно, что в итоге-то, запросы отбрасываются до выполнения, или выборки заранее обрезаются до разрешенного объема, который задает обучившаяся система?
Модель мешка слов, имхо, ошибочна: она смешивает в одну кучу имена таблиц, полей, операторы условий, группировки.
Особенно все спутают имена полей — участие поля в select, group by или соединении — это совсем разные операции, а для мешка слов — это одно и то же.
Хороший практический смысл имело бы разделение этого мешка на однотипные сущности и тогда получились бы диаграммы важности значения признака: например, вносимые задержки при обращении к разным таблицам или полям внутри таблицы. Из этого можно получить какие-то более тонкие подстройки: мол, если с планом запроса все ок, то вот еще у таблицы можно поменять порядок полей и этот класс запросов будет исполняться быстрее.
Машинное обучение помогает прогнозировать использование ресурсов при SQL-запросах