Олег Чуркин (Rambler&Co) - Django: правильно готовим ORM

Доклад с Moscow Python Conf 2016 (conf.python.ru)
Слайды: conf.python.ru/django-orm/
В докладе будут затронуты большинство тем, которые необходимо знать современному python-разработчику, чтобы эффективно использовать функционал Django-ORM для построения высоконагруженных web-проектов.
Поговорим и про классические ошибки при работе с QuerySet’ами и про профилирование и про code style. Выясним как можно сэкономить память и время при выполнении запросов, покажу популярные ошибки при проектировании схемы данных и при использовании миграций, а так же рассмотрим несколько распространенных задач современного веба, которые в Django еще не решены или решены некорректно.

[@Shmidtelson]

Очень познавательно. Побольше бы таких докладов =) Да хрен с этим кофебрейком. Как будто каждый день такую инфу дают.

[@fannigurt]

Вы когда организовываете конференции, вы не про кофе думайте, а про контент. Если бы просмотрели презентацию заранее и подготовились по таймингу, то поняли бы, что она часовая.

[@PythonDevelopment]

Жаль что не продолжили. Такой суперский докладчик и его так слили в конце! Печально, ребята!

[@torroot4142]

офигенный доклад спасибо

[@user-vj3ug7ub3h]

Спасибо за доклад. Очень толково!

[@Igor-if7sx]

Годнота! Спасибо Олег

[@alexeyluzin4485]

огонь

[@SamoilenkoLev]

Спасибо, очень круто. Не понял, правда, почему prefetch_related так плох. Если дополнительный запрос генерит не так много данных, мне кажется, проще его использовать чем raw SQL

[@delir0]

Спасибо за доклад, он хорош. Хотя, есть пара ошибок: 1) М2М связь Django создаёт уникальный составной индекс, в докладе утверждается иное; 2) Аргумент поля для создания модели называется db_index, а не index_db; 3) Докладчик рекомендует к использованию iterator, однако для psycopg2, драйвера, который мы все используем для постгреса, iterator не имеет смысла, поскольку сам драйвер кэширует результат.

[@Bahusss]

Спасибо за замечания. Однако, итератор работает не на уровне драйвера, а на уровне ORM и с помощью него можно избежать создания экземпляров модели в памяти. А из бд все данные подтягиваются всегда (если не использовать streaming).

[@delir0]

Ух ты, вот это вы меня обрадовали.

[@TyVik]

@@Bahusss Upd. Мне кажется, что Django ORM уже умеет работать через server-side cursor - docs.djangoproject.com/en/2.2/ref/models/querysets/#django.db.models.query.QuerySet.iterator

[@vmgrussia]

докладчик молодец )) хотя я хз что такое ORM ))

[@funkindy]

Доклад супер. Но удивило несколько, что скорость БД выше скорости питона, по части манипуляции с данными. Разные сложные решейпы и агрегации я делаю в pandas, загружая queryset в датафрейм, и не совсем понятно как in-memory обработка может быть медленней. Но я далеко не гуру.

[@TyVik]

Фишка в том, что pandas, numpy и пр. - расширения на C, которые работают напрямую с памятью, не создавая промежуточных python объектов. Так что скорость должна быть сравнима с БД. А вот если будете строки, которые обычные str сортировать или int, то тогда всё будет очень плохо.

[@funkindy]

@@TyVik с этим согласен

[@NMelis]

и что юзать тогда вместо order_by("?")

[@kostyaminkov5659]

создай масив с полями таблицы, в пайтоне импортируй рандом, а в ордер уже закидуй рандомное поле с твоего массива

[@NMelis]

@@kostyaminkov5659 ну такое себе решение

[@NMelis]

from django.db.models.functions import Random random_records = YourModel.objects.annotate(random_number=Random()).order_by('random_number')

[@peas8556]

Зздззз

[@hansolo5665]

хранить деньги в decimal field ? он серьезно ?

[@Furkas91]

почему нет?

[@user-jd4rl7im6d]

@@Furkas91 в долларах надо хранить!