Pourquoi les bases de données ne créent-elles pas automatiquement leurs propres index?
J'aurais pensé que les bases de données en sauraient suffisamment sur ce qu'elles rencontrent souvent et seraient en mesure de répondre aux demandes auxquelles elles sont soumises afin qu'elles puissent décider d'ajouter des index aux données très demandées.
Mise à jour
Ceci est désormais implémenté dans SQL Server Azure. Il génère des recommandations
et gestion des index peut être configuré pour être automatique .
Activer la gestion automatique des index
Vous pouvez configurer SQL Database Advisor pour implémenter automatiquement les recommandations. Au fur et à mesure que les recommandations deviennent disponibles, elles seront automatiquement appliquées. Comme pour toutes les opérations d'index gérées par le service, si l'impact sur les performances est négatif, la recommandation sera annulée.
Réponse originale
Certaines bases de données créent déjà (en quelque sorte) des index automatiquement.
Dans SQL Server, le plan d'exécution peut parfois inclure un opérateur Index Spool où le SGBDR crée dynamiquement une copie indexée des données. Cependant, ce spool n'est pas une partie persistante de la base de données synchronisée avec les données source et il ne peut pas être partagé entre les exécutions de requêtes, ce qui signifie que l'exécution de ces plans peut finir par créer et supprimer à plusieurs reprises des index temporaires sur les mêmes données.
Peut-être qu'à l'avenir, les SGBDR auront la capacité de supprimer dynamiquement et de créer des index persistants en fonction de la charge de travail.
Le processus d'optimisation d'indice n'est finalement qu'une analyse coûts-avantages. S'il est vrai que les humains peuvent avoir plus d'informations sur l'importance relative des requêtes dans une charge de travail en principe, il n'y a aucune raison pour que ces informations ne soient pas mises à la disposition de l'optimiseur. SQL Server dispose déjà d'un gouverneur de ressources qui permet de classer les sessions en différents groupes de charges de travail avec différentes allocations de ressources en fonction de la priorité.
Les DMV d'index manquants mentionnés par Kenneth ne sont pas destinés à être implémentés à l'aveugle car ils ne prennent en compte que les avantages d'une requête spécifique et ne tentent pas de prendre en compte le coût de l'index potentiel pour d'autres requêtes. Il ne consolide pas non plus les index manquants similaires. par exemple. la sortie de ce DMV peut signaler des index manquants sur A,B,C et A,B INCLUDE(C)
Certains problèmes actuels liés à cette idée sont
- La qualité de toute analyse automatisée qui ne crée pas réellement l'index dépendra fortement de la précision du modèle de calcul des coûts.
- Même dans le domaine de l'analyse automatisée, une solution hors ligne pourra être plus approfondie qu'une solution en ligne, car il est impératif qu'une solution en ligne n'ajoute pas de gros frais de tenue de livres au serveur en direct et n'interfère pas avec son objectif principal d'exécuter des requêtes.
- Les index créés automatiquement en réponse à la charge de travail seront nécessairement créés en réponse à des requêtes qui les auraient trouvés utiles et seront donc à la traîne des solutions qui créent les index à l'avance.
Il est probablement raisonnable de s'attendre à ce que la précision des modèles de calcul des coûts s'améliore avec le temps, mais le point 2 semble plus difficile à résoudre et le point 3 est intrinsèquement insoluble.
Néanmoins, la grande majorité des installations ne sont probablement pas dans cette situation idéalisée avec un personnel qualifié qui surveille, diagnostique et anticipe (ou du moins réagit) en permanence aux changements de charges de travail.
Le projet AutoAdmin de Microsoft Research fonctionne depuis 1996
Le but de ce projet est de rendre les bases de données auto-adaptables et auto-administrées en exploitant la connaissance de la charge de travail
La page d'accueil du projet répertorie plusieurs projets intrigants. L'une est particulièrement pertinente pour la question ici
Un autre problème intéressant se pose lorsqu'il n'y a pas de DBA disponible (par exemple une base de données intégrée ou une petite entreprise). Dans de tels scénarios, une approche de réglage d'index continu à faible contact peut devenir importante. Nous avons exploré des solutions ... [in] " An Online Approach to Physical Design Tuning " dans ICDE 2007.
Les auteurs déclarent
Avec des fonctionnalités de SGBD de plus en plus courantes, comme les index en ligne, il est intéressant d'explorer des solutions plus automatiques au problème de conception physique qui font progresser l'état de l'art.
L'article présente un algorithme
Ses principales caractéristiques sont:
- À mesure que les requêtes sont optimisées, nous identifions un ensemble pertinent d'index candidats qui amélioreraient les performances. Cette fonctionnalité permet au traitement des requêtes de se poursuivre en parallèle avec les index construits en arrière-plan.
- Au moment de l'exécution, nous suivons les avantages potentiels que nous perdons en ne disposant pas de tels index candidats et également l'utilité des index existants en présence de requêtes, de mises à jour et de contraintes d'espace.
- Après avoir rassemblé suffisamment de "preuves" qu'un changement de conception physique est bénéfique, nous déclenchons automatiquement des créations ou des suppressions d'index.
- La nature en ligne de notre problème implique que nous serons généralement à la traîne des solutions optimales qui connaissent l'avenir. Cependant, en mesurant soigneusement les preuves, nous nous assurons que nous ne souffrons pas de décisions "tardives" de manière significative, limitant ainsi le montant de la perte encourue.
L'implémentation de l'algorithme permet la limitation en réponse aux changements de charge du serveur et peut également annuler la création d'index si, lors de la création, la charge de travail change et les bénéfices attendus tombent en dessous du point où cela est jugé utile.
La conclusion des auteurs sur le sujet de Réglage physique en ligne versus traditionnel.
Les algorithmes en ligne de ce travail sont utiles lorsque les administrateurs de base de données ne sont pas sûrs du comportement futur de la charge de travail ou n'ont aucune possibilité de faire une analyse ou une modélisation complète. Si un administrateur de base de données dispose d'informations complètes sur les caractéristiques de la charge de travail, une analyse statique et un déploiement par les outils existants (par exemple, [2, 3]) seraient une meilleure alternative.
Les conclusions ici sont similaires à celles d'un autre article Autonomous Query-driven Index Tuning
Notre approche ne peut pas battre le conseiller d'index si toute la charge de travail est connue à l'avance. Cependant, dans des environnements dynamiques avec des charges de travail évolutives et changeantes, l'approche basée sur les requêtes produit de meilleurs résultats.
La conception de l'index que vous mettez en place est plus un art qu'une science. Le SGBDR n'est pas assez intelligent pour prendre des charges de travail courantes et concevoir une stratégie d'indexation intelligente. C'est à l'intervention humaine (lire: DBA) d'analyser la charge de travail et de déterminer quelle est la meilleure approche.
S'il n'y avait pas de pénalité d'avoir des index, ce serait une approche au fusil à pompe que d'ajouter simplement un nombre infini d'index. Mais parce que la modification des données (INSERTS, UPDATES et DELETES) a un impact sur les index activés d'une table, il y aura alors cette surcharge variable de ces index.
Il faut une conception et une stratégie humaines pour créer intelligemment des index qui maximiseront les performances de lecture, tout en ayant le moins de surcharge de modification de données.
En fait, certaines bases de données le font. Par exemple, BigTable de Google et SimpleDB d'Amazon créent automatiquement des indices (bien que les SGBDR ne soient pas non plus) . Il y a aussi au moins un moteur SGBDR MySQL qui fait cela. SQL Server aussi garde une trace des indices qu'il pense que vous devriez créer , bien qu'il n'aille pas jusqu'à les créer réellement.
Le problème est étonnamment difficile à corriger, il n'est donc pas étonnant que la plupart des bases de données ne les créent pas automatiquement (BigTable/SimpleDB s'en tirer car elles n'autorisent pas les jointures arbitraires, ce qui rend les choses beaucoup plus faciles) . De plus, la création d'indices à la volée est un processus long qui nécessite un accès exclusif à l'ensemble de la table - ce n'est certainement pas quelque chose que vous souhaitez voir se produire lorsque la table est en ligne.
Cependant, étant donné le nombre d'applications Web LAMP qui ont été écrites par des amateurs qui ne savent même pas ce qu'est un index , je pense toujours que cette fonctionnalité serait bénéfique pour certaines personnes.
Bien qu'il existe déjà des réponses détaillées, elles semblent contourner la vraie réponse: Les index ne sont pas toujours souhaitables.
Avec l'analogie des voitures mentionnée dans les commentaires, vous feriez mieux de dire pourquoi toutes les voitures ne sont-elles pas équipées de packs de sports extrêmes? C'est en partie des dépenses, mais c'est aussi dû au fait que beaucoup de gens n'ont pas besoin ou ne veulent pas de pneus à profil bas et d'une suspension rigide; c'est inutilement inconfortable.
Alors peut-être que vous avez 1 000 lectures pour chaque insert, pourquoi ne pas avoir un index créé automatiquement? Si le tableau est large et les requêtes variées, pourquoi ne pas en avoir plusieurs? Peut-être que le commit est critique en temps et que les lectures ne le sont pas; dans les circonstances, il peut être inacceptable de ralentir votre insert. Peut-être que vous travaillez avec un espace disque limité et que vous ne pouvez pas vous permettre d'avoir des index supplémentaires dans l'espace dont vous disposez.
Le fait est que les index ne sont pas créés automatiquement car ils ne sont pas la réponse à tout. La conception d'index ne consiste pas simplement à dire "hé, cela accélérera mes lectures", il y a d'autres facteurs à considérer.
Ils peuvent analyser les requêtes passées et suggérer/créer des index, mais cela ne fonctionne pas de manière optimale car les index atteignent un équilibre pour accélérer ce que vous souhaitez optimiser moyennant un coût et le serveur ne peut pas connaître vos intentions.