Vue d'ensemble du sharding de base de données
- Comment fonctionne le sharding des bases de données
- Avantages de la mise en commun des données (sharding)
- Inconvénients du sharding
- Types d'entrepôts de stockage (sharding)
- Alternatives au sharding de base de données
- Comment Couchbase Capella™ aide à la mise en commun des bases de données.
- Conclusion
Le partage de base de données est un outil puissant qui permet d'optimiser les performances et l'évolutivité d'une base de données. Il permet un accès plus rapide aux données et permet à une base de données de gérer des charges de travail plus importantes en répartissant les données et la puissance de traitement sur plusieurs serveurs. Les bases de données NoSQL étant conçues pour l'informatique distribuée et le sharding automatique, elles sont souvent les bases de données les plus associées au sharding. Cependant, avec suffisamment d'efforts, le sharding peut être réalisé avec n'importe quelle technologie de base de données.
Comment fonctionne le partage des bases de données ?
Le sharding de base de données divise l'ensemble des données en plusieurs groupes appelés "shards". Une fois divisé, chaque groupe peut être stocké indépendamment, généralement sur plusieurs serveurs, souvent désignés sous le nom de "cluster". Chaque groupe est accessible indépendamment, ce qui signifie que vous pouvez accéder aux données plus rapidement et que vous disposez de plus de ressources pour le traitement, le calcul et le stockage.
Où se déroule le sharding ?
Si une base de données intègre des fonctionnalités de sharding, l'équipe de développement aura moins de travail à fournir pour réaliser le sharding. Si le sharding est une fonction optionnelle ou nécessite une configuration, vous devrez planifier avec soin, mais le sharding ne devrait pas nécessiter de modifications ou d'ajouts importants dans la base de code. Si la base de données sous-jacente ne permet pas le sharding (comme c'est le cas pour de nombreuses bases de données relationnelles), vous devrez peut-être apporter des modifications majeures à la base de code et les développeurs devront intégrer le sharding dans la couche de persistance d'une application.
Dois-je partager mes données ?
L'utilisation du sharding dépend de nombreux facteurs. Ces facteurs comprennent la taille de votre ensemble de données, le nombre d'utilisateurs du système, le nombre d'opérations effectuées et les contraintes de votre infrastructure.
Si votre application connaît une baisse notable des performances en raison de l'augmentation du nombre d'utilisateurs ou d'opérations, la mise à l'échelle horizontale (qui fait souvent appel au partage) est un moyen d'augmenter les ressources de calcul disponibles pour votre base de données. Mais des performances médiocres peuvent également indiquer un code sous-optimal, l'absence d'index appropriés, la nécessité de modifier la modélisation des données ou d'autres problèmes. Le sharding ne doit pas toujours être le premier choix pour améliorer les performances, mais pour certaines technologies de base de données, il peut s'agir d'un moyen peu contraignant d'atteindre vos objectifs en matière de performances.
Avantages de la mise en commun des données (sharding)
- Des performances plus rapides : Il y a plus de serveurs disponibles pour traiter les entrées/sorties.
- Évolution horizontale : Vous pouvez rapidement ajouter des serveurs supplémentaires à un cluster
- Coûts : La mise à l'échelle horizontale peut souvent être moins coûteuse que la mise à l'échelle verticale (c'est-à-dire la mise à niveau d'un serveur vers un autre serveur plus puissant).
- Distribution/temps de fonctionnement : Une base de données distribuée à échelle horizontale peut atteindre un meilleur temps de disponibilité qu'un serveur unique traditionnel.
Inconvénients du sharding
- Complexité : Selon le système de base de données, la complexité du sharding peut varier. Certaines bases de données sont conçues avec la distribution, l'échelle horizontale et le sharding inclus. D'autres nécessitent une approche plus pratique.
- Rééquilibrage : Lorsque des machines supplémentaires sont ajoutées à un cluster, il est probable qu'il faille rééquilibrer les nuages pour répartir les données de manière homogène (par exemple, si vous avez 1 000 documents répartis de manière homogène sur trois nuages, cela représente environ 333 documents par nuage). Si vous ajoutez un quatrième dépôt, la répartition sera égale à 250 documents par dépôt). Si une base de données ne dispose pas de fonctions de partage intégrées, le rééquilibrage est garanti comme étant un processus manuel complexe de bricolage.
Types d'entrepôts de stockage (sharding)
Il existe plusieurs approches du partage des données. Certains systèmes de base de données intègrent la fonctionnalité de partage, tandis que d'autres ne la prennent pas directement en charge (et nécessitent beaucoup de codage personnalisé ou de processus de bricolage). L'objectif de chaque approche est de répartir les données de manière cohérente, de sorte que les données puissent être consultées ou écrites sur le même disque à chaque fois.
Partage basé sur la portée
La répartition par plage consiste à sélectionner des valeurs de données et à les affecter à un groupe de stockage selon qu'elles se situent ou non dans une plage spécifique. Par exemple, si vous avez des données sur les utilisateurs qui contiennent l'âge, un nuage pourrait stocker les utilisateurs âgés de 0 à 10 ans, un autre nuage stockerait les utilisateurs âgés de 11 à 20 ans, et ainsi de suite.
Cette approche peut s'avérer problématique, car une unité de stockage peut finir par stocker beaucoup plus d'utilisateurs que l'autre. De plus, les zones stockant une quantité disproportionnée de données peuvent devenir des points chauds ayant un impact sur les performances.
Partage basé sur des clés
Le sharding basé sur des clés adopte une approche plus indépendante. Une valeur contenue dans les données (généralement l'identifiant du document dans une base de données documentaire NoSQL) est passée par un hachage, et ce hachage détermine dans quel tiroir les données doivent être stockées.
Cette approche peut être problématique si elle n'est pas directement prise en charge par la base de données, car toute application accédant à la base de données doit être en mesure de construire le hachage. En outre, cette approche exige que la valeur des données utilisée pour le hachage soit immuable. Ce n'est généralement pas un problème, mais cela peut l'être dans de rares cas particuliers.
Couchbase utilise partage automatique basé sur les clés pour distribuer les données de manière homogène dans un cluster, et fournit également un rééquilibrage et une réplication automatiques. Ces automatisations peuvent simplifier les processus critiques et libérer un temps précieux pour votre équipe de développement.
Partage basé sur un répertoire
Le sharding basé sur un répertoire est une approche par laquelle une certaine valeur des données est mappée à un shard particulier sur la base de sa valeur dans une table de consultation ou une configuration de consultation. Cette approche est similaire à l'approche par plage, mais peut impliquer une simple recherche. Par exemple, un utilisateur ayant une adresse dans l'Ohio sera stocké dans le dépôt “Ohio”, un utilisateur en Californie ira dans le dépôt “Californie”, et ainsi de suite.
Cette approche peut être problématique car une table de recherche ou une configuration peut devenir indisponible, tomber en panne ou être corrompue. Dans ce cas, l'application ne peut plus effectuer de lectures ou d'écritures.
Geo sharding
Un géo-shard peut être combiné ou utilisé à la place des autres options de sharding. L'idée derrière la répartition géographique est de stocker les données physiquement plus près de l'endroit où elles seront le plus souvent consultées. Par exemple, un utilisateur ayant une adresse dans l'Ohio sera stocké sur un serveur dans l'Ohio, et un utilisateur ayant une adresse en Californie sera stocké sur un serveur en Californie.
Cette approche peut permettre un accès plus rapide, mais peut également conduire à des points chauds et à des serveurs sous-utilisés. Le géo-partage peut également ne pas répondre aux exigences légales pour des applications ou des juridictions spécifiques.
En plus de fournir un sharding automatique, Couchbase peut prendre en charge le géo sharding par le biais de réplication croisée des centres de données (XDCR).
Partage basé sur les entités
Le sharding basé sur les entités signifie que des données distinctes, mais étroitement liées, sont stockées ensemble sur le même shard. Par exemple, un utilisateur peut être considéré comme une entité dans la logique d'une application, mais l'historique des achats d'un utilisateur peut être stocké séparément dans un autre entrepôt. En stockant les données connexes dans la même grappe, vous pouvez réduire la quantité de travail informatique nécessaire pour les extraire ensemble en même temps.
L'inconvénient de cette approche est sa complexité. La configuration de l'affectation des données peut être un processus complexe, en particulier si certaines données sont utilisées par plusieurs entités.
Alternatives au sharding de base de données
La mise à l'échelle horizontale impliquera toujours le partage à un certain niveau, mais il existe de nombreuses options pour la mise à l'échelle horizontale. comment à partager. L'une des possibilités est le sharding architectural, comme une architecture de microservices ou un sharding de disque physique opaque pour l'utilisateur. Le sharding peut même être caché et abstrait derrière une architecture de base de données en nuage.
Lorsque l'on envisage un système de base de données, il est essentiel de comprendre comment le sharding sera réalisé. Il peut être entièrement abstrait et caché, il peut être automatique, il peut être pris en charge avec des options de configuration potentiellement complexes, ou il peut ne pas être pris en charge et nécessiter une approche bricolée.
Comment Couchbase Capella aide à la mise en commun des bases de données
Couchbase Capella est la plateforme de base de données en nuage pour les entreprises numériques.
Capella utilise le même système de sharding que Couchbase Server, c'est-à-dire un sharding automatique basé sur des clés. Du point de vue de l'utilisateur ou du développeur, le sharding avec Couchbase ne nécessite aucune configuration ou maintenance supplémentaire. En utilisant un algorithme CRC32 en conjonction avec vBuckets, Capella garantit que votre système n'aura pas de points chauds.
Capella automatise la réplication. Il vous suffit de sélectionner le nombre de répliques que vous souhaitez, et Capella s'occupe du reste.
Capella automatise également le rééquilibrage. Lorsque vous ajoutez ou retirez des serveurs d'un cluster, Capella les rééquilibre automatiquement sans provoquer de temps d'arrêt.
Enfin, Capella peut réaliser un géo-sharding grâce à la fonction XDCR. XDCR réplique les données entre les centres de données en temps réel. Les réplications XDCR peuvent inclure ou exclure des données sur la base de filtres définis par l'utilisateur afin d'améliorer la latence locale ou de répondre aux exigences en matière de localisation des données.
Conclusion
Le sharding est un concept important à comprendre si vous souhaitez faire évoluer une base de données pour qu'elle puisse gérer davantage d'opérations. Les bases de données NoSQL sont particulièrement adaptées au sharding car elles éliminent de nombreuses contraintes imposées par les bases de données relationnelles. Cela dit, Couchbase Capella offre certaines des meilleures fonctionnalités d'une base de données relationnelle (syntaxe SQL et une implémentation SQL complète qui inclut les JOIN et les Transactions ACID) vers une base de données distribuée avec partage automatique.
Pour en savoir plus sur le sharding dans Couchbase, consultez le site :
Autres ressources importantes pour déterminer comment faire évoluer une base de données :
