Salut et bienvenue dans ce nouvel épisode du podcast de Code Garage.
Aujourd'hui, on va parler des index en base de données.
Alors cette fonctionnalité de créer des index en base de données, c'est très important.
Et on va voir que même si l'implémentation peut parfois être un peu complexe,
le concept, lui, est très simple et facile à comprendre.
Alors petit point de détail avant de commencer.
Les exemples que je vais prendre de code, on va dire, vont être basés sur du SQL.
Mais en réalité, ça marche évidemment sur des bases SQL et noSQL.
Peu importe le concept et le fonctionnement des index, pardon, reste le même.
Si on prend une requête très simple, disons tous les utilisateurs ayant pour métier le développement web
dans une base très simple, quand la base de données va rechercher le résultat de cette requête,
le système devra parcourir toutes les lignes de la table en question pour trouver toutes les occurences.
Si notre logiciel, c'est par exemple un site de covaturenage,
et bien chercher les utilisateurs par notre métier, c'est pas vraiment courant,
parce que ce n'est pas quelque chose, pas une fonctionnalité dont on va avoir besoin.
Ça signifie qu'avec beaucoup d'utilisateurs, la requête pourra être longue à s'exécuter,
mais ce n'est pas très grave parce qu'elle tournera qu'une fois de temps en temps.
Même peut-être, c'est simplement nous en tant qu'administrateur du site
pour faire des statistiques sur les métiers et les professions de nos utilisateurs.
Maintenant, si notre logiciel, c'est un réseau social professionnel, comme LinkedIn par exemple,
cette requête sera potentiellement exécutée des milliers, voire des dizaines de milliers de fois par jour,
et plus le nombre d'utilisateurs sera grand, plus elle pourra être potentiellement bloquante pour notre système.
Si on prend quelques chiffres d'exemple, admettons qu'elle est exécutée 10 000 fois par jour,
sur une base de 100 000 utilisateurs, c'est un milliard de lignes qui seront parcourues
juste pour cette requête dans la journée.
Autant dire qu'en termes de ressources, la consommation de cette simple requête, elle n'est pas anégligeée,
mais heureusement, on a justement des index pour venir à notre escouse.
Alors, c'est quoi un index ?
Ce n'est pas pour rien que le mot index, il est utilisé dans la littérature,
parce que c'est un concept inventé il y a des centaines d'années
pour faciliter la recherche d'information dans les encyclopédies.
Dans un livre, un index, ça permet de retrouver toutes les pages liées à un mot important,
souvent et un mot vraiment spécifique.
Par exemple, si on prend un index d'un livre un peu aléatoire,
on va avoir le terme journal académique
et on va avoir à côté des chiffres 262, 280, 282.
On va avoir publicité et à côté, on va avoir 36, 45, 46, 127, 145, etc.
Et je pourrais en prendre d'autres, on pourra avoir Alice au pays des merveilles,
page 152, 153.
C'est super simple ici de comprendre que l'index,
il nous permet de ne pas avoir à parcourir toutes les pages du livre,
et donc tous les mots du livre, à la recherche d'un sujet en particulier.
Ça peut être un sujet très précis comme Alice au pays des merveilles
et puis quelque chose d'un petit peu plus large comme les journaux académiques par exemple.
C'est exactement la même chose dans une base de données.
Chaque index ajouté à notre base de données,
c'est en réalité une table supplémentaire très simple
qui contient chaque valeur à indexer.
Là, en l'occurrence dans l'exemple de notre livre, c'était des sujets précis
et un pointeur vers les lignes qui contiennent la valeur en question.
Un exemple d'un index par exemple pour la profession des utilisateurs,
admettons qu'on a toujours notre base avec 100 000 utilisateurs
et donc à chaque fois, on stock l'ID de l'utilisateur,
le prénom, le nom et le métier.
Eh bien si on crée un index sur justement la colonne des métiers de nos utilisateurs,
eh bien cette table, cette table d'index va simplement avoir une colonne,
donc job, métier avec par exemple les valeurs teacher, web developer,
plumber, artistes, etc.
Et puis à côté, ça va être une liste d'ID de nos objets dans la table user.
Par exemple, pour le teacher, on va avoir les ID à un 13, 145, 750, etc.
Imaginons que 10% de nos utilisateurs soient des développeurs web.
Pour faire la même requête que tout à l'heure,
10 000 utilisateurs qui sont développeurs web pour tous les trouver,
eh bien on va plus avoir besoin de parcourir l'entierté de la base,
mais d'abord on va devoir parcourir,
eh bien imaginons qu'il y ait 50 métiers différents pour nos utilisateurs.
On va devoir parcourir ces 50 lignes de la table de notre index,
ok, mais ça on le parcourt une fois.
Et ensuite, eh bien on va récupérer tous les ID de nos utilisateurs,
on va simplement avoir à parcourir ces 10 000 lignes,
ok, si on le fait 10 000 fois par jour,
on a dit la requête tout à l'heure, on l'exécutait 10 000 fois par jour,
eh bien ça fait 10 000 fois 10 000,
ça ça fait 100 millions de lignes parcourues,
plus 50, parce qu'on a dit que notre index fait une taille de 50 lignes,
et on doit quand même les parcourir,
eh bien ça fait 100 millions et 50 lignes qui sont quand même négligeables,
ce qui fait qu'on est passé de 1 milliard à 100 millions et 50 lignes,
soit une requête 10 fois plus performante avec un seul petit index.
Alors est-ce que les index sont une solution miracle
qui peut résoudre tous nos problèmes ?
La réponse c'est non,
parce que comme avec toute chose,
eh bien il y a des avantages et des inconvénients.
D'abord on l'a dit,
un index c'est une table supplémentaire qui va contenir une ligne
pour chaque donnée indexée,
que là par exemple chaque métier ça va être une nouvelle ligne,
et donc plus le nombre de valeurs uniques est grand,
plus l'index pèsera lourd et sera potentiellement plus lent.
Tout à l'heure si à la place d'avoir 50 métiers,
eh bien on avait tous nos utilisateurs qui avaient un métier différent
et qu'il n'y avait aucun utilisateur qui avait un métier en commun,
ça veut dire qu'on n'aurait pas rendu notre quête plus rapide.
Plus le nombre de valeurs uniques est grand,
plus l'index pèsera lourd et sera potentiellement plus lent.
En plus ces index ils doivent être mis à jour à chaque fois
qu'une donnée liée à l'index est ajoutée, supprimée ou modifiée.
Ok, si un utilisateur change son travail dans notre base donnée,
eh bien on va devoir modifier la table des utilisateurs,
plus modifier l'index derrière.
On va devoir supprimer l'entrée de l'utilisateur
au niveau de l'index de développeurs web par exemple,
pour l'ajouter avec les boulangers.
Donc ça fait trois opérations en tout,
une modification, une suppression, une addition, enfin un ajout.
En clair, un bon index rendra vos requêtes les plus lourdes
beaucoup plus performantes,
et par contre un mauvais index rendra votre base globalement plus lente
pour chaque insertion, suppression ou modification
de données liées à cet index.
La réponse un peu plus détaillée,
c'est créer un index et faire un compromis.
En anglais on parle de trade-off.
On échange un petit peu de performance pendant la mise à jour des données
contre potentiellement un gros gain lors de la lecture de ces mêmes données,
pour les requêtes justement qui vont avoir un lien avec cet index.
Si les données sont mis à jour plus souvent qu'elles ne sont lues,
alors l'index c'est qu'on la mal choisit.
C'est en général une bonne pratique de concevoir les nouveaux index
au fur et à mesure de la vie de la base et des requêtes,
et de l'analyse justement de la performance de ces dernières
pour ne pas se tromper et faire une mauvaise optimisation prématurée.
On risque de plus heurter ces performances que d'avoir un quelconque gain.
J'espère que cet épisode vous en aura appris un petit peu plus
sur les index en base de données et que vous aurez compris le concept.
Moi je vous donne rendez-vous la semaine prochaine
pour un prochain épisode du podcast ou directement sur code-garage.fr
pour retrouver tous nos articles de blog, nos podcasts et évidemment tous nos cours complets.
N'hésitez pas à mettre cinq étoiles au podcast sur Spotify, Apple Podcasts,
Google Podcasts, ça nous permet de référencer un petit peu mieux le podcast chaque jour.
Donc c'est un vrai soutien.
A la semaine prochaine, salut !