--- title: "Optimisation de l’accès à la base de données" version: 1.11 locale: fr source: https://docs.djangoproject.com/fr/1.11/topics/db/optimization/ canonical: https://djangodocs.dev/fr/1.11/topics/db/optimization/ --- # Optimisation de l’accès à la base de données La couche de base de données de Django fournit plusieurs manières d’aider les développeurs à tirer le meilleur de leurs bases de données. Ce document rassemble des liens vers la documentation adéquate et ajoute quelques astuces, réparties dans plusieurs chapitres respectant la chronologie des étapes à suivre lorsqu’on souhaite optimiser l’utilisation de la base de données. ## Priorité au profilage Comme principe de programmation générale, cela va sans dire. Recherchez [quelles sont les requêtes effectuées et ce qu’elles coûtent](/fr/1.11/faq/models/#faq-see-raw-sql-queries). Il est aussi possible d’utiliser un projet externe comme [django-debug-toolbar](https://github.com/jazzband/django-debug-toolbar/) ou un outil qui surveille directement votre base de données. Rappelez-vous que l’on peut optimiser pour la rapidité, pour la mémoire ou pour les deux, en fonction des besoins. Parfois, l’optimisation d’un côté va péjorer la situation de l’autre, mais dans d’autres cas, les deux vont en profiter ensemble. De plus, le travail effectué par le processus de la base de données n’a pas toujours le même coût (pour vous) que le même travail effectué dans le processus Python. C’est à vous de décider des priorités, de pondérer avantages et inconvénients et de profiler tout cela selon les besoins car tout dépend de votre application et du serveur. Avec tout ce qui suit, n’oubliez pas de profiler après chaque modification pour vous assurer que celle-ci est bénéfique et que le bénéfice est suffisant pour compenser la perte de lisibilité du code. Pour **toutes** les suggestions ci-dessous, il faut tenir compte du risque que le principe général ne s’applique pas dans votre cas de figure, ou que l’effet soit même inversé. ## Techniques standards d’optimisation de base de données Ceci comprend : - Des [index](https://en.wikipedia.org/wiki/Database_index). C’est la priorité n°1, *après* avoir déterminé par analyse de performance quels sont les index nécessaires. Utilisez [`Field.db_index`](/fr/1.11/ref/models/fields/#django.db.models.Field.db_index) ou [`Meta.index_together`](/fr/1.11/ref/models/options/#django.db.models.Options.index_together) pour en ajouter à partir de Django. Envisagez l’utilisation d’index aux champs que vous interrogez fréquemment avec [`filter()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.filter), [`exclude()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.exclude), [`order_by()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.order_by), etc. car les index peuvent aider à accélérer les requêtes. Notez que la recherche des meilleurs index est un thème complexe et dépendant du moteur de base de données, également dépendant de l’application à construire. La charge induite par la maintenance d’un index peut anéantir les gains en terme de vitesse de requête. - Utilisation appropriée des types de champs. Nous supposerons que vous avez effectué les opérations évidentes ci-dessus. La suite de ce document se concentre sur la façon d’utiliser Django de telle manière à ne pas effectuer de travail inutile. Ce document n’aborde cependant pas d’autres techniques d’optimisation qui s’appliquent à des opérations lourdes, comme la [mise en cache à portée générale](/fr/1.11/topics/cache/). ## Compréhension des objets `QuerySet` La compréhension des [QuerySet](/fr/1.11/ref/models/querysets/) est capitale pour obtenir de bonnes performances avec du code simple. En particulier : ### Compréhension de l’évaluation du `QuerySet` Pour éviter des problèmes de performance, il est important de comprendre : - que les [QuerySet sont différés](/fr/1.11/topics/db/queries/#querysets-are-lazy). - quand [ils sont évalués](/fr/1.11/ref/models/querysets/#when-querysets-are-evaluated). - comment [les données sont conservée en mémoire](/fr/1.11/topics/db/queries/#caching-and-querysets). ### Compréhension des attributs mis en cache Tout comme la mise en cache d’un `QuerySet` global, il y a mise en cache du résultat des attributs dans les objets de l’ORM. En général, les attributs qui ne sont pas exécutables seront mis en cache. Par exemple, à partir des [modèles d’exemple du Weblog](/fr/1.11/topics/db/queries/#queryset-model-example): ``` >>> entry = Entry.objects.get(id=1) >>> entry.blog # Blog object is retrieved at this point >>> entry.blog # cached version, no DB access ``` Mais généralement, les attributs exécutables provoquent des accès à la base de données à chaque appel : ``` >>> entry = Entry.objects.get(id=1) >>> entry.authors.all() # query performed >>> entry.authors.all() # query performed again ``` Soyez prudent dans la lecture du code des gabarits, le système des gabarits ne permet pas d’utiliser des parenthèses, mais les objets exécutables sont appelés automatiquement, masquant la distinction ci-dessus. Soyez prudent avec vos propres propriétés personnalisées, il vous revient d’implémenter leur mise en cache au besoin, par exemple en utilisant le décorateur [`cached_property`](/fr/1.11/ref/utils/#django.utils.functional.cached_property). ### Utilisation de la balise de gabarit `with` Pour faire usage du comportement de cache de `QuerySet`, il peut être nécessaire d’utiliser la balise de gabarit [`with`](/fr/1.11/ref/templates/builtins/#std-templatetag-with). ### Utilisation de `iterator()` Lorsque vous manipulez un grand nombre d’objets, le comportement de cache de `QuerySet` peut provoquer une grosse utilisation de la mémoire. Dans ce cas, [`iterator()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.iterator) peut aider. ## Travail de base de données en base de données plutôt qu’en Python Par exemple : - Au niveau le plus élémentaire, utilisez [filter et exclude](/fr/1.11/ref/models/querysets/#queryset-api) pour filtrer au niveau de la base de données. - Utilisez les [`expressions F`](/fr/1.11/ref/models/expressions/#django.db.models.F) pour filtrer en rapport avec d’autres champs à l’intérieur du même modèle. - Utilisez les [annotations pour effectuer le travail d’agrégation dans la base de données](/fr/1.11/topics/db/aggregation/). Si ces outils ne suffisent pas à générer le code SQL nécessaire : ### Utilisation de `RawSQL` Une méthode moins portable mais plus puissante est d’utiliser l’expression [`RawSQL`](/fr/1.11/ref/models/expressions/#django.db.models.expressions.RawSQL) qui permet d’ajouter explicitement du code SQL dans une requête. Si cela ne suffit toujours pas : ### Utilisation de SQL brut Écrivez votre [propre code SQL pour sélectionner des données ou remplir les modèles](/fr/1.11/topics/db/sql/). Utilisez `django.db.connection.queries` pour examiner ce que Django écrit pour vous et considérez cela comme un point de départ. ## Sélection d’objets individuels en utilisant une colonne unique et indexée Il y a deux raisons d’utiliser une colonne avec [`unique`](/fr/1.11/ref/models/fields/#django.db.models.Field.unique) ou [`db_index`](/fr/1.11/ref/models/fields/#django.db.models.Field.db_index) lorsqu’on utilise [`get()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.get) pour récupérer des objets individuels. Premièrement, la requête sera plus rapide en raison de l’index de base de données. De plus, la requête pourrait s’effectuer beaucoup plus lentement si plusieurs objets correspondent à la recherche ; avec une contrainte d’unicité sur la colonne, vous avez la garantie que cela ne se produira jamais. Ainsi, en se basant sur les [modèles d’exemple de Weblog](/fr/1.11/topics/db/queries/#queryset-model-example): ``` >>> entry = Entry.objects.get(id=10) ``` sera plus rapide que : ``` >>> entry = Entry.objects.get(headline="News Item Title") ``` parce qu”`id` est indexé dans la base de données et que son unicité est garantie. La ligne suivante est potentiellement très lente : ``` >>> entry = Entry.objects.get(headline__startswith="News") ``` Tout d’abord, `headline` n’est pas indexé, ce qui fait que la base de données sous-jacente prendra plus de temps pour trouver la ligne. Deuxièmement, cette recherche ne garantit pas qu’un seul objet sera renvoyé. Si la requête correspond à plus d’un objet, elle va tous les sélectionner et les transférer depuis la base de données. Cette pénalité peut être conséquente si des centaines ou des milliers d’enregistrements sont renvoyés. Ce d’autant plus si la base de données est située sur un autre serveur, là où la latence et le surcoût de la liaison réseau jouent aussi un rôle. ## Tout récupérer d’un coup quand on en connaît le besoin Il est en général moins efficace de solliciter la base de données plusieurs fois pour différentes parties d’un ensemble de données que de tout récupérer par une seule requête quand on sait à l’avance que l’on aura besoin du tout. C’est particulièrement important lorsqu’une requête est exécutée dans une boucle et risque au final d’effectuer plusieurs requêtes en base de données alors qu’une seule n’est vraiment nécessaire. Ainsi : ### Utilisation de `QuerySet.select_related()` et `prefetch_related()` Il faut bien comprendre [`select_related()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.select_related) et [`prefetch_related()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.prefetch_related) et les utiliser : - dans les [gestionnaires (par défaut ou non)](/fr/1.11/topics/db/managers/) lorsque cela fait sens. Ayez conscience des endroits où les gestionnaires sont (ou ne sont pas) utilisés ; ce n’est pas toujours évident de le savoir, ne faites donc pas de simples suppositions. - dans du code de vues ou d’autres couches, en faisant potentiellement appel à [`prefetch_related_objects()`](/fr/1.11/ref/models/querysets/#django.db.models.prefetch_related_objects) lorsque c’est nécessaire. ## Ne pas récupérer des éléments inutilement ### Utilisation de `QuerySet.values()` et `values_list()` Lorsque vous ne voulez qu’obtenir un dictionnaire ou une liste de valeurs sans avoir besoin d’objets modèles de l’ORM, faites bon usage de [`values()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.values). Cette méthode peut être utile pour remplacer des objets modèles dans le code des gabarits ; tant que les dictionnaires résultants possèdent les mêmes attributs que ceux qui sont utilisés dans le gabarit, tout va bien. ### Utilisation de `QuerySet.defer()` et `only()` Utilisez [`defer()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.defer) et [`only()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.only) quand vous savez à l’avance que vous n’aurez pas besoin de certaines colonnes de base de données (ou non utiles dans la plupart des cas) afin d’éviter de les charger. Notez que si vous les utilisez quand même, l’ORM devra les charger à l’aide d’une nouvelle requête, ce qui peut potentiellement aggraver la situation quand cette technique n’est pas utilisée à bon escient. Sachez également qu’il y a un léger surcoût lorsque Django doit construire un modèle avec des champs différés. N’utilisez pas trop agressivement les champs différés sans profilage car la base de données doit lire sur le disque la plupart des données non textuelles et non `VARCHAR` d’un enregistrement des résultats, même lorsqu’elle finit par n’exploiter que quelques colonnes. Les méthodes `defer()` et `only()` sont particulièrement adéquates lorsqu’on peut éviter de charger de grandes quantités de données textuelles ou quand la valeur de certains champs est coûteuse en terme de conversion en Python. Comme toujours, profilez d’abord, optimisez ensuite. ### Utilisation de `QuerySet.count()` …si vous n’avez besoin que du nombre de lignes, et évitez `len(queryset)`. ### Utilisation de `QuerySet.exists()` …si vous voulez uniquement savoir qu’il y a au moins un résultat, et évitez `if queryset`. Mais : ### Ne pas abuser de count()\` et `exists()` Si vous allez avoir besoin de données réelles du QuerySet, autant l’évaluer. Par exemple, si on dispose d’un modèle Email ayant un attribut `body` et une relation plusieurs-à-plusieurs vers `User`, le code de gabarit suivant est optimal : ```html+django {% if display_inbox %} {% with emails=user.emails.all %} {% if emails %}

You have {{ emails|length }} email(s)

{% for email in emails %}

{{ email.body }}

{% endfor %} {% else %}

No messages today.

{% endif %} {% endwith %} {% endif %} ``` Il est optimal car : 1. Comme les objets QuerySet sont différés, aucune requête de base de données n’est exécutée si “display\_inbox” vaut False. 2. L’emploi de [`with`](/fr/1.11/ref/templates/builtins/#std-templatetag-with) signifie que nous stockons `user.emails.all` dans une variable pour usage ultérieur, permettant ainsi de réutiliser son cache. 3. La ligne `{% if emails %}` provoque l’appel à `QuerySet.__bool__()`, ce qui provoque aussi l’exécution de la requête `user.emails.all()` dans la base de données et la construction du premier résultat au moins comme objet ORM. S’il n’y a pas de résultats, elle renvoie False, sinon True. 4. L’emploi de `{{ emails|length }}` appelle `QuerySet.__len__()`, ce qui remplit le reste du cache sans effectuer de nouvelle requête. 5. La boucle [`for`](/fr/1.11/ref/templates/builtins/#std-templatetag-for) utilise les données déjà en cache. Au total, le code effectue une ou zéro requête de base de données. La seule optimisation explicite effectuée est l’emploi de la balise [`with`](/fr/1.11/ref/templates/builtins/#std-templatetag-with). Si on avait utilisé `QuerySet.exists()` ou `QuerySet.count()` à n’importe quel endroit, cela aurait généré des requêtes supplémentaires. ### Utilisation de `QuerySet.update()` et `delete()` Plutôt que de récupérer un ensemble d’objets, de définir certaines valeurs et de les enregistrer individuellement, utilisez une instruction SQL UPDATE groupée au moyen de [QuerySet.update()](/fr/1.11/topics/db/queries/#topics-db-queries-update). De la même façon, effectuez des [suppressions groupées](/fr/1.11/topics/db/queries/#topics-db-queries-delete) chaque fois que c’est possible. Notez cependant que des méthodes de mise à jour groupées ne peuvent pas appeler les méthodes `save()` et `delete()` des instances individuelles, ce qui signifie que tout comportement spécialisé que vous auriez ajouté avec ces méthodes ne sera pas exécuté, y compris tout ce qui découle de l’utilisation des [signaux](/fr/1.11/ref/signals/) attachés aux objets de base de données. ### Utilisation directe de valeurs de clé étrangère Si vous n’avez besoin que de la valeur d’une clé étrangère, utilisez la valeur qui est déjà stockée dans l’objet que vous manipulez, plutôt que de récupérer tout l’objet lié pour simplement disposer de sa clé primaire. Par exemple, faites : ``` entry.blog_id ``` au lieu de : ``` entry.blog.id ``` ### Ne pas trier les résultats sans raison Le tri n’est pas gratuit ; chaque champ de tri est une opération que la base de données doit effectuer. Si un modèle possède un ordre de tri par défaut ([`Meta.ordering`](/fr/1.11/ref/models/options/#django.db.models.Options.ordering)) et que vous n’en avez pas besoin, vous pouvez l’enlever sur un `QuerySet` en appelant [`order_by()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.order_by) sans paramètre. L’ajout d’un index à votre base de données peut aider à améliorer les performances de tri. ## Insertion groupée Lors de la création d’objets, utilisez si possible la méthode [`bulk_create()`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.bulk_create) pour réduire le nombre de requêtes SQL. Par exemple : ``` Entry.objects.bulk_create([ Entry(headline='This is a test'), Entry(headline='This is only a test'), ]) ``` …est préférable à : ``` Entry.objects.create(headline='This is a test') Entry.objects.create(headline='This is only a test') ``` Notez qu’il existe un certain nombre de [`restrictions à cette méthode`](/fr/1.11/ref/models/querysets/#django.db.models.query.QuerySet.bulk_create), il s’agit donc de s’assurer qu’elle correspond à votre cas d’utilisation. Cela s’applique aussi aux champs [`ManyToManyFields`](/fr/1.11/ref/models/fields/#django.db.models.ManyToManyField), ce qui fait que : ``` my_band.members.add(me, my_friend) ``` …est préférable à : ``` my_band.members.add(me) my_band.members.add(my_friend) ``` …où `Bands` et `Artists` sont liés par une relation plusieurs-à-plusieurs.