Guide du débutant pour le partage de bases de données – Anamika Ahmed

1. Il aide à faciliter mise à l’échelle horizontale, aussi connu sous le nom évolutif. La mise à l’échelle horizontale signifie ajouter plus d’unités de traitement ou de machines physiques à votre serveur ou base de données pour permettre plus de trafic et un traitement plus rapide.
2. Il accélère les temps de réponse aux requêtes. Lorsque vous soumettez une requête dans une base de données non sécurisée, chaque ligne du tableau est recherchée avant de vous fournir le résultat que vous recherchez, et les requêtes peuvent être excessivement lentes dans une grande base de données monolithique. D’un autre côté, si la base de données est fragmentée, les requêtes doivent parcourir moins de lignes, et ainsi, vous obtenez vos jeux de résultats plus rapidement.
3. Il rend une application plus fiable en atténuant l’impact des pannes. Une panne dans une base de données non sécurisée peut rendre l’ensemble de l’application indisponible. Avec une base de données fragmentée, une panne est susceptible d’affecter un seul fragment.

1. Il est assez complexe d’implémenter une architecture de base de données fragmentée. S’il n’est pas fait correctement, il existe un risque important que le processus de partitionnement puisse entraîner la perte de données ou la corruption de tables. Même si le partitionnement est effectué correctement, le flux de travail de l’équipe peut être entravé car les utilisateurs doivent gérer les données sur plusieurs fragments plutôt qu’à partir d’un seul point d’entrée.
2. Les éclats deviennent souvent déséquilibrés.
3. Une fois qu’une base de données a été fragmentée, il peut être très difficile de la remettre dans son architecture non durcie
4. Le sharding n’est pas pris en charge nativement par tous les moteurs de base de données. Par exemple, PostgreSQL ne prend pas en charge la fonction de partitionnement automatique, mais il est possible de partitionner manuellement une base de données PostgreSQL.

Partage basé sur les clés

Cela utilise une partie des données (par exemple, l’ID client) qui est connectée à une fonction de hachage afin de déterminer sur quel fragment les données doivent aller. La fonction de hachage prend une entrée et donne une valeur de hachage discrète en sortie. La valeur de hachage est essentiellement l’ID de fragment utilisé pour déterminer sur quel fragment les données entrantes doivent être stockées.Un problème avec cette architecture est que le nombre de serveurs est effectivement fixé et l’ajout de serveurs supplémentaires nécessiterait une réaffectation de toutes les données, ce qui est assez une tâche coûteuse.

Partage basé sur l’annuaire

Dans ce schéma, vous gérez une table de recherche pour savoir où les données peuvent être trouvées. Cela facilite l’ajout de serveurs supplémentaires, mais il présente deux inconvénients majeurs. Premièrement, la table de recherche peut être un seul point d’échec: si elle est corrompue, elle peut avoir une incidence sur la capacité d’écrire de nouvelles données ou d’accéder à leurs données existantes. Deuxièmement, l’accès constant à ce tableau peut avoir un impact sur les performances de l’application.

Partage basé sur la plage

Basé sur la plage le sharding implique le sharding des données en fonction de la plage de valeurs données. Supposons que vous ayez une base de données qui stocke des informations sur les produits: un produit sera stocké dans un éclat en fonction de la fourchette de prix dans laquelle il tombe. Ce schéma est relativement facile à mettre en œuvre, car le code d’application lit simplement dans quelle plage les données se trouvent et les écrit dans le fragment correspondant.

Le partage est généralement effectué lorsque vous traitez de grandes quantités de données. Quelques scénarios courants où il pourrait être avantageux de fragmenter une base de données:

1. Si votre application est liée aux performances de lecture, vous pouvez ajouter des caches ou des répliques de base de données.
2. Passez à une machine plus grande et plus chère.