Django всячески помогает разработчикам получить максимальную отдачу от используемой базы данных. В этом разделе собрана информация, которая пригодится при оптимизации вашего приложения.
Для практикующих программистов - это само собой разумеется. Первым делом определите какие запросы выполняются и как быстро. Вы также можете использовать сторонние приложения, например, django-debug-toolbar, или инструменты, которые мониторят непосредственно базу данных.
Вы можете оптимизировать скорость работы, или потребляемую память, или оба параметра. Иногда оптимизация одного пагубно влияет на другой параметр, но иногда можно улучшить оба. Так же нагрузка на базу данных может быть не так важна(для вас) как нагрузка на сервер(работы python). Вы сами определяете золотую средину, и не забывайте выполнить профайлинг всего этого, перед оптимизацией.
Не забывайте выполнять профайлинг после каждого изменения, чтобы удостоверится что изменения повысили производительность, и что это повышение стоит усложнения кода. Все советы ниже могут и не сработать в вашем случае, или даже понизить производительность.
...включая:
Индексы. Следует добавить в первую очередь, после того, когда вы определите через профайлинг, какие индексы требуются. Используйте Field.db_index или Meta.index_together чтобы добавить индексы из Django. Следует добавить индексы полям, которые используются в filter(), exclude(), order_by() и др., т.к. они ускоряют поиск по полям. Куда добавлять индексы - сложный вопрос, который зависит от БД и вашего приложения. Накладные расходы на поддержку индекса могут перевесить полученное ускорение при выполнении запросов.
Используйте правильные типы полей.
Предположим вы уже выполнили эти очевидные вещи. Остальная часть этого раздела расскажет, как оптимально использовать Django. Этот документ не описывает другие методы оптимизации, которые применимы для всех “тяжелых” операций, например, кэширование.
Понимание QuerySets - важная часть для написания эффективного простого кода. В частности:
Для избежания проблем с производительностью, важно понимать:
когда происходит вычисление.
Как и кэширование всего QuerySet, существует кэширование значения атрибутов в объектах ORM. В общем, не вызываемые атрибуты(not callable) будут закэшированы. Например, возьмем модель Weblog из примеров:
>>> entry = Entry.objects.get(id=1)
>>> entry.blog # Blog object is retrieved at this point
>>> entry.blog # cached version, no DB access
Но обращение к вызываемым атрибутам каждый раз выполняет запрос к базе данных:
>>> entry = Entry.objects.get(id=1)
>>> entry.authors.all() # query performed
>>> entry.authors.all() # query performed again
Будьте внимательны читая код шаблонов - шаблонизатор не позволяет использовать скобки и автоматом вызывает функции и методы.
Будьте внимательны с собственными свойствами - вы должны самостоятельно реализовать кэширование, используя, например, декоратор cached_property.
Для использования кэширования в QuerySet можно использовать шаблонный тэг with.
Если у вас очень много объектов, кэширование в QuerySet может использовать большой объем памяти. В этом случае может помочь iterator().
Например:
Самое простое: используйте filter и exclude для фильтрации данных в БД.
Используйте объект F() для фильтрации по другим полям модели.
Используйте annotate для выполнения агрегации в базе данных.
Если этого не достаточно для создания необходимого SQL:
Не совсем переносимый между разными БД, но очень мощный метод – RawSQL, который позволяет добавить SQL непосредственно в запрос. Если и этого вам не достаточно:
Используйте собственный SQL запрос для получения данных и загрузки в модели. Используйте django.db.connection.queries, чтобы понять что создает Django и начните с изменения этого запроса.
Есть две причины использовать поле с unique или db_index в методе get(). Первая - запрос будет быстрее т.к. будет использовать индекс в базе данных. Вторая - запрос будет гораздо медленнее, если несколько объектов будут удовлетворять запросу, уникальное поле исключает такую ситуацию.
Для нашего примера блога:
>>> entry = Entry.objects.get(id=10)
будет быстрее чем:
>>> entry = Entry.object.get(headline="News Item Title")
т.к. id проиндексировано и уникально.
Следующий запрос будет скорее всего медленным:
>>> entry = Entry.objects.get(headline__startswith="News")
Во-первых headline не проиндексировано и база данных будет медленнее вычислять результат.
Во-вторых - запрос не гарантирует, что будет возвращен только один объект. Если несколько объектов удовлетворяют запросу, они все будут переданы с базы данных. Задержка может быть значительной при передачи сотен или тысяч объектов. Еще большую задержку получаем, если база данных находится на другом сервере.
Обращение несколько раз к базе данных для получения различных частей одного “массива” данных обычно менее эффективно, чем получение всех данных одним запросом. Это особенно важно для запросов, выполняемых в цикле, что может привести к большому количеству запросов. Поэтому:
Если вам нужен dict или list значений, а не объекты моделей ORM, используйте values(). Это можно использовать для подмены объектов моделей в шаблоне - если атрибуты словаря совпадают с используемыми атрибутами моделей, все будет хорошо работать.
Используйте defer() и only(), если есть колонки в базе данных, которые вы не будете использовать. Запомните, что если вы все же будете их использовать, ORM сделает дополнительный запрос для их получения, что уменьшит производительность.
Заметим, что при создании моделей с “deferred” полями Django выполняет некоторую дополнительную работу. Не перестарайтесь, так как база данных читает большинство не текстовых, не VARCHAR данных с диска при запросе, даже если будет использоваться только несколько колонок, используйте профайлинг. Методы defer() и only() полезны, если вы можете избежать загрузки большинства текстовых полей или полей, которые долго конвертируются в объекты Python. Как всегда - используйте сначала профайлинг.
...вместо``len(queryset)``, если вам необходимо только количество объектов.
...если необходимо проверить есть ли результат, вместо if queryset.
Но:
Если вам необходимы остальные данные из QuerySet, просто вычислите их.
Например, возьмем модель Email с полем body и связь многое-го-многим с моделью User, следующий шаблон будет оптимальным:
{% if display_inbox %}
{% with emails=user.emails.all %}
{% if emails %}
<p>You have {{ emails|length }} email(s)</p>
{% for email in emails %}
<p>{{ email.body }}</p>
{% endfor %}
{% else %}
<p>No messages today.</p>
{% endif %}
{% endwith %}
{% endif %}
Он оптимальный потому что:
Так как QuerySets ленивый, запрос не будет выполнен при ‘display_inbox’ равном False.
Тег with означает что мы сохраняем user.emails.all в переменной для последующего использования.
Строка {% if emails %} вызывает QuerySet.__bool__(), который выполняет``user.emails.all()`` что приводит к запросу к базе данных, и как минимум первая строка ответа будет преобразована в ORM объект. Если результат будет пуст, вернется False, иначе True.
Использование {{ emails|length }} вызывает QuerySet.__len__(), заполняя оставшийся кэш без выполнения запроса.
for выполняет цикл по уже заполненному кэшу.
В общем этот код делает один или ноль запросов к базе данных. Единственная необходимая оптимизация – это использование тега with. Использование QuerySet.exists() или QuerySet.count() вызвало бы дополнительные запросы.
Вместо загрузки данных в объекты, изменения значений и отдельного их сохранения, используйте SQL UPDATE запросы через QuerySet.update(). Аналогично используйте массовое удаление при возможности.
Однако учтите, что эти методы не вызывают save() или delete() объектов. Это означает, что логика добавленная вами в эти методы, не будет выполнена, учитывая обработчики сигналов от объектов.
Если вам необходимо только значение внешнего ключа, используйте его, т.к. оно уже в объекте, который вы получили, вместо получения всего связанного объекта и использования первичного ключа. Например, делайте:
entry.blog_id
вместо:
entry.blog.id
Сортировка требует ресурсы. Каждое поле, по которому производится сортировка, требует от базы данных дополнительных ресурсов. Если модель имеет сортировку по-умолчанию (Meta.ordering) и она вам не нужна, уберите её из запроса с помощью order_by() (без параметров).
Добавление индекса в вашу базу данных может улучшить производительность операции сортировки.
При создании объектов, если возможно, используйте метод bulk_create() чтобы сократить количество SQL запросов. Например:
Entry.objects.bulk_create([
Entry(headline="Python 3.0 Released"),
Entry(headline="Python 3.1 Planned")
])
...предпочтительнее чем:
Entry.objects.create(headline="Python 3.0 Released")
Entry.objects.create(headline="Python 3.1 Planned")
Заметим, что есть несколько предостережений к этому методу, убедитесь что этот метод подходит для всего случая.
Это относится и к ManyToManyFields, это:
my_band.members.add(me, my_friend)
...предпочтительнее чем:
my_band.members.add(me)
my_band.members.add(my_friend)
...где Bands и Artists связаны через многие-ко-многим.
Mar 31, 2016