Est-il sensé d'implémenter mongodb sharding avec disons 100 fragments sur une machine plus costaud juste pour obtenir une écriture plus concise dans la base de données comme on dit, il y a un verrou global pour chaque processus monogod.exe? En supposant que cela soit possible, cette approche me donnera-t-elle une concurrence d'écriture plus élevée?MongoDB Sharding sur une machine
L'utilisation de plusieurs appareils sur une machine n'est pas une bonne idée. Chacun des processus mongod essayera d'utiliser toute la mémoire disponible, forçant les autres pages mappées de la mémoire de mongod à sortir de la mémoire. Cela créera une énorme quantité de permutation dans la plupart des cas.
Le verrou de base de données globale est généralement pas un problème comme cela est démontré dans: http://blog.pythonisito.com/2011/12/mongodbs-write-lock.html
utilisent seulement une mongod par machine (mais il est bien d'ajouter un mongos ou serveur de configuration ainsi), à moins que ce soit pour quelques tests simples .
acclamations, Derick
Le seul cas d'utilisation où j'ai trouvé l'exécution de plusieurs mongod sur le même serveur était d'augmenter la vitesse de réplication sur la connexion à latence élevée. Comme le souligne Derick, le verrou en écriture n'est pas vraiment votre problème lors de l'exécution de mongodb
Pour répondre à votre question: oui vous pouvez démontrer mise à l'échelle mongo avec plusieurs cas par machine (4 cas par SEMS serveur pour être assez) si votre test ne comporte pas trop de données (sinon la page en sera considérablement decrase votre performance , Je l'ai déjà testé)
Cependant, les instances concurrenceront toujours pour les ressources. Tout ce que vous réussirez à faire est de déplacer le problème de verrouillage de la base de données vers un problème de verrouillage des ressources.
Je ne suis pas du tout d'accord. Nous exécutons 8 fragments par boîte dans notre configuration. Il se compose de deux nœuds de tête, chacun avec deux autres machines pour la réplication. 6 boîtes au total. Ce sont des boîtes costaudes avec environ 120 Go de RAM, 32 coeurs et 2 To chacun. En ayant 8 fragments par boîte (nous pourrions aller plus haut par la façon dont cela est fixé à 8 à des fins historiques), nous nous assurons que nous utilisons efficacement le processeur. La RAM se trie. Vous devez regarder les métriques et vous assurer que vous ne paginez pas trop mais avec des disques SSD (ce que nous avons) si vous débordez sur les disques, ce n'est pas si mal.
Comment la RAM se débrouillerait-elle? Aussi, avez-vous décidé d'avoir autant de tessons pour un débit d'écriture plus élevé ou autre chose? – iCode
Nous avons utilisé le Mongo Map Reduce (MR) et il a besoin de la puissance du processeur pour traiter toutes les données. Le sharding d'origine a été configuré avec un fragment par cœur. Cela nous a donné le maximum de CPU. Depuis lors, la boîte a été améliorée et nous sommes maintenant à un fragment par 4 cœurs. En ce qui concerne la mémoire, il s'agit d'un exercice pour conserver les index dans la RAM. Les données ne vont jamais, alors ne vous en inquiétez même pas. Nous surveillons la taille de notre index par rapport à la RAM et nous avons mis à jour pour accommoder. Nous avons également abandonné les index dont nous n'avons pas besoin. –
Oui, vous pouvez et en fait c'est ce que nous faisons pour 50 + mil base de données d'écriture lourde. Assurez-vous simplement que tous vos index par mongod s'inscrivent dans la RAM et qu'il y a de la place pour la croissance et la maintenance. Cependant, il y a un petit compromis: selon ce que votre QPS cible est, ce type de partage nécessite des machines avec plus de puissance, alors que le sharding sur une seule machine ne le fera pas et dans la plupart des cas, vous pouvez vous débarrasser de la marchandise, matériel moins cher. Quoi qu'il en soit, effectuez la série de tests de performance (ageinst IO, Network, PQS, etc.) et établissez votre base de données avec soin, en considérant que les disques SSD sont stockés, mais le stockage Linux XFS est également important. .
100 fragments est probablement trop nombreux, mais je ne serais pas surpris si vous obteniez de meilleures performances d'écriture avec quelques fragments sur un serveur costaud. Pourquoi ne pas avoir vos fragments sur des serveurs séparés et moins costauds, comme d'habitude? Quel type d'insertion/mise à jour prévoyez-vous obtenir? –
La raison principale est la disponibilité pour un POC que j'ai besoin de faire et je me demande si je pourrais simuler un environnement de partition pour le serveur que j'ai disponible. Je suppose qu'un serveur avec 8 cœurs et 32 Go de RAM est considéré comme costaud.J'espère obtenir 1000 écritures concurrentes et 10.000 lectures simultanées où chaque demande de lecture ou d'écriture ne prendra pas plus de 0.5second à être entretenu par la base de données. Est-ce que c'est même raisonnable avec MongoDB? La taille du résultat de la requête de chaque lecture et la quantité de données à écrire n'est pas grande et il s'agit principalement de la gestion des nombreuses demandes de lecture ou d'écriture simultanées sur la base de données. – iCode
Votre avis ici est apprécié. Est-ce que j'ai même du sens? – iCode