Qu'est-ce que la fragmentation et pourquoi est-il important?

Question

Je crois que je comprends la fragmentation, d'être de remettre vos tranches de données (éclats) dans un facile à traiter avec la fonction d'agrégation qui fait sens dans le contexte. Est-ce correct?

Mise à jour: je suppose que je suis en difficulté ici. À mon avis, le niveau d'application ne devrait avoir aucune entreprise de déterminer l'endroit où les données doivent être stockées. Au mieux, il devrait être communiquées au client d'une certaine sorte. Les deux réponses répondu à la ce, mais pas le pourquoi est-il important aspect. Quelles conséquences a-t-elle en dehors de l'évidence des gains de performances? Ces gains suffisants pour compenser le MVC violation? Est sharding surtout important à très grande échelle des applications ou s'applique à plus petite échelle?

Answer 1

La fragmentation est juste un autre nom pour "le partitionnement horizontal" d'une base de données. Vous pouvez effectuer une recherche pour ce terme pour obtenir plus clair.

De Wikipedia:

Le partitionnement Horizontal est un principe de conception en vertu de laquelle les lignes d'une table de base de données sont détenus séparément, plutôt que de fractionnement par des colonnes (comme pour la normalisation). Chaque partition fait partie d'un éclat, qui peut à son tour être situé sur un autre serveur de base de données ou d'emplacement physique. L'avantage est le nombre de lignes dans chaque table est réduite (ce qui réduit la taille de l'index, améliore ainsi les performances de recherche). Si la fragmentation est basé sur quelques aspects de les données (par exemple, les clients Européens contre les clients d'Amérique), alors il peut être possible d'en déduire l'appropriées fragment d'adhésion facilement et automatiquement, et la requête que seul l'éclat.

Plus d'informations sur la fragmentation:

Tout d'abord, chaque serveur de base de données sont identiques, ayant la même structure de table. Deuxièmement, les enregistrements de données sont logiquement divisé en une fragmenté de la base de données. À la différence de la base de données partitionnée, chaque enregistrement de données existe dans un seul fragment (sauf s'il y a mise en miroir pour la sauvegarde/redondance) avec toutes les opérations CRUD effectuées dans la base de données. Vous n'aimez pas la terminologie utilisée, mais il s'agit d'une manière différente d'organiser une base de données logique en parties plus petites.

Mise à jour: Vous ne pause MVC. Le travail de détermination de la bonne fragment d'où stocker les données de manière transparente par votre couche d'accès aux données. Il vous faudra déterminer le bon éclat sur la base des critères que vous avez utilisé pour éclat de votre base de données. (Comme vous l'avez manuellement éclat de la base de données dans certains des fragments différents basés sur certains aspects concrets de votre application.) Ensuite, vous devez prendre soin lors du chargement et stockage des données à partir de/dans la base de données à utiliser le bon éclat.

Peut-être que cet exemple avec du code Java rend un peu plus clair (c'est sur les Hibernate Shards projet), comment ce serait de travailler dans un scénario réel.

À l'adresse "why sharding": C'est surtout que pour des applications à grande échelle, avec beaucoup de données. Tout d'abord, il aide à minimiser le temps de réponse pour les requêtes de base de données. Deuxièmement, vous pouvez utiliser plus cher, "bas de gamme" machines pour héberger vos données sur, au lieu d'un seul gros serveur, qui peut ne suffisent plus.

Answer 2

Si vous avez des requêtes à un SGBD pour qui la localité est assez restreint (par exemple, un utilisateur déclenche uniquement sélectionne avec un 'where username = $my_username"), il est logique de mettre tous les noms commençant par Une sur un serveur et tous de M-Z sur l'autre. Par cela, vous obtenez près de la mise à l'échelle linéaire pour certaines requêtes.

Longue histoire courte: la Fragmentation est fondamentalement le processus de distribution des tableaux sur différents serveurs afin d'équilibrer la charge sur les deux de façon égale.

Bien sûr, c'est beaucoup plus compliqué dans la réalité. :)

Answer 3

Est sharding surtout important dans de très applications de grande envergure ou qu'il ne s'appliquent à plus petite échelle?

La fragmentation est un problème si et seulement si vos besoins à l'échelle-delà de ce que peut être desservie que par un seul serveur de base de données. C'est une houle outil si vous avez des shardable de données et vous avez incroyablement élevé de l'évolutivité et de performances. Je suppose que dans toute ma 12 ans, j'ai été un logiciel professionnel, j'ai rencontré une situation qui pourrait avoir bénéficié de la fragmentation. C'est une technique avancée avec très peu d'applicabilité.

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

Answer 4

À mon avis, la couche application devrait avoir aucune analyse de la détermination de où les données doivent être stockées

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

Lorsque vous faites de votre architecture, vous commencez avec des responsabilités et des collaborations. Une fois que vous déterminer votre architecture fonctionnelle, vous devez équilibrer les non-fonctionnelles des forces.

Si l'un de ces non-fonctionnelles des forces est une grande évolutivité, vous devez vous adapter à votre architecture pour répondre à cette force, même si cela signifie que le stockage de vos données abstraction maintenant des fuites dans votre niveau d'application.