Salut, moi c'est Nicolas Brondin-Bernard et bienvenue dans ce nouvel épisode de Code Garage.
Code Garage, qu'est-ce que c'est ?
C'est une plateforme de formation pour les devs qui veulent continuer à se former
et ça pour le prix de 19,99€ par mois.
C'est un petit peu le Netflix de la formation pour les devs.
Aujourd'hui, dans cet épisode du podcast, on va parler de base de données
et plus précisément de réplications et de fragmentations.
Donc si vous êtes déjà plongé dans la documentation de base de données,
que soit d'ailleurs du relationnel ou du non relationnel,
vous avez sûrement aperçu ces deux termes, donc réplication et on parle souvent de sharding.
Sharding, c'est simplement la version anglaise pour fragmentation.
Mais aujourd'hui, on va voir ce que ça signifie réellement,
sans trop rentrer dans les détails, mais pour que vous compreniez le concept et bien les différences.
Donc à quoi ça sert ?
La principale raison pour choisir ces stratégies de sauvegarde de données,
c'est de mettre en place un scaling horizontal, donc un passage à l'échelle horizontal.
En fait, pour la plupart des systèmes informatiques,
il sera moins cher d'investir dans deux petites machines
qui ont, on va dire, la moitié des performances,
qui se partagent la moitié des performances,
plutôt que dans une grosse machine qui aura toutes les performances.
Voilà, ça, c'est en termes de composants, de choses comme ça, c'est en général moins cher.
Et c'est pareil du coup pour les bases de données.
En fait, quand votre application est grossie à un tel point que le système commence à ralentir,
qui appuie à cette performance sur la machine ou est installée votre base de données,
il est temps d'arrêter de faire grossir la machine,
ce qu'on appelle le passage à l'échelle vertical,
et de commencer à diviser la charge sur plusieurs machines,
un passage à l'échelle horizontal.
Donc la méthode numéro 1, c'est ce qu'on appelle la réplication.
Cette stratégie consiste tout simplement à faire coopérer un certain nombre de machines,
on va dire 3 pour l'exemple,
et dans promouvoir une au rang de machines primaires et les autres au rang de machines secondaires.
Alors, dans de la documentation, on peut encore tomber sur les termes master et slave,
mais on essaye de s'écarter petit à petit de ces termes-là.
Quand une nouvelle donnée sera sauvegardée sur le serveur primaire,
ce serveur-là va propager cette nouvelle information aux autres machines
qui vont répliquer le nouveau schéma des données.
La réplication, c'est donc une copie intelligente des données.
L'avantage, c'est d'avoir plusieurs machines différentes mais synchronisées
sur laquelle votre application pourra les lire de la donnée
et ce qui va permettre de supporter plus de charges en lecture.
Par contre, il y a quand même un inconvénient,
c'est de devoir passer par le serveur primaire pour écrire ou modifier une donnée
parce que le processus d'écriture, lui, il gagne pas en efficacité,
il passe que par une machine,
mais comme en général la charge principale sur une base de données
vient du nombre de lectures concurrentes,
et bien on gagne quand même en performance.
Et par contre, en plus, si jamais le serveur principal tombe,
il faudra attendre que les serveurs secondaires restants
élisent un nouveau serveur primaire avant de pouvoir réécrire à nouveau
ce qui peut prendre un petit peu de temps et bloquer votre système.
La méthode numéro 2, c'est ce qu'on appelle la fragmentation.
Ici, il n'y a pas de relation hiérarchique entre les machines,
elles sont plus ou moins toutes sur un pied d'égalité,
et elles possèdent chacune une partie des données.
Si vous prenez un répertoire téléphonique par exemple
et que vous mettez ça dans une base de données,
la machine 1 contiendra les noms de A à I,
la machine 2 de J à R et la machine 3 de S à Z.
Ici, on vient améliorer la performance en lecture et en écriture
parce que chaque machine est responsable de ses propres données.
Attention quand même,
il faut que la fragmentation soit bien pensée
parce que si toutes les données les plus populaires sont sur une machine,
cette machine en question risque de subir plus de charges que les autres.
Je vous ai pris un exemple avec les noms des gens en parodraalfabétiques,
sauf qu'il y a peut-être une dizaine de personnes
dans le répertoire que la majorité des gens appellent
et qu'ils se retrouvent sur la même machine,
on peut avoir des problèmes de performance.
C'est pour ça qu'il faut bien penser sa fragmentation en amont.
Mais surtout, le vrai point faible de cette approche,
c'est que si une des machines tombe,
c'est toute une partie des données qui est inaccessible,
même en lecture.
Donc ça, on n'aura que des données partielles si jamais il y a un problème.
Mais on a aussi une méthode,
une troisième méthode qui est une méthode hybride.
En fait, la troisième méthode, c'est la plus coûteuse,
mais c'est aussi la plus robuste,
parce qu'elle consiste d'abord à fragmenter les données,
puis ensuite à répliquer chacun des fragments.
Voilà, donc c'est un mélange des deux méthodes.
Donc potentiellement, ça veut dire
avoir par exemple neuf machines, neuf petites machines dans notre exemple,
ce qui en fait une architecture évidemment beaucoup plus complexe,
mais qui va être aussi, on va dire, plus solide,
parce que vous n'y pouvez pas perdre une partie des données
et vos données restent toujours accessibles en lecture, etc.
La conclusion, c'est évidemment que pour choisir la meilleure solution pour votre projet,
il faut savoir ce qui est d'abord le plus critique pour vous.
Est-ce que c'est la disponibilité ?
La consistance ou le partitionnement ?
Et en sachant donc dans le concept des bases de données distribuées,
eh bien ces trois options, vous ne pouvez jamais les avoir complètement,
il faudra en choisir que deux.
Ce théorème-là, ça s'appelle le théorème CAP et CAP pour consistance,
partitionnement et availability en anglais.
Et donc si jamais le sujet vous intéresse,
je vous laisse un lien dans les notes du podcast de cet épisode,
pour retrouver et en apprendre un petit peu plus.
Moi, j'espère que cet épisode vous a été utile
et je vous dis à très vite sur Code Garage,
que ce soit sur le blog, le podcast ou dans les cours.
Ciao !