Base de données : Différences entre réplication et fragmentation (sharding)

Si vous avez déjà plongé dans 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 : "réplication" et "sharding"

En français on traduirait "sharding" par "fragmentation", mais qu'est-ce que cela signifie réellement ?

À quoi ça sert ?

La principale raison pour choisir ces stratégies de sauvegarde des 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 stratégie consiste simplement à faire coopérer un certain nombre de machines (disons 3 pour l'exemple), d'en promouvoir une au rang de primaire et les autres au rang de secondaires.

À noter qu'il peut encore être courant de tomber sur les termes "master" et "slaves" pour désigner les deux rôles de ces machines.

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

La réplication est donc 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 permet de supporter plus de charge en lecture.

Néanmoins, l'inconvénient est de devoir passer par le serveur primaire pour écrire ou modifier une donnée, le processus d'écriture, lui, ne gagne pas en efficacité, mais en général la charge sur votre système vient principalement du nombre de lectures concurrentes.

De plus, si le serveur principal tombe, il faudra attendre que les secondaires élisent un nouveau primaire avant de pouvoir écrire à nouveau, ce qui peut prendre du temps.

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 performance en lecture ET 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 subir plus de charge que les autres.

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), 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 : la disponibilité, la consistance ou le partitionnement, sachant que vous ne pouvez choisir que deux des options.

Ce principe des bases de données distribuées s'appelle le théorème CAP, que je vous laisserai découvrir si le sujet vous intéresse !