Si vous êtes déjà tombé sur de la documentation de base de données (que ce soit du relationnel ou non-relationnel), vous avez sûrement déjà aperçu ces deux termes : "replication" et "sharding"

En français on traduirait ces termes par "réplication" et "fragmentation", mais quel est le sens derrière ces mots un peu barbares ?

À quoi ça sert ?

La principale raison pour choisir ces architectures de bases de données est de mettre en place un "scaling horizontal" ou "passage à l'échelle horizontal".

Pour la plupart des systèmes informatiques, il sera moins cher d'investir dans deux petites machines de performance P1 que dans une grosse machine deux fois plus puissante P2.

C'est le même problème pour les bases de données : lorsque votre application grossie à tel point que le système commence à ralentir, il est temps d'arrêter de faire grossir la machine (scaling vertical) et de commencer à diviser la charge dans de multiple machines (scaling horizontal)

Méthode n°1 : La réplication

Cette méthode consiste simplement à faire coopérer un certain nombre de machines (disons 3 pour l'exemple), d'en promouvoir une au rang de master (maître) et les autres au rang de slaves (esclaves).

Lorsqu'une nouvelle donnée sera sauvegardée sur le master, ce dernier propagera cette nouvelle information aux autres machines pour qu'elles "répliquent" le nouveau schéma des données.

Appelons un chat, un chat, la réplication est simplement une copie intelligente des données

L'avantage est d'avoir plusieurs machines différentes (mais synchronisées) sur lesquelles votre application pourra aller lire de la donnée, ce qui accélère le processus et surtout permet de supporter plus de charge en lecture.

Néanmoins, l'inconvénient est de devoir passer par le master pour écrire ou modifier une donnée, le processus d'écriture, lui, n'est donc pas plus rapide, ni plus robuste.

De plus, si le master tombe, il faudra attendre que les slaves élisent un autre master avant de pouvoir écrire à nouveau, ce qui peut prendre plusieurs secondes selon le SGBD.

Méthode n°2 : La fragmentation

Ici il n'y a pas de relation hiérarchique entre les machines, elles sont toutes sur un pied d'égalité et possèdent chacune une partie des données.

Prenons un répertoire par exemple : la machine 1 contiendrait les noms de A à I, la machine 2 de J à R et la machine 3 de S à Z.

Ici on améliore la vitesse en lecture ET la vitesse en écriture car chaque machine est responsable de ses propres données. Attention néanmoins, il faut que la fragmentation soit bien pensée car si toutes les données les plus populaires sont sur la même machine, cette dernière risque de lâcher à son tour.

Mais le vrai point faible de cette approche est que si l'une des machines tombe, c'est toute une partie des données qui est inaccessible, même en lecture !

Méthode 3 : Hybride

La troisième méthode, la plus coûteuse mais aussi la plus robuste consiste à d'abord fragmenter ses données, pour ensuite répliquer chacun des fragment.

Potentiellement, cela veut aussi dire avoir 9 machines au total (dans notre exemple), et un total de 90Go de données pour 30Go de données brutes avec la réplication, ce qui en fait une architecture beaucoup plus complexe !

Conclusion

Pour choisir la meilleure solution pour votre projet, il faut savoir ce qui est le plus critique pour vous : avoir toutes vos données entières au moins en lecture (et accepter que la lecture puisse être inaccessible de temps en temps), c'est ce qu'on appelle l'intégrité.

Ou bien que les données soient accessibles au maximum, même si elles ne sont pas entières, c'est ce qu'on appelle la disponibilité.

Tu as aimé cet article ? Tu veux me donner ton avis ou une idée ? Alors on se retrouve sur Facebook, Linkedin, Twitter ou même Instagram !

À bientôt !


À propos de l'auteur

Hello, je suis Nicolas Brondin-Bernard, ingénieur web indépendant depuis 2015 passionné par le partage de d'expériences et de connaissances.

Aujourd'hui je suis aussi coach pour développeurs web juniors, tu peux me contacter sur nicolas@brondin.com, sur mon site ou devenir membre de ma newsletter "JAW : de Junior à Warrior" pour recevoir 1 conseil par semaine par email.


Photo par Jaron Mobley sur Unsplash