Lors de l'optimisation des requêtes de base de données, quelle est la relation exacte entre le nombre de requêtes et la taille des requêtes ?

Question

Pour optimiser la vitesse d'une application, tout le monde conseille toujours de minimiser le nombre de requêtes qu'elle adresse à la base de données, en les regroupant en un plus petit nombre de requêtes qui récupèrent davantage lorsque c'est possible.

Toutefois, il faut savoir que les données transférées restent des données transférées et que ce n'est pas parce que vous effectuez moins de requêtes que les données transférées sont gratuites.

Je suis dans une situation où je peux sur-inclure sur la requête afin de réduire le nombre de requêtes, et simplement supprimer les données non désirées dans le code de l'application.

Existe-t-il une sorte de règle empirique sur le coût de chaque requête, pour savoir quand optimiser le nombre de requêtes par rapport à la taille des requêtes ? J'ai essayé de chercher sur Google des données objectives d'analyse des performances, mais je n'ai étonnamment rien trouvé de tel.

Il est clair que cette relation changera en fonction de facteurs tels que l'augmentation de la taille de la base de données, ce qui la rendra quelque peu individualisée, mais elle n'est sûrement pas individualisée au point de ne pas pouvoir en tirer une idée générale du paysage.

Je cherche des réponses générales, mais pour ce que ça vaut, j'exécute une application sur Heroku.com, ce qui signifie Ruby on Rails avec une base de données Postgres.

Answer 1

Je suis fermement ancré dans le camp du "prends seulement ce dont tu as besoin quand tu en as besoin".

La récupération de lignes supplémentaires dont vous pouvez avoir besoin ou non (par exemple, la récupération de tous les détails de la commande lors du chargement d'un écran de résumé de la commande, juste au cas où l'utilisateur descendrait dans le détail) entraîne simplement une requête beaucoup plus complexe, qui joint probablement des tables qui ne seront pas utilisées la plupart du temps.

En tant que DBA, les requêtes les plus difficiles à optimiser sont celles qui réunissent un grand nombre de tables.

Récupération d'un supplément colonnes n'est pas aussi mauvais, mais parfois le serveur peut récupérer quelques colonnes clés directement à partir d'un "index de couverture" plutôt que de devoir récupérer toutes les colonnes à partir d'une table de base.

Je pense que la clé du conseil que vous avez entendu est de ne pas faire d'allers-retours inutiles lorsque vous pouvez tout obtenir en une seule fois, au lieu de ce que vous semblez dire : " obtenir des données supplémentaires juste au cas où vous en auriez besoin ".

Les développeurs ont tellement l'habitude de tout "modulariser" qu'il n'est pas du tout inhabituel de se retrouver avec une page web finale qui fait des centaines ou même plusieurs milliers d'appels à la base de données pour charger la page web juste une fois . Nous avons un produit commercial en interne que nous avons mesuré et qui fait plus de 50 000 appels à la base de données pour une seule action.

Pour un exemple (quelque peu artificiel), disons que vous avez une page "Résumé de la commande" qui inclut un champ "total de la commande", qui est la somme de tous les éléments dans la table "Détail de la commande". Le site mauvais l'approche est :

1. Récupérer la liste des commandes à partir de la table En-tête de commande
2. Boucle programmée dans les commandes
3. Pour chaque commande, exécutez une requête pour récupérer tous les enregistrements détaillés de la commande.
4. Additionner par programme les éléments de la commande pour obtenir le total, qui est affiché dans la grille.

Ça semble fou, non ? C'est plus courant que vous ne le pensez, surtout lorsque vous intégrez une logique liée aux données dans des composants Web individuels. C'est beaucoup plus efficace :

1. Faire un appel unique à la base de données, qui une requête quelque chose comme :

   SELECT oh.OrderID, oh.OrderDate, SUM(od.LineTotal) as OrderTotal
   FROM OrderHeader oh
   INNER JOIN OrderDetail od on oh.OrderID = od.OrderID

2. Affichez les résultats dans la grille.

Answer 2

Si vous cherchez une règle empirique : chaque fois que c'est possible, filtrez, triez et paginez dans la requête de la base de données. La base de données est optimisée pour ce type d'opérations (opérations ensemblistes).

Il est préférable de réserver le code d'application à la véritable logique commerciale (et à la logique d'affichage, etc.).