Quel matériel fait un bon serveur MongoDB? Où l'obtenir?

Supposons que vous soyez sur dell.com en ce moment et que vous achetez un serveur pour exécuter votre base de données MongoDB pour votre petite startup. Vous devrez gérer littéralement des dizaines de milliers d'écritures et de lectures par minute (mais de petits objets). Opteriez-vous pour 2 processeurs? Investissez plus sur la RAM?

J'ai entendu (corrigez-moi si je me trompe) que MongoDB gère le plus possible sur la RAM, puis vide tout sur le disque, dans ce cas, je devrais investir dans un processeur avec un grand cache L2, probablement> 40 Go de RAM et un disque SSD .. non?

Serais-je mieux avec un serveur haut de gamme (~ 11 309 $, 2 processeurs coûteux, 96 Go de RAM) ou 2 serveurs (~ 6 419 $, 2 processeurs coûteux, 12 Go de RAM)?

Dell est-il ok ou avez-vous de meilleures suggestions? (Je suis en dehors des États-Unis, au Portugal)

Au départ, vous voudrez renforcer la RAM. La RAM dont vous aurez besoin dépend de la quantité de données que vous stockez, du nombre de collections, des index sur ces collections, des modèles d'accès aux données, etc. Beaucoup de facteurs.

La chose la plus importante est d'avoir suffisamment de RAM pour conserver vos index dans la RAM. Sinon, vos performances en souffriront considérablement car vos serveurs afficheront constamment des pages pendant que Mongo déplace les fichiers mappés en mémoire dans et hors de la RAM. Malgré tout cela, nous n'avons pas vu la vitesse d'écriture affectée, mais tout le reste l'est. Le traitement écrit la file d'attente, le vidage, les vidages, etc. prennent tous un coup dramatique une fois que vos index ne tiennent plus dans la RAM.

Il n'y a donc pas de vraie réponse courte. Fondamentalement, soyez intelligent dans vos index. N'utilisez que ce dont vous avez besoin. Gardez les collections petites si vous le pouvez (c.-à-d. Répartissez-en plusieurs là où vous le pouvez.) Les collections plafonnées sont également intéressantes à examiner.

Il est très important d'utiliser une machine 64 bits et non 32 bits. http://blog.mongodb.org/post/137788967/32-bit-limitations

Avec MongoDB, vous voulez de la RAM. Et puis un peu plus de RAM. L'achat de RAM ne peut pas nuire.

Si vous êtes au stade de l'achat de matériel de production, l'application que vous exécutez doit déjà être écrite, non? Exécutez donc l'application sur le matériel dont vous disposez et prenez des mesures. Modifiez progressivement certains composants et prenez plus de mesures. Lorsque vous aurez terminé, vous saurez quels points de focalisation sont les plus importants pour votre application et votre scénario.

Tout d'abord - achetez autant de RAM que possible. Le deuxième facteur limitant est la vitesse du disque. RAID aide. SSD aide. Plus d'éclats aident. Mesurez le débit en comparant l'efficacité du disque et les temps de réponse requis, puis décidez quoi faire dans le cadre du budget dont vous disposez.

Je me demande si une solution en cluster Linux serait une alternative meilleure et moins chère.

MongoDB vous permet de distribuer des données sur de nombreux serveurs. Ce sera impossible avec un seul serveur klaxonnant.

Je pensais que MongoDB était l'une des étapes suivantes après avoir découvert que le déploiement d'une base de données relationnelle sur un serveur de klaxon n'était pas assez évolutif.

Des dizaines de milliers d'écrits par minute, ce n'est rien. Vous pouvez obtenir 50 000 écritures ou plus par seconde sur du matériel décent. Les spécifications matérielles dépendent vraiment de ce que vous essayez de faire. En général, suffisamment de RAM pour de grandes bases de données et des systèmes d'E / S rapides sont importants à côté d'un CPU décent ...

Il est important d'établir une base de référence solide avant de concevoir votre matériel. Attendez-vous généralement à ce que ces questions soient posées par les gens expérimentés de mongoDB avant que quiconque puisse même envisager de répondre à votre question.

Statistiques d'application actuelles (le cas échéant)

• Total des enregistrements à ce jour?
• Début de l'estimation du stockage?
• % De croissance prévu / mois?
• Taille moyenne du document?

Charge de travail d'ingestion de données

• Nouvelles insertions / jour, pointe et moyenne par seconde?
• Mises à jour / jour, pointe et moyenne par seconde?
• Lectures / jour, pointe et moyenne / seconde?
• Nombre moyen de documents retournés par requête: 70
• Suppressions / jour, pic et moyenne / seconde: aucune
• Y aura-t-il des chargements / mises à jour groupés? Si oui, de quelle taille et à quelle fréquence?
• Combien de types de documents différents y aura-t-il?
• Combien de chacun?
• À quoi pensez-vous que vos documents ressembleront (exemple de document)?

Modèles de requête et attentes en matière de performances

• Lire le SLA de réponse?
• Écrire un SLA de réponse?
• Les lectures sont-elles basées sur une plage ou aléatoires?

Modèles d'accès prévus

• Nombre d'indices secondaires requis?
• Nombre d'attributs?
• Conditions de tri?
• Simple ou composé?