La création d’un site web est la première étape pour établir votre présence sur Internet. Pour prospérer à long terme, vous devez également vous assurer que votre site peut évoluer en fonction de sa croissance. Et l’une des premières étapes consiste à mettre en œuvre une base de données qui peut évoluer avec vous. Sinon, vous risquez de connaître des performances de requête lentes et des pannes de base de données.
Cet article explique comment utiliser le partage ou le « sharding » de base de données pour obtenir une évolutivité et une disponibilité élevées de vos données. Nous aborderons également les inconvénients du sharding et les différentes architectures de sharding que vous pouvez utiliser.
Qu’est-ce que le sharding de base de données ?
Le sharding est une technique d’optimisation qui distribue les tables sur d’autres serveurs de base de données. Elle ressemble au partitionnement dans le sens où les deux impliquent la division des données en sous-ensembles plus petits. La différence est que le partage distribue ces sous-ensembles sur différents serveurs, alors que le partitionnement les stocke dans une seule base de données. Ces serveurs utilisent le même moteur de base de données et le même type de matériel pour atteindre un niveau de performance similaire pour tous les shards.
Le sharding vise à réaliser une architecture de type « share-nothing », éliminant les goulots d’étranglement du traitement et les points de défaillance uniques.
Vous pouvez mettre en œuvre le sharding de deux façons — horizontalement et verticalement. Le partage horizontal divise la table en fonction des lignes, tandis que le sharding vertical divise les tables en fonction des colonnes.
À cet égard, le partage est comparable au partitionnement, qui divise les grandes tables en plus petites.
Le sharding horizontal est efficace pour les bases de données où la plupart des requêtes renvoient un sous-ensemble de lignes, comme une base de données clients qui renvoie des données (comme le nom, l’adresse, l’e-mail, etc.) en une seule fois.
Le sharding vertical est efficace pour les bases de données dont les requêtes renvoient des colonnes uniques. Par exemple, si la base de données client renvoie le nom ou l’adresse e-mail du client séparément, vous pouvez séparer le nom et l’adresse e-mail dans des clusters différents.
Avantages du partage de bases de données
Voici quelques-uns des avantages du sharding de bases de données.
Mise à l’échelle horizontale améliorée
Vous pouvez faire évoluer votre base de données verticalement ou horizontalement. La mise à l’échelle verticale consiste à ajouter davantage d’unités centrales de traitement (CPU) et de mémoire vive (RAM) au serveur pour améliorer les performances. La mise à l’échelle verticale est une solution utile pour les petites et moyennes bases de données. Toutefois, à mesure que vos données augmentent, la mise à l’échelle verticale devient infaisable. La puissance que vous pouvez ajouter à un seul serveur est limitée.
La mise à l’échelle horizontale est plus flexible. Elle vous permet de faire évoluer votre base de données selon vos besoins en ajoutant des serveurs supplémentaires à votre système. Chacun de ces serveurs fournit des ressources à différents shards de base de données. Cela permet de répartir la charge de travail et d’améliorer la capacité du système à traiter davantage de demandes.
Des temps de réponse plus rapides aux requêtes
Les shards ne comportent que quelques lignes et colonnes. De ce fait, le traitement des requêtes de la base de données prend moins de temps. En revanche, l’interrogation d’une base de données non sharded peut nécessiter une recherche dans des centaines, voire des milliers, de lignes.
Fiabilité accrue dans les situations de panne
Les pannes de bases de données surviennent pour diverses raisons, notamment la suppression accidentelle de données, les erreurs de connexion et les attaques de cybersécurité. Le sharding minimise les effets des pannes. Comme chaque shard est autonome, seul le shard affecté subit un temps d’arrêt. Par exemple, si vous avez quatre shards et que l’un d’entre eux subit une panne, seuls 25 % des opérations seront affectées.
Inconvénients du sharding
Bien que le sharding améliore la fiabilité et la disponibilité d’une base de données, sa mise en œuvre est complexe. L’utilisation d’une mauvaise architecture de sharding peut ralentir les performances et entraîner des pertes de données.
Veillez à choisir une technique de sharding qui permet une répartition équilibrée des données sur tous les shards. Sans cet équilibre, vous risquez de créer des hotspots de base de données, qui se produisent lorsqu’un shard stocke la plupart des données tandis que les autres shards restent pratiquement vides. Cela réduit le débit d’écriture vers le seul shard.
Pour résoudre ce problème, vous pouvez partitionner encore plus le shard déséquilibré, mais ce processus est difficile et risque de mettre votre base de données hors service pendant la migration des données.
Un autre inconvénient du sharding est que les jointures SQL impliquant plusieurs tables dans différents shards peuvent devenir trop lentes et dégrader les performances. Toutefois, avec la bonne architecture, vous pouvez éviter ce problème.
Architectures de sharding
Vous pouvez mettre en œuvre le sharding à l’aide de trois architectures :
- Sharding basé sur les clés
- Sharding basé sur les plages
- Sharding basé sur les répertoires
L’architecture que vous choisissez dépend de votre cas d’utilisation.
Sharding basé sur les clés
Dans une architecture de sharding basée sur une clé ou un hachage, une application de base de données utilise une clé de shard pour localiser un shard. Une fonction de hachage permet de hacher la valeur de la clé de sharding, et la sortie fait correspondre les données à un shard particulier. Une fonction de hachage simple peut être le modulus de la clé et le nombre de shards.
La fonction de hachage peut prendre plus d’une clé de sharding. Pour cette raison, le sharding basé sur la clé convient aux enregistrements de données qui peuvent avoir des clés partagées. La répartition algorithmique des données minimise la possibilité de créer des points chauds de la base de données où un tesson contient plus de données que l’autre.
Cependant, comme la distribution repose uniquement sur la fonction de hachage, il est impossible de regrouper logiquement les données. Par conséquent, les opérations de base de données qui requièrent des données provenant de plusieurs shards peuvent être inefficaces car elles nécessitent la lecture des données de chaque shard.
Sharding basé sur la plage
Le sharding basé sur la plage implique le sharding d’une base de données en fonction d’une plage de valeurs spécifiée.
Il utilise une clé de sharding pour déterminer à quel shard attribuer une valeur. L’application de base de données vérifie le shard qui correspond à la clé de sharding dans une table de consultation et stocke les données. Pour cette raison, le sharding basé sur la plage est facile à concevoir et à mettre en œuvre.
Par exemple, vous pouvez utiliser la valeur de l’ID utilisateur dans une base de données d’utilisateurs comme clé de sharding. Vous pourriez stocker les utilisateurs dont l’ID est compris entre 0 et 2 000 sur un shard, ceux entre 2 000 et 4 000 sur un autre shard, et ainsi de suite.
Le sharding basé sur l’intervalle peut provoquer des points chauds dans la base de données. Considérez une base de données d’utilisateurs dans laquelle la plupart de vos identifiants se situent entre 2 001 et 4 000. Le processus les affecte à un seul shard, ce qui crée un déséquilibre au fil du temps. Le sharding basé sur l’intervalle fonctionne donc mieux pour les données réparties de manière homogène.
Sharding basé sur un répertoire
Le sharding basé sur les répertoires regroupe les données logiquement liées dans le même shard. Il utilise une table de consultation contenant une liste de mappages pour chaque entité de la base de données. Chaque mappage correspond à un shard de base de données.
Le sharding basé sur les répertoires est plus flexible que le sharding basé sur les plages ou les clés, car vous pouvez ajouter des données aux shards de manière dynamique. Il n’y a pas de fonction de sharding à suivre ou de valeurs de plage à respecter. Cette flexibilité augmente l’efficacité de la base de données : Vous pouvez stocker des données similaires dans un seul shard, ce qui signifie que l’exécution de requêtes communes prend moins de temps.
Par exemple, si vous avez utilisé le sharding basé sur les répertoires et regroupé les utilisateurs en fonction de leur emplacement, pour récupérer les utilisateurs d’un endroit particulier, vous n’interrogez qu’un seul shard.
Sharding de base de données avec Kinsta
La plupart des moteurs de base de données modernes prennent en charge le sharding de base de données. L’un de ces moteurs de base de données est MariaDB, un fork de MySQL supporté commercialement. Il s’agit d’un système de base de données open source très performant adopté par des entreprises comme IBM, GitHub et Wikimedia. Il fait également partie de la pile de serveurs haute performance de Kinsta.
MariaDB offre des fonctionnalités intégrées de sharding grâce au moteur de stockage spider. Le moteur de stockage spider est un moteur de formation de clusters qui prend en charge le partitionnement et les transactions XA (extended architecture). Il vous permet de traiter les tables distantes de différentes instances comme si elles se trouvaient dans la même instance. Une fois que vous créez une table dans le moteur de stockage spider, la table se lie à une autre table dans le serveur MariaDB distant. Une fois la connexion établie, le moteur de stockage partage le lien avec toutes les tables qui font partie de la même transaction.
Résumé
Le sharding de base de données est une technique de mise à l’échelle qui divise les tables en sous-ensembles plus petits et les distribue à différents serveurs appelés shards. Vous pouvez mettre en œuvre le sharding par différents moyens, comme le sharding basé sur les clés, le sharding basé sur les plages et le sharding basé sur les répertoires.
Bien que le sharding améliore l’évolutivité, la fiabilité et la disponibilité d’une base de données, il est très complexe à mettre en œuvre. De plus, une fois que vous avez créé un shard, il n’est pas facile de revenir à l’état non shardé de la base de données. Pour cette raison, n’utilisez le sharding pour l’optimisation que lorsque vous êtes sûr que les autres options d’évolutivité ne fonctionneront pas.
Que votre activité soit à but non lucratif ou de niveau entreprise, les solutions expertes de Kinsta peuvent vous débarrasser de vos soucis d’hébergement de site, vous permettant de vous concentrer sur ce qui compte le plus.
Laisser un commentaire