Est-ce une optimisation prématurée d'ajouter des index de base de données?

Un de mes collègues aujourd’hui a suggéré que nous examinions toutes les requêtes de notre application et que nous ajoutions des index en conséquence.

Je pense que cette optimisation est prématurée car notre application n'est même pas encore publiée. J'ai suggéré de surveiller les requêtes lentes une fois que nous sommes en ligne, puis d'ajouter des index en conséquence.

Quel est le consensus général lors de la conception de votre base de données, devez-vous ajouter un index correspondant chaque fois que vous écrivez une nouvelle requête? Ou vaut-il mieux surveiller et voir comment ça se passe?

L'optimisation prématurée consiste à "optimiser" quelque chose en raison d'un sentiment vague et intuitif qui, vous le savez, sera probablement lent, en particulier au détriment de la lisibilité et de la maintenabilité du code . Cela ne signifie pas délibérément ne pas suivre les bonnes pratiques bien établies en matière de performance.

Parfois, c'est une ligne difficile à tracer, mais je dirais certainement que ne pas ajouter d'index avant de commencer, c'est une optimisation trop tardive . cela punira les utilisateurs précoces - vos utilisateurs les plus enthousiastes et les plus importants - et leur donnera une vision négative de votre produit, qu’ils répartiront ensuite dans des revues, des discussions, etc. bonne idée, mais je m'assurerais de le faire au plus tard à la version bêta.

surveiller les requêtes lentes une fois que nous allons vivre

Parce que rien ne dit qualité comme faire souffrir vos utilisateurs pour un manque de design!

Vous devez savoir quelles requêtes ont besoin d’index lors de la conception des tables, ainsi que des colonnes interrogées dans les clauses where et les jointures. Celles-ci devraient déjà être indexées car ce qui pourrait ne pas être apparent dans un environnement réel peut devenir rapidement apparent lorsque la charge ou les données stockées augmentent. Ce que vous ne voulez pas faire quand cela se produit, c'est de claquer des index sur chaque requête "lente", vous obtiendrez un index sur tout.

"Optimisation prématurée", dans son sens péjoratif, signifie une optimisation coûteuse qui pourrait ne pas être nécessaire. Cela ne signifie pas que toutes les optimisations mises en œuvre avant le dernier point possible pour éviter la faillite!

En particulier, il est légitime d’optimiser à partir de tests de performance avant la mise en production, afin de vous assurer que vous pourrez répondre à certaines exigences sensibles (bien qu'approximatives) selon lesquelles votre application ne doit pas aspirer.

Au minimum, vous devez charger votre base de données avec une quantité plausible de données de test et vérifier la réactivité de votre application. Ce n'est pas prématuré, car vous savez que cela va arriver, et il va capturer toutes les requêtes qui déclenchent des analyses absurdement lentes. Comme AE le dit dans un commentaire:

Utilisez des index pour éviter une analyse complète de la table pour toute requête que l'utilisateur final effectuera habituellement en temps réel.

Du moins, pour les tables dont l'utilisation est prévue.

En guise de raccourci, si vous avez une expérience significative du moteur de base de données et que vous avez déjà planifié les tests lorsque vous écrivez la première copie du code, vous savez souvent, sans même l'exécuter, que la requête que vous êtes l'écriture sera trop lente sans index. Bien sûr, vous êtes libre de faire semblant de ne pas savoir et de regarder le test échouer avant d’ajouter l’index pour le faire passer, mais il n’ya aucune raison pour que du code défectueux (parce qu’il ne répond pas) soit mis en ligne.

Je pense que cette optimisation est prématurée car notre application n'est même pas encore publiée. J'ai suggéré de surveiller les requêtes lentes une fois que nous sommes en ligne, puis d'ajouter des index en conséquence.

Vous ne pouvez pas traiter vos utilisateurs finaux et votre environnement de production comme une assurance qualité. En d'autres termes, vous dites que vous le découvrirez en production. Je ne pense pas que ce soit la bonne façon, et je vois que cette approche va terriblement mal tous les jours .

N'oubliez pas une chose, vous ne pouvez pas la peindre avec un pinceau large.

Quelle est votre charge de travail commune ?

Cela peut paraître évident ou ennuyeux, mais c’est important dans la pratique. Si vous avez 10 requêtes qui constituent 98% de votre charge de travail (assez commun, croyez-le ou non), ma recommandation serait une analyse sérieuse avant la production . Avec des données réalistes et représentatives, assurez-vous que ces 10 requêtes sont aussi performantes que possible ( parfait est une perte de temps précieux et presque impossible à réaliser).

Pour les 200 autres requêtes qui composent les 2% de la charge de travail , ce sont celles qui ne valent probablement pas la peine de faire beaucoup d'efforts et qui constitueront la solution idéale pour résoudre les problèmes de production. C'est aussi une réalité et pas une très mauvaise chose. Mais cela ne signifie pas ignorer les meilleures pratiques en matière d'indexation ou émettre des hypothèses sur la récupération des données.

Il est courant et utile de déterminer les performances de la base de données avant la production. En fait, il existe une position relativement commune pour ce type de choses, appelée DBA de développement .

Mais...

Certains vont trop loin et deviennent fous en ajoutant des index "au cas où". Quelqu'un recommande-t-il un index manquant? Ajoutez-le et quatre autres variations. Aussi une mauvaise idée. Vous devez non seulement penser à la récupération de vos données, mais également à la modification des données. Plus vous avez d'index sur une table, en général, plus vous avez de temps système lorsque vous modifiez des données.

Comme la plupart des choses, il existe un bon équilibre.

Comme une petite note amusante ... La pluralisation de "Index"

Les "indices" sont pour les financiers

Les "index" sont pour nous

Non, ce n'est pas une optimisation prématurée, mais il faut le faire correctement, comme devrait l'être toute optimisation.

Voici ce que je ferais:

1. Chargez la base de données avec suffisamment de données de test pour imiter une charge de production. Vous ne pouvez pas obtenir cette précision à 100% mais c'est très bien: mettez juste assez de données. Une table a-t-elle une quantité fixe de données? Chargez-le. Avez-vous une table contenant beaucoup de données, par exemple une table contenant des questions sur ce site? Chargez quelques millions d'enregistrements même s'il ne s'agit que de données factices.
2. Activer le profilage sur votre serveur de base de données.
3. Décrochez l'application en utilisant une combinaison de scripts automatisés (fournit du volume) et d'utilisateurs réels (ils savent comment casser des choses).
4. Passez en revue les données de profilage. Des requêtes spécifiques sont-elles lentes? Vérifiez les plans expliqués et voyez si le serveur de base de données vous dit qu'il veut un index mais qu'il n'existe pas.

Les serveurs de base de données sont des logiciels complexes et intelligents. Ils peuvent vous dire comment les optimiser si vous savez écouter.

Les clés doivent mesurer les performances avant et après l'optimisation et laisser la base de données vous dire ce dont elle a besoin .

Suivre des modèles éprouvés pour des problèmes connus (comme trouver un enregistrement par son ID) n’est pas prématuré. C'est juste raisonnable.

Cela dit, les indices ne sont pas toujours une affaire simple. Pendant la phase de conception, il est souvent difficile de savoir à quels index votre trafic dépendra et quelles sont les opérations d'écriture goulot d'étranglement. Je préconiserais donc de tirer parti de certaines meilleures pratiques "évidentes" en matière de conception de schéma (utilisez des PK appropriées pour les modèles de lecture / écriture conçus et les FK d'index); mais, ne mettez pas d'index sur quoi que ce soit d'autre jusqu'à ce que vos tests de stress l'exigent.

Lorsque votre application est publiée, il est trop tard.

Mais tout processus de développement approprié devrait inclure des tests de performance.

Utilisez les résultats de vos tests de performance pour choisir les index à ajouter et vérifiez leur efficacité en répétant les tests de performance.

Bien que je ne pense pas que toutes les requêtes doivent être optimisées, les index font tellement partie du SGBDR qu’ils doivent être pris en compte avant la publication. Lorsque vous exécutez une requête, contrairement aux autres formes de programmation, vous ne dites pas au système comment l'exécuter. Ils développent leurs propres plans et le basent presque toujours sur la disponibilité d'un index. La composition et le volume des données seront également pris en compte ultérieurement.

Voici quelques points à considérer:

1. Il y a des questions que vous devez identifier dans votre développement initial et que vous savez être utilisées fréquemment. Concentrez-vous sur eux.
2. Il y aura des requêtes lentes. En les indexant d'abord, vous pouvez ensuite déterminer si les performances ne sont toujours pas assez rapides, puis envisager une nouvelle conception (la dénormalisation peut être prématurée). Je préférerais le faire avant une sortie. Personne ne veut d'un système où il faut 10 minutes pour trouver quelque chose dans l'inventaire.
3. Les index peuvent améliorer les performances des requêtes mais ne doivent pas entraver la modification des données.
4. De nombreux systèmes ont des outils pour analyser vos requêtes, alors n’ayez pas peur de les utiliser.

Après votre examen initial, vous devez suivre quelques considérations pour savoir quand vous devez réexaminer ceci de nouveau et comment vous allez pouvoir collecter les informations à cette fin (surveiller l’utilisation, obtenir des copies des données du client, etc.).

Je réalise que vous ne voulez pas optimiser prématurément, mais il est presque certain que vos performances seront médiocres sans indexer votre base de données. En éliminant ce problème, vous pouvez déterminer s’il existe d’autres domaines qui posent des problèmes de performances.

Cela dépend également du nombre d'utilisateurs que vous attendez. Vous devez absolument faire des tests de charge et vous assurer que votre base de données peut suivre 10 à 100 à 1000 demandes simultanées. Encore une fois, cela dépend du trafic que vous attendez et des zones que vous prévoyez utiliser plus que d’autres.

En général, je voudrais ajuster les zones sur lesquelles l’utilisateur doit s’approcher le plus en premier. Ensuite, je réglerais tout ce qui est lent du point de vue de l'expérience utilisateur. Chaque fois que l'utilisateur doit attendre quelque chose, il a une mauvaise expérience et peut être refusé. Pas bon!

Il est recommandé d’identifier les colonnes qui ont définitivement besoin d’un index lors d’une analyse initiale. Il existe un risque réel de dégradation progressive ou imprévue des performances de la production lorsque la taille de la base de données augmente si vous n'avez absolument aucun index. La situation que vous souhaitez éviter est celle où une requête fréquemment exécutée nécessite d'analyser un grand nombre de lignes de table. Il n'est pas prématuré d'optimiser l'ajout d'indices aux colonnes critiques, car vous disposez de la plupart des informations nécessaires et dont les différences de performances potentielles sont importantes (ordres de grandeur). Il existe également des situations dans lesquelles l'avantage des indices est moins clair ou plus dépendant des données - vous pouvez probablement différer la décision pour certains de ces cas.

Certaines questions que vous devez poser sont les suivantes:

• Quelles sont les limites de conception pour la taille de chaque table?

Si les tables doivent toujours être petites (disons <100 lignes), il ne s'agit pas d'un sinistre si la base de données doit analyser toute la table. Il peut être avantageux d’ajouter un indice, mais cela nécessite un peu plus d’expertise ou de mesure pour déterminer.

• Quelle est la fréquence d'exécution de chaque requête et quel est le temps de réponse requis?

Si la requête est rarement exécutée et ne nécessite pas de temps de réponse strict (par exemple, la génération de rapports) et que le nombre de lignes n'est pas énorme, il est probablement relativement prudent de différer l'ajout d'index. Encore une fois, l'expertise ou la mesure peut aider à dire si cela va être bénéfique.

• La requête nécessite-t-elle de regarder la table avec autre chose que la clé primaire? Par exemple, filtrer par plage de dates, joindre sur une clé étrangère?

Si ces requêtes sont exécutées fréquemment et touchent des tables comportant de nombreuses lignes, vous devez sérieusement envisager l’ajout préventif d’un index. Si vous n'êtes pas sûr que ce soit le cas pour une requête, vous pouvez renseigner la base de données avec une quantité réaliste de données, puis consultez le plan de requête.