2013-07-23 6 views
6

Pour le moment, nous exécutons une réplique MongoDB contenant 2 serveurs + 1 arbitre.Quand démarrer MongoDB sharding

Et nous stockons environ 150 Go de données dans les bases de données sur la réplique.

À l'heure actuelle, nous pensons à quand commencer avec sharding. Parce que nous nous demandons s'il y a un point où vous ne pouvez plus commencer à partager.

Il est évident que nous devrons commencer à partitionner avant de manquer d'espace disque, notre processeur est surchargé ou la performance globale diminue en raison de trop peu de RAM. Quelqu'un m'a également dit qu'il y a une limite de taille de données de 256 Go, après quoi vous ne pouvez plus commencer à partager. Aussi, j'ai lu la documentation officielle http://docs.mongodb.org/manual/sharding/ et "MongoDB le guide définitif", je ne pouvais pas le prouver.

D'après votre expérience, y a-t-il une limite où vous devriez avoir commencé avec sharding?

Répondre

6

Je commencerais à partitionner lorsque vous avez atteint environ 60-70% d'utilisation des ressources. Cela pourrait être à la fois l'espace disque dur et la RAM. La limite de 256 Go est en effet là, elle est documentée à http://docs.mongodb.org/manual/reference/limits/#Sharding%20Existing%20Collection%20Data%20Size

+0

N'était-ce pas corrigé puisqu'il s'agissait plus d'un "bug"? Je me souviens avoir lu à ce sujet être: '// – Sammaye

+0

qui serait intersting;), et si j'ai obtenu le manuel juste une fois la collection est partagée, il peut dépasser les 256 Go par partition de droite? – Dukeatcoding

+0

@Dukeatcoding Yeah aucune limite sur la taille d'une collection sharded (par shard aussi bien) il est juste pré-sharded, MongoDB a un certain problème dépassant 256GB lors de la création du shard, je ne me souviens pas exactement quoi – Sammaye

6

J'ai trouvé que la limite était basée sur les lectures/écritures; afterall sharding est sur l'augmentation de la capacité, écrit principalement, tandis que les ensembles de réplicas sont plus concernés par les lectures. Cependant, l'utilisation de serveurs séparés (nœuds) pour les plages de données (clé shard) peut également aider les lectures, ce qui a un effet d'accrochage pour les deux. Par exemple, vous ne pouvez utiliser que 40% de la mémoire de votre serveur actuel avec votre jeu de travail actuel, mais en raison de la quantité d'écritures envoyées à ce serveur, vous pourriez voir des problèmes de vitesse dus à IO. À ce moment, vous prendriez en compte le sharding. Donc vraiment je dirais personnellement, et cette question est fortement basée sur l'opinion, que vous devriez partitionner quand vous sentez que vous avez besoin de plus de capacité pour les opérations que ce qui est rentable pour un seul ensemble de réplicas.

Je connais des configurations de répliques uniques qui peuvent prendre ce que, normalement, un cluster entier, mais cela dépend de la taille de votre budget. À mesure qu'un ordinateur grossit, il devient plus cher.

+0

vous avez peut-être raison avec la performance. Puisque nous avons une centaine d'écritures par seconde, le temps de verrouillage devient de plus en plus élevé, cela devrait aussi s'améliorer par sharding, n'est-ce pas? – Dukeatcoding

+0

@Dakeatcoding 100 wties par seconde crée des problèmes de verrouillage? Hmmm mes nœuds peuvent gérer jusqu'à 1 million d'opérations par seconde ... – Sammaye

+0

@Dukeatcoding Vous pourriez avoir un problème d'optimisation ici, il est normalement recommandé de chercher à optimiser votre base de données avant de décider de l'effacer – Sammaye