Оптимизация доступа к базе данных ¶

Понять QuerySet оценку ¶

Чтобы избежать проблем с производительностью, важно понимать:

• что QuerySets ленивы .
• когда они оцениваются .
• как данные хранятся в памяти .

Что такое кэшированные атрибуты ¶

Помимо кеширования целого QuerySet , существует кеширование результата атрибутов на объектах ORM. Как правило, атрибуты, которые нельзя вызвать, будут кэшироваться. Например, если предположить, что модели веб-журналов :

>>> 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 декоратора.

Используйте with тег шаблона ¶

Чтобы использовать кэширование QuerySet , вам может потребоваться with тег шаблона.

Используйте iterator() ¶

Когда у вас много объектов, кеширование QuerySet может привести к использованию большого количества памяти. В этом случае iterator() может помочь.

Используйте explain() ¶

QuerySet.explain() предоставляет подробную информацию о том, как база данных выполняет запрос, включая используемые индексы и объединения. Эти сведения могут помочь вам найти запросы, которые можно было бы переписать более эффективно, или определить индексы, которые можно добавить для повышения производительности.

Используйте RawSQL ¶

Менее переносимым, но более мощным методом является RawSQL выражение, которое позволяет явно добавить в запрос некоторый SQL. Если этого все еще недостаточно:

Используйте необработанный SQL ¶

Напишите свой собственный SQL для извлечения данных или заполнения моделей . Используйте, django.db.connection.queries чтобы узнать, что Django пишет для вас, и начать с этого.

Используйте QuerySet.select_related() и prefetch_related() ¶

Поймите select_related() и prefetch_related() тщательно, и используйте их:

• в менеджерах и менеджерах по умолчанию, где это необходимо. Помните, когда ваш менеджер используется, а когда нет; иногда это сложно, поэтому не делайте предположений.
• в коде просмотра или других слоях, возможно, используя prefetch_related_objects() там, где это необходимо.

Используйте QuerySet.values() и values_list() ¶

Если вам нужно только dict или list значений и не нужны объекты модели ORM, используйте подходящее использование values() . Они могут быть полезны для замены объектов модели в коде шаблона - до тех пор, пока предоставляемые вами dicts имеют те же атрибуты, что и используемые в шаблоне, все в порядке.

Используйте QuerySet.defer() и only() ¶

Используйте defer() и, only() если есть столбцы базы данных, которые, как вы знаете, вам не понадобятся (или не понадобятся в большинстве случаев), чтобы избежать их загрузки. Обратите внимание, что если вы все же их используете, ORM придется искать их в отдельном запросе, что делает это пессимизацией, если вы используете его ненадлежащим образом.

Не будьте слишком агрессивны, откладывая поля без профилирования, так как база данных должна читать большую часть нетекстовых данных, не относящихся к VARCHAR, с диска для одной строки результатов, даже если в итоге используется только несколько столбцов. Эти defer() и only() методы являются наиболее полезными , когда вы можете избежать загрузки много текстовых данных или для полей , которые могут принимать много обработки , чтобы преобразовать обратно в Python. Как всегда, сначала профилируйте, а затем оптимизируйте.

Используйте QuerySet.count() ¶

… Если вам нужен только счет, а не выполнение len(queryset) .

Используйте QuerySet.exists() ¶

… Если вы хотите узнать, существует ли хотя бы один результат, а не .if queryset

Но:

Не злоупотребляйте count() и exists() ¶

Если вам понадобятся другие данные из QuerySet, немедленно оцените их.

Например, предполагая, что модель электронной почты имеет body атрибут и отношение «многие ко многим» к пользователю, следующий код шаблона является оптимальным:

{% 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 %}

Это оптимально, потому что:

1. Поскольку QuerySets ленивы, запросы к базе данных не выполняются, если display_inbox имеет значение False.
2. Использование with означает, что мы сохраняем user.emails.all переменную для последующего использования, что позволяет повторно использовать ее кэш.
3. Строка вызывает вызов, который вызывает выполнение запроса в базе данных и, по крайней мере, первую строку, которая будет преобразована в объект ORM. Если результатов нет, он вернет False, в противном случае - True.{% if emails %} QuerySet.__bool__() user.emails.all()
4. Использование вызовов , заполнение остальной части кеша без выполнения другого запроса.{{ emails|length }} QuerySet.__len__()
5. for Цикл перебирает уже заполненной кэш.

Всего этот код выполняет один или ноль запросов к базе данных. Единственная преднамеренная оптимизация - это использование with тега. Использование QuerySet.exists() или QuerySet.count() в любой момент вызовет дополнительные запросы.

Используйте QuerySet.update() и delete() ¶

Вместо того, чтобы извлекать массу объектов, устанавливать некоторые значения и сохранять их по отдельности, используйте массовый оператор SQL UPDATE через QuerySet.update () . Аналогичным образом выполняйте массовое удаление, где это возможно.

Обратите внимание, однако, что эти методы массового обновления не могут вызывать методы save() или delete() отдельных экземпляров, а это означает, что любое настраиваемое поведение, добавленное вами для этих методов, не будет выполняться, включая все, что вызвано обычными сигналами объекта базы данных .

Используйте значения внешнего ключа напрямую ¶

Если вам нужно только значение внешнего ключа, используйте значение внешнего ключа, которое уже есть в объекте, который у вас есть, вместо получения всего связанного объекта и его первичного ключа. то есть делать:

entry.blog_id

вместо того:

entry.blog.id

Не заказывайте результаты, если вам все равно ¶

Заказ платный; каждое поле для сортировки - это операция, которую должна выполнить база данных. Если модель имеет порядок упорядочивания по умолчанию ( Meta.ordering ) и он вам не нужен, удалите его QuerySet , вызвав order_by() без параметров.

Добавление индекса в вашу базу данных может помочь повысить производительность заказа.

Создать оптом ¶

При создании объектов по возможности используйте этот bulk_create() метод, чтобы уменьшить количество SQL-запросов. Например:

Entry.objects.bulk_create([
    Entry(headline='This is a test'),
    Entry(headline='This is only a test'),
])

… Предпочтительнее:

Entry.objects.create(headline='This is a test')
Entry.objects.create(headline='This is only a test')

Обратите внимание, что их несколько , поэтому убедитесь, что они подходят для вашего варианта использования.caveats to this method

Массовое обновление ¶

При обновлении объектов по возможности используйте этот bulk_update() метод, чтобы уменьшить количество SQL-запросов. Учитывая список или набор запросов объектов:

entries = Entry.objects.bulk_create([
    Entry(headline='This is a test'),
    Entry(headline='This is only a test'),
])

Следующий пример:

entries[0].headline = 'This is not a test'
entries[1].headline = 'This is no longer a test'
Entry.objects.bulk_update(entries, ['headline'])

… Предпочтительнее:

entries[0].headline = 'This is not a test'
entries[0].save()
entries[1].headline = 'This is no longer a test'
entries[1].save()

Обратите внимание, что их несколько , поэтому убедитесь, что они подходят для вашего варианта использования.caveats to this method

Вставить оптом ¶

При вставке объектов в ManyToManyFields используйте add() с несколькими объектами, чтобы уменьшить количество SQL-запросов. Например:

my_band.members.add(me, my_friend)

… Предпочтительнее:

my_band.members.add(me)
my_band.members.add(my_friend)

… Где Bands и Artists иметь отношения «многие ко многим».

При вставке разных пар объектов в ManyToManyField или при определении настраиваемой through таблицы используйте bulk_create() метод для уменьшения количества запросов SQL. Например:

PizzaToppingRelationship = Pizza.toppings.through
PizzaToppingRelationship.objects.bulk_create([
    PizzaToppingRelationship(pizza=my_pizza, topping=pepperoni),
    PizzaToppingRelationship(pizza=your_pizza, topping=pepperoni),
    PizzaToppingRelationship(pizza=your_pizza, topping=mushroom),
], ignore_conflicts=True)

… Предпочтительнее:

my_pizza.toppings.add(pepperoni)
your_pizza.toppings.add(pepperoni, mushroom)

… Где Pizza и Topping иметь отношения «многие ко многим». Обратите внимание, что их несколько , поэтому убедитесь, что они подходят для вашего варианта использования.caveats to this method

Удалить оптом ¶

При удалении объектов ManyToManyFields используйте remove() с несколькими объектами, чтобы уменьшить количество запросов SQL. Например:

my_band.members.remove(me, my_friend)

… Предпочтительнее:

my_band.members.remove(me)
my_band.members.remove(my_friend)

… Где Bands и Artists иметь отношения «многие ко многим».

При удалении различных пар объектов из ManyToManyFields , использование delete() на Q выражение с несколькими through экземплярами модели , чтобы уменьшить количество запросов SQL. Например:

from django.db.models import Q
PizzaToppingRelationship = Pizza.toppings.through
PizzaToppingRelationship.objects.filter(
    Q(pizza=my_pizza, topping=pepperoni) |
    Q(pizza=your_pizza, topping=pepperoni) |
    Q(pizza=your_pizza, topping=mushroom)
).delete()

… Предпочтительнее:

my_pizza.toppings.remove(pepperoni)
your_pizza.toppings.remove(pepperoni, mushroom)

… Где Pizza и Topping иметь отношения «многие ко многим».