Qu'est-ce que le sharding et pourquoi est-ce important?
Je pense que je comprends que le sharding consiste à remettre vos données découpées (les fragments) dans un agrégat facile à gérer qui a du sens dans le contexte. Est-ce correct?
Mise à jour: Je suppose que je me bats ici. À mon avis, le niveau applicatif ne devrait pas avoir d'activité à déterminer où les données doivent être stockées. Au mieux, il devrait s'agir d'un client partagé. Les deux réponses ont répondu à l’aspect important mais non au pourquoi. Quelles sont les implications en dehors des gains de performance évidents? Ces gains sont-ils suffisants pour compenser la violation de MVC? Le sharding est-il principalement important dans les applications à très grande échelle ou s'applique-t-il aux applications à plus petite échelle?
Sharding est juste un autre nom pour "partitionnement horizontal" d'une base de données. Vous voudrez peut-être chercher ce terme pour le rendre plus clair.
De Wikipedia :
Le partitionnement horizontal est un principe de conception selon lequel les lignes d'une table de base de données sont conservées séparément au lieu d'être divisées en colonnes (comme pour la normalisation). Chaque partition fait partie d'un fragment, qui peut à son tour être situé sur un serveur de base de données ou un emplacement physique distinct. L'avantage est que le nombre de lignes dans chaque table est réduit (cela réduit la taille de l'index et améliore ainsi les performances de recherche). Si le partage est basé sur un aspect réel des données (par exemple, les clients européens par rapport aux clients américains), il peut être possible de déduire facilement et automatiquement l'appartenance à un fragment approprié et de ne rechercher que le fragment concerné.
Quelques informations supplémentaires sur le sharding:
Tout d’abord, chaque serveur de base de données est identique et possède la même structure de table. Deuxièmement, les enregistrements de données sont logiquement divisés dans une base de données fragmentée. Contrairement à la base de données partitionnée, chaque enregistrement de données complet existe dans un seul fragment (sauf en cas de mise en miroir pour la sauvegarde/la redondance) avec toutes les opérations CRUD exécutées uniquement dans cette base de données. Vous n’aimerez peut-être pas la terminologie utilisée, mais cela représente une manière différente d’organiser une base de données logique en parties plus petites.
Mise à jour: Vous ne casserez pas MVC. Le travail consistant à déterminer le bon fragment où stocker les données serait effectué de manière transparente par votre couche d'accès aux données. Là, vous devrez déterminer le bon fragment en fonction des critères que vous avez utilisés pour partager votre base de données. (Comme vous devez décomposer manuellement la base de données en différents fragments en fonction de certains aspects concrets de votre application.) Vous devez ensuite veiller à utiliser le bon fragment lors du chargement et du stockage des données depuis/dans la base de données.
Peut-être que cet exemple avec Java le rend un peu plus clair (il s'agit du projet Hibernate Shards )), comment cela fonctionnerait dans un monde réel scénario.
Pour adresser le "why sharding ": C’est principalement pour les applications à très grande échelle, avec beaucoup de données. En premier lieu, cela permet de réduire les temps de réponse des requêtes de base de données. Deuxièmement, vous pouvez utiliser des solutions plus économiques, "machines pour héberger vos données, au lieu d’un gros serveur, ce qui pourrait ne plus suffire.
Si vous avez des requêtes à un SGBD pour lesquelles la localité est assez restreinte (par exemple, un utilisateur déclenche uniquement la sélection avec un 'où nom_utilisateur = $ mon_nom_utilisateur'), il est logique de mettre tous les noms d'utilisateur commençant par AM sur un serveur et tous sur NZ. de l'autre. En cela, vous obtenez une mise à l'échelle presque linéaire pour certaines requêtes.
Long story short: La fragmentation est essentiellement le processus de distribution de tables sur différents serveurs afin d'équilibrer la charge de manière égale sur les deux.
Bien sûr, c'est tellement plus compliqué en réalité. :)
Le fragmentation est un partitionnement horizontal ( ligne par ligne ) par opposition à une partition verticale ( par colonne ) partitionnement qui est Normalisation. Il sépare de très grandes bases de données en parties plus petites, plus rapides et plus faciles à gérer, appelées fragments de données. C'est un mécanisme pour réaliser des systèmes distribués.
Pourquoi avons-nous besoin de systèmes distribués?
- Disponibilité accrue.
- Expansion plus facile.
- Aspects économiques: créer un réseau d'ordinateurs plus petits avec la puissance d'un seul ordinateur de grande taille coûte moins cher.
Vous pouvez en lire plus ici: Avantages de la base de données distribuée
Comment le sharding aide-t-il à obtenir un système distribué?
Vous pouvez partitionner un index de recherche en N partitions et charger chaque index sur un serveur distinct. Si vous interrogez un serveur, vous obtiendrez 1/Nth des résultats. Ainsi, pour obtenir un ensemble de résultats complet, un système de recherche réparti typique utilise un agrégateur qui accumule les résultats de chaque serveur et les combine. Un agrégateur distribue également une requête sur chaque serveur. Ce programme d'agrégation s'appelle MapReduce dans la terminologie Big Data. En d’autres termes, Distributed Systems = Sharding + MapReduce (bien qu’il existe aussi d’autres choses).
Une représentation visuelle ci-dessous. 
Le sharding est-il principalement important dans les applications à très grande échelle ou s'applique-t-il aux applications à plus petite échelle?
L'éclatement est une préoccupation si et seulement si vos besoins vont au-delà de ce que peut servir un serveur de base de données unique. Si vous disposez de données partageables et que vous avez des exigences élevées en termes d’évolutivité et de performances, c’est un outil idéal. J'imagine que depuis 12 ans que je suis un professionnel du logiciel, j'ai rencontré une situation qui aurait pu bénéficier du partage. C'est une technique avancée avec une applicabilité très limitée.
En outre, l’avenir sera probablement quelque chose d’amusant et d’excitant comme un énorme "nuage" d’objets qui efface toutes les limitations de performances potentielles, non? :)
Sharding a été inventé à l'origine par les ingénieurs de Google. Vous pouvez constater qu'il est très utilisé lors de l'écriture d'applications sur Google App Engine. Étant donné que la quantité de ressources que vos requêtes peuvent utiliser est soumise à des limitations strictes et que les requêtes elles-mêmes ont des limitations strictes, le sharding est non seulement encouragé, mais presque appliqué par l'architecture.
Un autre endroit où le sharding peut être utilisé est de réduire les conflits sur les entités de données. Lors de la création de systèmes évolutifs, il est particulièrement important de surveiller les données écrites souvent, car elles constituent toujours le goulot d'étranglement. Une bonne solution consiste à partager cette entité spécifique et à écrire sur des copies multiples, puis de lire le total. Un exemple de cela "sharded counter wrt GAE: http://code.google.com/appengine/articles/sharding_counters.html
La fragmentation ne se limite pas au partitionnement horizontal. Selon le article de wikipedia ,
Le partitionnement horizontal divise une ou plusieurs tables par ligne, généralement au sein d'une seule instance d'un schéma et d'un serveur de base de données. Cela peut offrir un avantage en réduisant la taille de l’index (et donc l’effort de recherche), à condition qu’il existe un moyen évident, robuste et implicite d’identifier dans quelle partition une rangée particulière sera trouvée, sans avoir besoin au préalable de rechercher l’index, par exemple, le classique. exemple des tables 'CustomersEast' et 'CustomersWest', où leur code postal indique déjà où ils seront trouvés.
La fragmentation va au-delà: elle partitionne la ou les tables problématiques de la même manière, mais elle le fait sur plusieurs instances potentielles du schéma. L’avantage évident serait que la charge de recherche pour la grande table partitionnée peut maintenant être répartie sur plusieurs serveurs (logiques ou physiques), et pas uniquement sur plusieurs index sur le même serveur logique.
Aussi,
La division de fragments entre plusieurs instances isolées nécessite plus qu'un simple partitionnement horizontal. Les gains d'efficacité espérés seraient perdus si l'interrogation de la base de données nécessitait l'interrogation des deux instances, uniquement pour récupérer une table de dimension simple. Au-delà du partitionnement, le sharding divise ainsi les grandes tables partitionnables sur les serveurs, tandis que les tables plus petites sont répliquées en unités complètes.
À mon avis, le niveau applicatif ne devrait pas avoir d'activité à déterminer où les données doivent être stockées
C'est une bonne règle mais comme la plupart des choses, ce n'est pas toujours correct.
Quand vous faites votre architecture, vous commencez avec des responsabilités et des collaborations. Une fois que vous avez déterminé votre architecture fonctionnelle, vous devez équilibrer les forces non fonctionnelles.
Si l’une de ces forces non fonctionnelles est une évolutivité massive, vous devez adapter votre architecture pour prendre en compte cette force, même si cela signifie que votre abstraction de stockage de données fuit maintenant dans votre couche d’application.