Le réglage des requêtes doit-il être proactif ou réactif?

En tant que développeur de logiciels et aspirant DBA, j'essaie d'intégrer les meilleures pratiques lorsque je conçois mes bases de données SQL Server (99% du temps, mon logiciel se trouve au-dessus de SQL Server). Je fais le meilleur design possible avant et pendant le développement.

Mais, comme tout autre développeur de logiciels, il y a des fonctionnalités supplémentaires, des bogues et juste un changement d'exigences qui nécessite des objets de base de données modifiés / créés.

Ma question est la suivante: le réglage des requêtes doit-il être proactif ou réactif? En d'autres termes, quelques semaines après une modification importante du code / de la base de données, dois-je simplement réserver une journée pour vérifier les performances des requêtes et les ajuster en fonction de cela? Même s'il semble fonctionner correctement ?

Ou devrais-je simplement être conscient que les performances inférieures à la moyenne devraient être une vérification de la base de données et revenir au tableau proverbial?

L'optimisation des requêtes peut prendre beaucoup de temps et, selon la conception initiale de la base de données, elle pourrait être très avantageuse. Je suis curieux de connaître le modus operandi accepté.

Les deux, mais surtout proactifs

Il est important de tester pendant le développement par rapport à des volumes et une qualité de données réalistes. Il est incroyablement courant qu'une requête s'exécute sur un développeur 100 ou 1000 lignes, puis tombe à plat avec 10 millions de lignes de production.

Il vous permet également de prendre des notes sur "l'index peut aider ici". Ou "revisitez-moi". Ou "sera corrigé avec la nouvelle fonctionnalité xxx dans la prochaine version DB".

Cependant, quelques requêtes ne résisteront pas à l'épreuve du temps. La distribution des données change ou elle devient exponentielle car l'optimiseur décide d'utiliser un type de jointure différent. Dans ce cas, vous ne pouvez que réagir.

Dire que, pour SQL Server au moins, les diverses requêtes DMV "index manquant" et "requête la plus longue" peuvent indiquer des zones problématiques avant l'appel téléphonique

Edit: pour clarifier ...

Proactif ne signifie pas régler chaque requête maintenant. Cela signifie régler ce dont vous avez besoin (exécuter fréquemment) à un temps de réponse raisonnable. Ignorez principalement les requêtes de rapport hebdomadaires du dimanche à 3 heures du matin.

OK, je vais mordre et prendre une vue contraire. Tout d'abord, je dirais que vous ne devriez jamais commencer par faire quelque chose qui, vous le savez, vous causera des ennuis. Si vous souhaitez appeler cela en appliquant les meilleures pratiques, allez-y. C'est aussi loin d'être proactif.

Après cela, vous perdez du temps (et de l'argent), alors continuez et livrez votre produit. Au lieu de prendre une tonne de requêtes de réglage au moment de la conception qui peuvent ou non se révéler être des goulots d'étranglement, utilisez ce temps pour des tests supplémentaires, y compris des tests de charge.

Lorsque vous découvrez que quelque chose ne fonctionne pas selon vos spécifications de conception, ou si quelque chose tombe dans les 10% ou 20% inférieurs de la liste des temps de réponse de votre profileur, investissez le temps dont vous avez besoin pour peaufiner quoi que ce soit. cassé.

Dans un monde parfait, tout serait parfaitement conçu dès le départ et développé à l'aide d'une séquence de construction logique. Dans le monde réel, il y a des contraintes de budget et de temps et vos données de test peuvent ne pas ressembler à vos données de production. Pour cette raison, je dis utiliser le bon sens pour éviter les problèmes de manière proactive mais concentrer vos ressources limitées en ajustant les choses qui se révèlent être de vrais problèmes au lieu de dépenser du temps et de l'argent que vous n'avez probablement pas pour rechercher des problèmes imaginaires ou potentiels.

Vous allez faire 3 types de réglages, 1 réactif et 2 proactif.

Réactif

À l'improviste, certaines requêtes commencent à vous poser des problèmes. Cela peut être dû à un bogue ou une fonctionnalité d'application, à une table dépassant les attentes, à un pic de trafic ou à l'optimiseur de requête devenant "créatif". Cela pourrait être une affaire de type `` oh-merde-le-site '' du milieu de la nuit, ou cela pourrait être en réponse à la lenteur du système de nature non critique. Quoi qu'il en soit, le caractère déterminant de l'accord réactif est que vous avez déjà un problème . Inutile de dire que vous voulez en faire le moins possible. Ce qui nous amène à ...

Proactif

Type 1: Maintenance de routine

Selon une sorte de calendrier, tous les quelques mois ou semaines, selon la fréquence à laquelle votre schéma change et la vitesse de croissance de vos données, vous devez examiner la sortie des outils d'analyse des performances de votre base de données (par exemple, les rapports AWR pour les DBA Oracle). Vous recherchez des problèmes naissants, c'est-à-dire des choses qui sont sur le point d'exiger un réglage réactif, ainsi que des fruits à faible pendaison, des articles qui ne risquent pas de causer des problèmes bientôt, mais qui peuvent s'améliorer avec peu d'effort dans l'espoir de prévenir loin -les problèmes futurs. Le temps que vous devriez y consacrer dépendra du temps dont vous disposez et de quoi d'autre vous pourriez le dépenser, mais le montant optimal n'est jamais nul. Cependant, vous pouvez facilement réduire le montant que vous devez dépenser en faisant plus de ...

Type 2: conception appropriée

L'avertissement de Knuth contre "l'optimisation prématurée" est largement connu et dûment respecté. Mais la bonne définition de «prématuré» doit être utilisée. Certains développeurs d'applications, lorsqu'ils sont autorisés à écrire leurs propres requêtes, ont tendance à adopter la toute première requête qu'ils rencontrent qui est logiquement correcte, et ne prêtent aucune attention aux performances, présentes ou futures. Ou ils peuvent tester par rapport à un ensemble de données de développement qui n'est tout simplement pas représentatif de l'environnement de production (astuce: ne faites pas cela! Les développeurs doivent toujours avoir accès à des données réalistes pour les tests.). Le fait est que le moment approprié pour régler une requête est quand elle est déployée pour la première fois, pas quand elle apparaît sur une liste de SQL peu performant, et certainement pas quand elle cause un problème critique.

Alors, qu'est-ce qui pourrait être considéré comme une optimisation prématurée du terrain DBA? Au sommet de ma liste serait de sacrifier la normalisation sans besoin démontré. Bien sûr, vous pouvez conserver une somme sur une ligne parent plutôt que de la calculer lors de l'exécution à partir des lignes enfants, mais en avez-vous vraiment besoin? Si vous êtes Twitter ou Amazon, la dénormalisation stratégique et le pré-calcul peuvent être vos meilleurs amis. Si vous concevez une petite base de données de comptabilité pour 5 utilisateurs, la bonne structure pour faciliter l'intégrité des données doit être une priorité absolue. D'autres optimisations prématurées sont également une question de priorité. Ne passez pas des heures à peaufiner une requête qui s'exécute une fois par jour et prend 10 secondes, même si vous pensez pouvoir la réduire à 0,1 seconde. Vous avez peut-être un rapport qui dure 6 heures par jour, mais explorez-le comme un travail par lots avant d'investir du temps dans le réglage. N'investissez pas dans une instance de rapport répliquée en temps réel distincte si votre charge de production ne dépasse jamais 10% (en supposant que vous puissiez gérer la sécurité).

En testant des données réalistes, en prenant des hypothèses éclairées sur les modèles de croissance et de trafic (plus les allocations pour les pics) et en appliquant vos connaissances sur les bizarreries de l'optimiseur de votre plate-forme, vous pouvez déployer des requêtes qui s'exécutent (presque) de manière optimale non seulement maintenant, mais à l'avenir et dans des conditions moins qu'idéales. Lorsque vous appliquez les techniques appropriées, les performances des requêtes peuvent être prédites avec précision et optimisées (dans le sens où chaque composant est aussi rapide qu'il doit l'être).

(Et pendant que vous y êtes, apprenez les statistiques! )

Dans un monde parfait, tout réglage se ferait de manière proactive dans la phase de conception et rien ne serait réactif, mais le monde n'est pas parfait. Vous constaterez que les données de test ne sont parfois pas représentatives, les cas de test auront été manqués, les charges seront différentes de manière inattendue et il y aura des bogues qui causent des problèmes de performances. Ces situations peuvent nécessiter un réglage réactif, mais cela ne signifie pas que le réglage réactif est préférable. L'objectif devrait toujours être de les attraper à l'avance.

Votre planification d'un réglage rétroactif est très pragmatique. Lorsque vous testez, vous devez documenter les délais et le débit attendus et, parfois, intégrer une analyse qui vous permet de savoir quand les processus de production ne répondent pas aux spécifications de conception. De cette façon, vous pourrez peut-être identifier à l'avance quel code doit être réglé. Vous pouvez alors déterminer non seulement quel est le problème, mais pourquoi vous ne l'avez pas détecté dans la phase de conception / test.

Pour moi, les tests de performance ont toujours fait partie du processus de développement. Vous souhaitez modifier ce tableau, modifier ce rapport, ajouter cette fonctionnalité? Dans le cadre des tests, vous vous assurez de pouvoir comparer les performances individuelles et globales aux références connues et / ou par rapport aux exigences (par exemple, certains rapports s'exécutent en arrière-plan ou sont autrement automatisés, donc les performances - ou plutôt la vitesse - de chaque requête dans le système n'est pas toujours la priorité absolue).

À mon humble avis, cela ne devrait pas du tout être un processus réactif - vous ne devriez jamais attendre qu'un changement provoque un problème de performance en production pour commencer à y réagir. Lorsque vous effectuez la modification dans dev / test, etc., vous devez tester ces modifications avec des données similaires sur un matériel similaire avec les mêmes applications et des modèles d'utilisation similaires. Ne laissez pas ces changements se précipiter vers la production et vous surprendre. Cela se produira presque toujours quand il n'est pas pratique de passer une journée à régler - budget pour ce temps de réglage bien à l'avance.