Cet article est partagé par la communauté Huawei Cloud « Traitement de pagination des données volumineuses dans les applications » par Ma Le.
Introduction
L’affichage de grandes quantités de données a toujours été considéré comme un problème à résoudre. Une idée classique consiste à les afficher et à les traiter par lots.
1 Traitement des clés étrangères lors d'une requête
Si le modèle utilise des clés étrangères dans le modèle Django, définissez l'opération associée via on_delete.
CASCADE : Fonctionnement en cascade. Si les données de la clé étrangère sont supprimées, ces données seront également supprimées. PROTÉGER : Protégé. Tant que ces données font référence aux données de la clé étrangère, les données de la clé étrangère ne peuvent pas être supprimées. Si elles sont supprimées de force, le framework Django signalera une erreur. SET_NULL : défini sur NULL. Si les données de la clé étrangère sont supprimées, ces données sont définies sur NULL, à condition que ces données puissent être définies sur NULL. SET_DEFAULT : définissez la valeur par défaut. Si les données de clé étrangère sont supprimées, définissez la valeur de ces données par défaut, à condition qu'il existe une valeur par défaut. Fonction SET() : Si les données de la clé étrangère sont supprimées, la valeur de la fonction SET sera obtenue comme valeur de la clé étrangère. La fonction Set() peut accepter un objet appelable et la valeur de retour de l'objet appelable est définie comme résultat. DO_NOTHING : Aucune action n'est entreprise, tout dépend du comportement au niveau de la base de données.
Contraintes au niveau de la base de données :
PESTRICT : option par défaut. Si vous souhaitez supprimer des enregistrements de la table parent, si la table enfant a des enregistrements associés, la suppression n'est pas autorisée. NOACTION : Idem que ci-dessus, détectez d'abord les clés étrangères CASCADE : lorsque la table parent est supprimée et mise à jour, les opérations d'association de table enfant sont également supprimées et mises à jour. SET NULL : lorsque la table parent est supprimée ou mise à jour, la table enfant définit le champ de clé étrangère de l'enregistrement associé sur null, il ne peut donc pas être nul lors de la conception de la table enfant.
Ces outils de méthode de clé étrangère peuvent aider les utilisateurs à gérer les tâches de requête liées à plusieurs tables.
1.1 Comment interroger la pagination dans Django
Dans les applications avec des requêtes de pagination, les requêtes incluant LIMIT et OFFSET sont très courantes, et presque toutes auront une clause ORDER BY.
Si vous utilisez le tri par index, cela sera très utile pour optimiser les performances, sinon le serveur devra effectuer beaucoup de tri de fichiers.
Un problème haute fréquence est que la valeur de décalage est trop grande. Si la requête ressemble à LIMIT 10 000, 20, 10 020 lignes seront générées et les 10 000 lignes précédentes seront supprimées, ce qui coûte très cher.
sélectionnez * dans l'ordre du tableau par limite d'identifiant 10000, 20 ;
C'est très simple. La signification de cette instruction est d'interroger 10 000+20 enregistrements, de supprimer les 10 000 premiers enregistrements et de renvoyer les 20 derniers enregistrements.
Il ne fait aucun doute que cette requête peut réaliser une pagination, mais plus la valeur de 10 000 est grande, plus les performances de la requête sont faibles, car MySQL doit analyser tous les 10 000 + 20 enregistrements.
En supposant que toutes les pages sont consultées à la même fréquence, une telle requête analysera en moyenne la moitié de la table de données. Pour les optimiser, vous pouvez limiter le nombre maximum de pages accessibles dans les vues paginées, ou rendre plus efficaces les requêtes batch volumineuses.
Lorsqu'une table contient de nombreuses données qui répondent aux conditions de requête, nous n'avons souvent pas besoin de toutes les supprimer en même temps, ce qui constituera un défi majeur en termes d'efficacité des requêtes ou de performances du serveur : par exemple, dans le centre commercial le plus simple, supposons qu'il y ait 10 000 données dans le centre commercial, mais nous ne pouvons voir qu'une seule page à la fois sur le front-end.
sélectionnez * dans le tableau où xxx="xxx" limite 10 ;
Cela signifie interroger 10 données qui remplissent les conditions.
sélectionnez * dans le tableau où xxx="xxx" limite 10 décalage 10 ;
Cela signifie une pagination, une interrogation des 11e à 20e données qui remplissent les conditions.
Ou interrogez en spécifiant l'identifiant maximum
sélectionnez * dans la table où id > #max_id# ordre par limite d'identifiant n ;
Cette requête renverra également les n derniers enregistrements, mais il n'est pas nécessaire d'analyser les m premiers enregistrements comme la méthode 1, mais l'identifiant maximum (ou identifiant minimum) de la requête précédente (page précédente) doit être obtenu dans chaque requête, ce qui est plus couramment utilisé.
Bien sûr, le problème avec cette requête est que si l'ID maximum n'est pas continu, nous ne pourrons peut-être pas obtenir l'ID. Par exemple, si nous sommes actuellement à la page 3 et que nous devons interroger les données sur la page 5, ce sera le cas. ne fonctionne pas.
Ou via une sous-requête, filtrez d’abord les 10 000 premiers, recherchez l’ID le plus grand, puis sélectionnez les 20 restants qui répondent aux exigences.
sélectionnez * dans la table où id > (sélectionnez l'identifiant dans l'ordre de la table par limite d'identifiant m, 1) limite n ;
Cette requête analyse également l'ID du champ via une sous-requête, car elle ne nécessite pas d'association de table, mais constitue une simple comparaison. Il s'agit d'une utilisation recommandée lorsque l'ID maximum sur la page précédente n'est pas connu.
La méthode de connexion gauche-droite elle-même peut avoir de moins bonnes performances.
Il existe également les sous-requêtes suivantes, joindre des tables, ajouter des index pour localiser rapidement les tuples, puis lire les tuples
SELECT * FROM table WHERE id <= (SELECT id FROM table ORDER BY id DESC LIMIT (page-1)*pagesize ORDER BY id DESC LIMIT pagesize)
rest_framework a un module d'opération de pagination intégré. Appliquons-le à des fonctions spécifiques dans employ/views.py.
à partir de rest_framework.pagination importer PageNumberPagination @api_view(['GET', 'POST']) @permission_classes([PermissionPersonnalisée]) def blog_api_view(requête) : """""" si request.method == "GET": paginateur = PageNumberPagination() # paginator.page_size = 1 paramètre nous affichons seulement 1 élément par page. paginateur.page_size = 2 task_objects = EmployeeSign.objects.all() résultat = paginator.paginate_queryset (task_objects, requête)
Si la recherche de personne n'est pas utilisée, tous les messages seront affichés sur la même page.
sérialiseur = TaskSerializer (résultat, plusieurs = True) renvoyer la réponse (serializer.data)
Accédez aux données de pagination. L'interface par défaut http://127.0.0.1:2001/api/tasks/ est la pagination 1.
http://127.0.0.1:2001/api/tasks/?page=1 #2,3,4...
2 Résumé
Encore une fois, dans les applications avec des requêtes paginées, les requêtes impliquant LIMIT et OFFSET sont très courantes, et presque toutes auront une clause ORDER BY. Si vous utilisez le tri par index, cela sera très utile pour optimiser les performances, sinon le serveur devra effectuer beaucoup de tri de fichiers.
Un problème haute fréquence est que la valeur de décalage est trop grande. Si la requête ressemble à LIMIT 10 000, 20, 10 020 lignes seront générées et les 10 000 lignes précédentes seront supprimées, ce qui coûte très cher.
En supposant que toutes les pages sont consultées à la même fréquence, une telle requête analysera en moyenne la moitié de la table de données.
Pour les optimiser, vous pouvez limiter le nombre maximum de pages accessibles dans les vues paginées, ou rendre les requêtes volumineuses plus efficaces.
Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~
La première mise à jour majeure de JetBrains 2024 (2024.1) est open source. Même Microsoft prévoit de la payer. Pourquoi est-elle encore critiquée pour son open source ? [Récupéré] Le backend de Tencent Cloud s'est écrasé : un grand nombre d'erreurs de service et aucune donnée après la connexion à la console. L'Allemagne doit également être "contrôlable de manière indépendante". Le gouvernement de l'État a migré 30 000 PC de Windows vers Linux deepin-IDE et a finalement réussi démarrage ! Visual Studio Code 1.88 est sorti. Bon gars, Tencent a vraiment transformé Switch en une "machine d'apprentissage pensante". Le bureau à distance RustDesk démarre et reconstruit le client Web. La base de données de terminaux open source de WeChat basée sur SQLite, WCDB, a reçu une mise à niveau majeure.