Super-lents

[10 minutes]

L'entreprise GARVEL propose des figurines de super-héros à acheter en ligne sur un site Internet adossé à sa base de données. Son catalogue a atteint cette année le million de modèles. Depuis quelques temps, et la récente forte augmentation des modèles au catalogue, les performances des consultations ont beaucoup chuté, entraînant des temps d'accès lents (plusieurs secondes) et une baisse des actes d'achat.

La requête la plus utilisée par l'application Web sert à lister tous les super-héros avec toutes leurs caractéristiques, avec leurs véhicules et leurs repaires (et également toutes leurs caractéristiques) et à la trier par ordre de prix.

Modèle UML Figurines GARVEL

Soyez concis et précis dans vos réponses ; La bonne mobilisation des concepts du domaine et la clarté de la rédaction seront appréciées.

Question

Expliquer pourquoi cette requête peut poser des problèmes de performance, lorsque la base comprend de nombreux enregistrements.

Solution

  1. Les problèmes de performance sont liés au tri qui s'effectue sur le prix d'une part ;

  2. et aux jointures qui doivent être exécutées entre toutes les tables de la base pour pouvoir extraire la liste de toutes les figurines avec leurs caractéristiques.

Question

Proposer et justifier une première solution d'optimisation à mettre en œuvre qui sera utile dans tous les cas et n'aura que peu d'effets indésirables.

Solution

Une première optimisation évidente concerne l'indexation du champ prix, elle permettra d'accélérer l'opération de tri, et ses effets indésirables (ralentissement de la mise à jour et augmentation du volume disque) seront négligeables.

Question

Proposer deux solutions alternatives qui, si l'on reste en relationnel, permettraient d'améliorer considérablement les performances. Vous en poserez les avantages, inconvénients et les mesures à prendre pour contenir ces inconvénients.

Solution

  1. Si l'on devait rester en relationnel on pourrait dénormaliser le modèle de façon à ne plus avoir à faire de jointure, ou à en faire moins selon le degré de dénormalisation.

  2. Cette solution engendrerait de la redondance, qu'il faudrait contrôler par ailleurs, au niveau applicatif et/ou au niveau de la base de données, par des triggers par exemple.

  3. Une alternative serait de créer une vue matérialisée qui pré-calculerait les jointures (et le tri par la même occasion).

  4. L'inconvénient est que cette vue introduirait un décalage entre ce qui est présent dans la base et ce que l'on visualise sur le site. La calcul de la vue n'étant que de quelques secondes, on pourra envisager, sans surcharger le serveur, un nouveau calcul de la vue à chaque mise à jour des données liées, déclenchée par un trigger par exemple.

(Notons que les solutions de partitionnement ne seraient d'aucun intérêt étant donné que toutes les données, enregistrements et attributs, doivent être retournées ; à moins d'une partition sur le prix cela aura même un effet négatif étant donné qu'il faudra réaliser l'union avant le tri par prix).