2010-09-05 4 views
0

Je veux diviser une table de produit en beaucoup plus petit, et mettre la table dans un serveur différent. mais il y a quelques problèmes avec moi: si je partage la base de données avec l'identifiant du produit. Comment puis-je obtenir tous les produits appartiennent à certaines catégories lorsque quelqu'un énumère une catégorie de produits. Quelqu'un at-il de bons idéaux?stratégie de partitionnement de base de données

+1

La première question est: pourquoi voulez-vous faire cela? Qu'est-ce qui te fait penser que tu as besoin de taper? – Mchl

+0

parce que la table de produit est très grande maintenant. je veux améliorer la performance. M'aiderez-vous? – 52226777

+0

qu'est-ce qui est très grand? –

Répondre

0

C'est une bonne question. Si tout ce que vous voulez faire est de mettre des enregistrements dans une autre base de données et que vous ne ferez pas de jointures avec ces enregistrements sur d'autres tables, alors oui vous devez indiquer à votre application d'insérer les enregistrements 1-10000 dans la partition 1 et 10001 -20000 dans le fragment 2. Mais si vous voulez faire une requête de fragment 1 à fragment 2, cela ne fonctionnera pas, et vous aurez besoin d'un produit comme dbShards. dbShards est un bon outil de sharding et a de bonnes critiques. En outre, ils vous aideront à développer une stratégie globale de sharding pour votre application.

Espérons que ça aide.

0

Le problème de base avec sharding est toujours le même: vous ne savez pas comment partitionner depuis le début.

Si vous ne disposez pas de 100 millions de lignes dans le tableau, il est évident que vous n'avez pas besoin de vous en occuper. Les fragments ne résolvent aucun type de performance de requête.

J'ai essayé une fois de deviner ce qui sera populaire et problématique dans DB et échoué misérablement. Maintenant, je comprends que j'ai besoin de résoudre ce problème quand il se passe et j'ai besoin d'écrire du bon code pour faire des changements de ce genre dans le futur (voir le modèle de dépôt par exemple).

Les connaissances de base sur les performances de la base de données sont également bonnes. Ajoutez à cela la résolution des requêtes lentes (slowlog est un bon point de départ) et ignorez les opérations de jointure.

Questions connexes