Сравнительный анализ эффективности планировщиков СУБД при выполнении различных запросов

[Akina]

Даже на первый взгляд - совершенно непонятно, зачем потребовался python, что мешало сделать всё на чистом SQL. Особенно генерацию тестовых данных - setseed() в PostgreSQL или rand(N) в MySQL позволяют любому читателю гарантированно воспроизвести одни и те же данные, причём именно те же, что использованы автором. А в SQLite их можно перегнать через CSV или linked server.

[astentx]

Скорее всего потому, что это курсовая/дипломная работа, судя по структуре и nir_7_semestr. Часто наблюдаемое явление: из питона по простому импорту CSV пушки по воробьям. В целом, если бы модели были объявлены через классы orm и менялся только энджин в алхимии, прилагался код-запускатор запросов и измеритель времени выполнения, сбрасыватель кешей/буферов и т.п (короче говоря, готовая настройка тестов), можно было бы сказать, что для простоты автоматизации и измерений. Но тут он просто потому что. Учитывая ещё то, что файлы локальные, и все названные СУБД умеют импортировать CSV нативной, без внешнего pandas.

[Yuvitch]

Ну вот... Вот так должны выглядеть статьи на Хабре.
Все по-научному: Объект, Цель, Постановка задачи, Методика, Материалы и Компоненты, Выполненные процедуры, Анализ, Заключение. Все основное -- в тексте, все детали -- в приложениях.
Не удивлюсь, если это материал к некоторой Конференции и/или Диссертации.

[Shado_vi]

в заголовке "при выполнении различных запросов" - по факту же только select запросы и только в НЕ фрагментированой таблице. в "вакуумах" условиях? (навевает на мысли об пропаганде/маркетинге pg, в этих условиях его лидерство понятно и так)
есть более качественные и глубокие статьи на хабре про планировщики.

[Tishka17]

Хотелось бы увидеть в данном сравнении ещё Oracle и MS SQL

[akardapolov]

В случае Oracle потребутся еще менять методику тестирования. Потому как очень много в СУБД Oracle в части стабилизации планов выполнения делается автоматически - SQL Plan Baselines.

[Akina]

На эти грабли наступают все , кто начинает делать как бы бенчмарки разных СУБД.

Ой, да настройки по умолчанию - вообще БСК. Вон у MySQL их три разных - для разработчика, выделенного сервера и невыделенного сервера. И какие из них, спрашивается, автор посчитал "ну совсем по умолчанию" - поди угадай.

[bigtrot]

1.В PostgreSQL есть конфигурационнык параметры для настройки планировщика запроса. Некоторые из них учитывают конфигурацию железа. Насколько правильно проводить сравнительный анализ без тонкой настройки под конфигурацию железа является один из вопросов.
2.Как было отмечено, статья методически выдержана с точки зрения проведения исследований. Но не хватает оценки практической ценности проведенного исследования.

[hard_sign]

Тот компонент СУБД, который вы описали, называется не планировщик, а оптимизатор. Планировщик отвечает за то, чтобы сгенерированные планы выполнялись одновременно, не мешая друг другу. У SQLite такого быть не может по определению.