Comments 10
Даже на первый взгляд - совершенно непонятно, зачем потребовался python, что мешало сделать всё на чистом SQL. Особенно генерацию тестовых данных - setseed() в PostgreSQL или rand(N) в MySQL позволяют любому читателю гарантированно воспроизвести одни и те же данные, причём именно те же, что использованы автором. А в SQLite их можно перегнать через CSV или linked server.
Скорее всего потому, что это курсовая/дипломная работа, судя по структуре и nir_7_semestr. Часто наблюдаемое явление: из питона по простому импорту CSV пушки по воробьям. В целом, если бы модели были объявлены через классы orm и менялся только энджин в алхимии, прилагался код-запускатор запросов и измеритель времени выполнения, сбрасыватель кешей/буферов и т.п (короче говоря, готовая настройка тестов), можно было бы сказать, что для простоты автоматизации и измерений. Но тут он просто потому что. Учитывая ещё то, что файлы локальные, и все названные СУБД умеют импортировать CSV нативной, без внешнего pandas.
Ну вот... Вот так должны выглядеть статьи на Хабре.
Все по-научному: Объект, Цель, Постановка задачи, Методика, Материалы и Компоненты, Выполненные процедуры, Анализ, Заключение. Все основное -- в тексте, все детали -- в приложениях.
Не удивлюсь, если это материал к некоторой Конференции и/или Диссертации.
в заголовке "при выполнении различных запросов" - по факту же только select запросы и только в НЕ фрагментированой таблице. в "вакуумах" условиях? (навевает на мысли об пропаганде/маркетинге pg, в этих условиях его лидерство понятно и так)
есть более качественные и глубокие статьи на хабре про планировщики.
Хотелось бы увидеть в данном сравнении ещё Oracle и MS SQL
В случае Oracle потребутся еще менять методику тестирования. Потому как очень много в СУБД Oracle в части стабилизации планов выполнения делается автоматически - SQL Plan Baselines.
все СУБД были использованы с настройками по умолчанию
На эти грабли наступают все , кто начинает делать как бы бенчмарки разных СУБД.
что релевантно для большинства типовых сценариев развертывания.
Для PostgreSQL наоборот абсолютно нерелевантно.
Но, тем не менее , с академической точкой зрения - да интересно. Спасибо, в закладках.
А теперь , вопрос по существу
Каждый запрос выполнялся в каждой СУБД последовательно 10 раз.
Почему вы делайте выводы на основании столь малой выборки ?
Очень важное замечание по методологии
После сбора сырых данных для каждого запроса и каждой СУБД вычислялось среднее значение времени выполнения.
Почему делаются выводы о эффективности сложного алгоритма(планировщик это сложный алгоритм) на основании оценки не обладающей свойством робастности (устойчивости к выбросам) ?
1.В PostgreSQL есть конфигурационнык параметры для настройки планировщика запроса. Некоторые из них учитывают конфигурацию железа. Насколько правильно проводить сравнительный анализ без тонкой настройки под конфигурацию железа является один из вопросов.
2.Как было отмечено, статья методически выдержана с точки зрения проведения исследований. Но не хватает оценки практической ценности проведенного исследования.
Тот компонент СУБД, который вы описали, называется не планировщик, а оптимизатор. Планировщик отвечает за то, чтобы сгенерированные планы выполнялись одновременно, не мешая друг другу. У SQLite такого быть не может по определению.
Сравнительный анализ эффективности планировщиков СУБД при выполнении различных запросов