Je pense que vous avez mélangé quelques termes ici.
Toutes vos données vont dans une base de données (ou schéma). Dans une base de données, vous pouvez avoir des tables.
ex.
table employee
id integer
name varchar
address varchar
country varchar
table office
id integer
employee_id integer
address varchar
À l'intérieur des tables, vous avez des champs (id, name, address) alias colonnes. Et les tables ont une ou plusieurs lignes.
Un exemple pour la table employee :
id name address country
----------------------------------------------------
1 John 1 Regent Street UK
2 James 24 Jump Street China
3 Darth Vader 1 Death Star Bestine, Tatooine
Voilà pour les bases.
Pourquoi partitionner
Supposons maintenant que nous ayons beaucoup, beaucoup de personnes (lignes) dans notre base de données.
N'oubliez pas qu'il s'agit d'une base de données galactique, nous avons donc 100 milliards d'enregistrements.
Si nous voulons rechercher aussi rapidement c'est bien si nous pouvons le faire en parallèle.
Nous partitionnons donc la table (disons par pays) et nous pouvons ensuite avoir x serveurs qui recherchent dans 1 pays chacun.
Le partitionnement entre les serveurs s'appelle sharding .
Ou nous pouvons partitionner par ex. données historiques par année, nous n'avons donc pas à parcourir toutes les données juste pour obtenir le récent nouvelles. Nous n'avons qu'à passer par la partition pour cette année. C'est ce qu'on appelle le partitioning .
Quelle est la grande différence entre le sharding peut simplement partitioning ?
Partage
En sharding vous prévoyez que tous vos données sont pertinentes et tout aussi susceptibles d'être interrogées. (par exemple, Google peut s'attendre à ce que toutes ses données soient interrogées ; l'archivage d'une partie de ses données est inutile pour lui).
Dans ce cas, vous voulez que de nombreuses machines examinent vos données en parallèle, où chaque machine effectue une partie de la travail.
Donc, vous donnez à chaque machine une partition différente (shard) des données et donnez à toutes les machines la même requête. Lorsque les résultats sortent, vous UNION tous ensemble et affichez le résultat.
Partitionnement de base
Dans le partitioning de base une partie de vos données est hot et la partie est not . Un cas typique est celui des données historiques, les nouvelles données sont hot , les anciennes données sont à peine touchées.
Pour ce cas d'utilisation, il est inutile de mettre les anciennes données dans des serveurs séparés. Ces machines attendront et attendront sans rien faire car personne ne se soucie des anciennes données, à l'exception de certains auditeurs qui les examinent une fois par an.
Vous partitionnez donc ces données par an et le serveur archivera automatiquement les anciennes partitions afin que votre les requêtes ne porteront que sur une (peut-être 2) années de données et seront beaucoup plus rapides.
Ai-je besoin d'un partitionnement ?
Vous n'effectuez le partitionnement que lorsque vous avez beaucoup de données, car cela complique votre configuration.
Sauf si vous avez plus d'un million d'enregistrements, vous n'avez pas à envisager le partitionnement.
Si vous avez plus de 100 millions d'enregistrements, vous devriez certainement l'envisager.
Pour plus d'informations, voir :http://dev.mysql.com/ doc/refman/5.1/en/partitioning.html
et :http://blog.mayflower.de/archives/353-Is-MySQL-partitioning-useful-for-very-big-real-life-problems.html
Voir aussi wiki :http://en.wikipedia.org/wiki /Partition_%28database%29
Ce ne sont que mes heuristiques personnelles YMMV.
