Qu'est-ce que le sharding et pourquoi est-il important?

Je pense que je comprends que le sharding consiste à remettre vos données tranché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 d'application ne devrait pas avoir à déterminer où les données doivent être stockées. Au mieux, il devrait être un client en quelque sorte. Les deux réponses ont répondu à l'aspect important mais non au pourquoi. Quelles implications cela a-t-il en dehors des gains de performance évidents? Ces gains sont-ils suffisants pour compenser la violation MVC? Le sharding est-il principalement important dans les applications à très grande échelle ou s'applique-t-il aux applications à plus petite échelle?

Le sharding est juste un autre nom pour le "partitionnement horizontal" d'une base de données. Vous voudrez peut-être rechercher ce terme pour le clarifier.

De Wikipédia :

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, plutôt que d'être fractionnées par 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 de 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 l'appartenance au fragment approprié facilement et automatiquement, et d'interroger uniquement le fragment pertinent.

Quelques informations supplémentaires sur le sharding:

Tout d'abord, chaque serveur de base de données est identique, ayant la même structure de table. Deuxièmement, les enregistrements de données sont logiquement répartis 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 s'il existe une mise en miroir pour la sauvegarde / redondance) avec toutes les opérations CRUD effectuées uniquement dans cette base de données. Vous n'aimez 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 de détermination du fragment correct 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 fragment correct en fonction des critères que vous avez utilisés pour partager votre base de données. (Comme vous devez partager manuellement la base de données en plusieurs fragments différents en fonction de certains aspects concrets de votre application.) Ensuite, vous devez faire attention lors du chargement et du stockage des données de / dans la base de données pour utiliser le fragment approprié.

Peut - être que cet exemple avec du code Java le rend un peu plus clair (il s'agit du projet Hibernate Shards ), comment cela fonctionnerait dans un scénario réel.

Pour résoudre le " why sharding": c'est principalement uniquement pour les applications à très grande échelle, avec beaucoup de données. Tout d'abord, il aide à réduire les temps de réponse pour les requêtes de base de données. Deuxièmement, vous pouvez utiliser des machines "bas de gamme" moins chères pour héberger vos données au lieu d'un seul grand serveur, ce qui pourrait ne plus suffire.

Si vous avez des requêtes vers un SGBD pour lequel la localité est assez restreinte (par exemple, un utilisateur ne déclenche que les sélections avec un 'où nom d'utilisateur = $ mon_nom d'utilisateur'), ​​il est logique de mettre tous les noms d'utilisateur commençant par AM sur un serveur et tous de NZ de l'autre. Par cela, vous obtenez une mise à l'échelle presque linéaire pour certaines requêtes.

En bref : le sharding est essentiellement le processus de distribution de tables sur différents serveurs afin d'équilibrer la charge sur les deux de manière égale.

Bien sûr, c'est tellement plus compliqué en réalité. :)

Le partitionnement est un partitionnement de base de données horizontal (par ligne ) par opposition au partitionnement vertical (par colonne ) qui est la normalisation . Il sépare les 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 grand ordinateur coûte moins cher.

Vous pouvez en savoir plus ici: Avantages de la base de données distribuée

Comment le sharding aide à atteindre 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 / Nème des résultats. Ainsi, pour obtenir un ensemble de résultats complet, un système de recherche distribué typique utilise un agrégateur qui accumule les résultats de chaque serveur et les combine. Un agrégateur distribue également la requête sur chaque serveur. Ce programme d'agrégation est appelé MapReduce dans la terminologie du Big Data. En d'autres termes, Distributed Systems = Sharding + MapReduce (bien qu'il y ait 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?

Le partage est une préoccupation si et seulement si vos besoins dépassent ce qui peut être servi par un seul serveur de base de données. C'est un outil de gonflement si vous avez des données partageables et que vous avez des exigences d'évolutivité et de performances incroyablement élevées. Je suppose que dans mes 12 années entières, j'ai été un professionnel du logiciel, j'ai rencontré une situation qui aurait pu bénéficier du sharding. C'est une technique avancée avec une applicabilité très limitée.

En outre, l'avenir va probablement être quelque chose d'amusant et d'excitant comme un "nuage" d'objet massif qui efface toutes les limitations de performances potentielles, non? :)

Sharding a été inventé à l'origine par les ingénieurs de Google et vous pouvez le voir utilisé assez fortement lors de l'écriture d'applications sur Google App Engine. Puisqu'il y a des limitations strictes sur la quantité de ressources que vos requêtes peuvent utiliser et parce que les requêtes elles-mêmes ont des limitations strictes, le partitionnement est non seulement encouragé mais presque appliqué par l'architecture.

Un autre endroit où le partage peut être utilisé est de réduire les conflits sur les entités de données. Il est particulièrement important lors de la construction de systèmes évolutifs de faire attention aux données qui sont souvent écrites car elles constituent toujours le goulot d'étranglement. Une bonne solution consiste à séparer cette entité spécifique et à écrire sur plusieurs copies, puis à lire le total. Un exemple de ce "compteur fragmenté par rapport à GAE: http://code.google.com/appengine/articles/sharding_counters.html

Le sharding fait plus qu'un simple partitionnement horizontal. Selon l' 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. Il 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 ligne particulière sera trouvée, sans avoir à rechercher d'abord l'index, par exemple, le classique exemple des tables 'CustomersEast' et 'CustomersWest', où leur code postal indique déjà où ils seront trouvés.

Le partitionnement va au-delà de cela: il partitionne la ou les tables problématiques de la même manière, mais il le fait sur des instances potentiellement multiples du schéma. L'avantage évident serait que la charge de recherche pour la grande table partitionnée peut désormais être répartie sur plusieurs serveurs (logiques ou physiques), et pas seulement sur plusieurs index sur le même serveur logique.

Aussi,

La division des 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 la requête des deux instances, juste pour récupérer une table de dimension simple. Au-delà du partitionnement, le partitionnement divise ainsi les grandes tables partitionnables sur les serveurs, tandis que les petites tables sont répliquées en unités complètes

À mon avis, le niveau d'application ne devrait pas avoir à déterminer où les données doivent être stockées

C'est une bonne règle mais comme la plupart des choses pas toujours correctes.

Lorsque vous faites votre architecture, vous commencez par 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 répondre à cette force même si cela signifie que votre abstraction de stockage de données s'infiltre maintenant dans votre niveau d'application.