Почему в Django преобразование List(QuerySet) такое медленное?

Question

[Сергей Еремин]

Люблю писать raw запросы в Django. И не то чтобы не умею готовить ORM (хотя готовлю не важно), а просто даже на SQL иногда не получается написать то что хочешь (см. мой предыдущий вопрос). И вот накатав очередной raw с кучей всяких JOIN из шести таблиц (назовет результат его исполнения QueySet2), и посмотрев в профилировщике сколько он кушает, решил всё безумное число повторяющихся полей таскать из предыдущего raw запроса (результат его назовем QuerySet1). Все равно он в кеше сидит, поля совпадают, id не повторяются... в моем случае это мне показалось удобным. Все равно надо весть этот QueySet2 прелопатить для отправки в шаблон выкинув 90% повторяющихся данных...

Чтобы было понятнее, происходит что-то вроде формирования таблицы... "листаю" записи QueySet2, раскладываю их в колонки и ряды, добавляю к каждому колонке и ряду какие-то справочные данные полученные из вычисляемых полей и полей связных таблиц навороченного QueySet2... А вот сами описания этих колонок, рядов и каждой ячейки можно взять из QyerySet1. И вот я обращаюсь к QyerySet1 примерно таким образом: QyerySet1[i].id ... Таких обращений всего 35 в цикле (посчитал). И выполеятся это 4.71 секунды. Но т.к. для определения длинны QyerySet1 все равно надо было -- для листания ячеек по рядам -- определить его длину len(list(QyerySet1)), то ради эксперимента решил проверить как это будет работать если сначала сделать ListSet1 = list(QyerySet1) а уже после обращаться ListSet1[i].id.... И те же 35 запросов выполнились за 0.25 секунды! Т.е. быстрее в 18 раз!

Время замерено без учета исполнения самого SQL (время исполнения SQL посмотрел в SQL-профилировщике и вычел из обоих замеров... Если не вычитать разница будет 12 раз, что тоже прилично).

Поэспериментировав, убедился, что обращение QyerySet1[i].id похоже каждый раз внутри Django превращается в List(QyerySet1)[i].id (я не программист, по-этому, в исходники лазит не умею, и делаю выводы просто сравнивая время исполнения разных вариантов).

Вопрос почему так медленно? Как это победить?

Answer 1

[Roman K]

Научись работать с Django
Научись работать с Python (в частности, pep8 и iterable)
Научись пользоваться ORM (only, defer, select/prefetch related) и использовать raw как исключение, а не наоборот
Научись строить архитектуру БД (в частности,

кучей всяких JOIN из шести таблиц

)

И не будет таких медленных запросов.

А ответом на вопрос будет примерно вот что:
Если QuerySet1 ещё не сфетчен, то QyerySet1[i].id делает запрос к БД (итого, 35 запросов)
list(QyerySet1) делает фетч и .id уже берётся из оперативы.

P.S. Используй django-debug-toolbar. Увидишь все свои SQL запросы и время их исполнения.

Comments

[Сергей Еремин]

Вы бы не ругались. а ответили по существу...

А вот за django-debug-toolbar -- спасибо! До того я много мучился, не понимая почему ORM, создавая запрос такой-же как и я подставляю ему через raw, работает радикально медленнее? (особенно с рекурсивными SQL-запросвми). Теперь с помощью django-debug-toolbar увидел, что и raw запросы django выполняет коряво. Например SQL конструкцию WHERE что-то IN (1, 2,3, ... ,100) раскручивает как сто разных WHERE! Т.е. то, что чистый SQL через курсоры выполняет 150 ms, Django через raw выполняет 15 секунд!

[Roman K]

Сергей Еремин: Дельные советы (с долей конструктивной критики) теперь расцениваются, как ругательства? Я абсолютно серьёзно советую вчитаться в каждое слово документации. Я пишу на джанго уже около двух лет и ни разу WHERE something IN (1,2,3...100) не раскручивалось в сотню разных WHERE. Сдаётся мне, советы я, всё-таки, дал правильные.

[Сергей Еремин]

Я не могу упростить базу. Собственно делаю агрегатор предложений пластиковых окон: oknardia.ru
Таблица_с_адресами дома --> таблица_с сериями_домов --> таблица с типами квартир в сериях --> связь_многое_ко_многим_с_указанием количества <-- проемы_окон_с_размерами <-- ценовое_предложение_на_проем_с_описанием_индивидуальных_схем_открывания <-- набор_(пакет_профиль_фурнитура_допники_услуга) <-- офис <-- бренд == это только основные таблицы. А еще таблицы со стеклопакетами (там у них куча характеристик и нужно рейтинги) , с профилями и пр. И когда надо собрать все это вместе чтобы показать -- то все серьезно! И это еще нет ранжирования учитывающего что одни предложения хороши на южную сторону дома, а другие на северную...

На счет RAW погорячился. Это как раз QyerySet[i].id каждый раз в отдельный SQL-чик превращается... Я его не заметил. т.к. он в функцию вынесен и написан был давно.

[Roman K]

Сергей Еремин: Честно говоря, сложно понимаются текстом сущности. Описание задачи текстом и примеры были бы куда проще. Забегая вперёд, спрошу: а точно ли нужны таблицы под, например, "таблица с типами квартир в сериях"? Просто если там не сотни-тысячи строк, постоянно пополняемых, может, лучше убрать их в константу в питон?

[Сергей Еремин]

Roman Kitaev: Типов квартир уже около 140, а всего то в базе 20 серий домов для теста... И даже те с лукавством (некоторые схожие по проемам серии объединены в одну). В реальности же только панельных серий под 1000... а я планирую в будущем "добить" и многоэтажками по индивидуальным проектам.

В общем, все сложно.

Кстати, еще интересное наблюдение через django-debug-toolbar ... если есть raw запрос SELECT id, A FROM ... бла-бла-бла... а после через QuerySet запросить поле B, которого нет в SELECT, то Django порождает еще один маленький SQL-запрос по id в нужную табличку (кстати, как она понимает к какой табличке). Из-за этого тоже тормозило.

[Сергей Еремин]

Тут еще надо понимать. что квартира "двушка" в одной серии совсем не то, что "двушка" в другой. И даже в одной серии они бывают разные: нижние этажи -- без балкона; в боковых секциях -- с дополнительными окнами; на первом этаже -- это переформатированная "трешка" от которой одну комнату переделали во входной блок (подъезд)... С домами, которые в форме "Г" и "ПЭ так и вовсе еще разнообразие планировок в поворотных секциях... мрак :(

Answer 2

[Сергей Еремин]

Возня с отладчиком показал:

Проблема в "Отложенной загрузке полей" при исполнении raw-запросов! В большом-пребольшом raw забыл указать одно из полей (не люблю использовать звездочки, т.к. хочется иметь названия всех полей перед глазами). Все работает, но при получении значения из неуказанного поля выполнялся еще один запрос! Соответственно, при выполнении list() никакой "Отложенной загрузкой полей" в этом большом-пребольшом запросе происходило, а происходил маленький запрос get по id в нужную таблицу (Django сам понимал, какие данные из БД хотят и сам строил маленький get-запрос). Понятно, что выполнение 35 маленьких get запросов быстрее чем 35 больших-пребольших.

Добавление нужного поля в большой-пребольшой запрос решило проблему. Аналогично ее решает использование звездочек в SQL-запросе.

Comments

[Roman K]

Ты это 1.5 года выяснял?)

[Сергей Еремин]

Нет. :)

Случайно нашел свой вопрос когда гуглил способ получения .value() для raw-queryset.... .value() только для запросов через ORM работает. :(