5 raisons d'installer une base de données MongoDB locale

Pourquoi installer une base de données MongoDB locale ?

L'exploitation d'une base de données MongoDB dans le nuage présente de nombreux avantages. Vous pouvez mettre en ligne des grappes de serveurs rapidement, et tout le réseau est géré et sécurisé. Tous vos utilisateurs peuvent y être connectés et les sauvegardes sont automatisées. Un service comme Atlas est idéal pour ce genre de choses. Mais il y a des moments où vous pouvez vouloir installer votre propre MongoDB local et il y a de bonnes raisons de le faire. En voici cinq :

1 : Libre sans limites

De nombreuses bases de données en nuage proposent un niveau gratuit. Ce niveau gratuit est généralement limité. Prenons l'exemple du niveau gratuit M0 de MongoDB Atlas, où les limitations commencent avec une capacité de stockage maximale de 512 Mo et incluent une série de restrictions parce que la base de données se trouve sur une plateforme partagée. Si vous installez votre propre base de données MongoDB localement, vos seules limites sont l'espace disque et la mémoire vive dont vous disposez pour faire fonctionner votre base de données.

2 : Pas besoin d'être en ligne

Cela peut sembler évident, mais une base de données en nuage signifie que vous devez être en ligne sur l'internet pour vous y connecter. Si vous voyagez ou travaillez dans un endroit où la connectivité est limitée, cela peut poser problème. Pire encore, si cette connectivité est payante et que le tarif est élevé. Chaque requête et chaque résultat vous coûteront de l'argent.

3 : décalage nul

Lorsque vous utilisez une base de données en nuage, la latence de l'Internet entre également en jeu, ce qui se traduit par des millisecondes supplémentaires pour chacune des requêtes que vous effectuez à partir d'une application. Bien qu'il soit difficile de repérer ce décalage dans une application GUI pilotée par l'utilisateur comme Studio 3T, ce décalage sera toujours présent (à moins que la 5G ne fonctionne comme elle l'a promis... non, ne retenez pas votre souffle).

4 : Aussi rapide que votre machine locale

L'exécution locale de votre base de données signifie que toute la puissance de votre processeur local est disponible pour les tâches les plus intensives. Les bases de données en nuage partagées doivent, par conception, être de bons voisins pour les autres bases de données fonctionnant sur les mêmes hôtes. Il y aura donc des limites raisonnables. Sinon, vous constaterez que les performances baissent de temps à autre lorsque quelqu'un d'autre exécute une tâche à forte intensité de calcul. Lorsque vous travaillez en local, vous êtes seul en concurrence pour les ressources.

5 : Réplication gratuite

À moins que vous n'utilisiez quelque chose comme Docker et que vous ne configuriez vous-même un mini-cluster localement, votre MongoDB local sera une instance unique de MongoDB. Cela signifie qu'il n'aura pas à répliquer les données vers une autre instance de MongoDB pour la rendre hautement disponible. Cela signifie que vous disposerez de plus de ressources pour vos applications.

À qui s'adresse donc cette version locale de MongoDB ?

Toute personne qui fait du développement et qui n'a pas besoin de se brancher sur les systèmes de production. (Studio 3T peut les aider à obtenir de vraies données de test grâce à l'utilisation du masquage de données).

Toute personne souhaitant traiter des données qui sont normalement critiques pour la production sans avoir d'impact sur le processus de production. Studio 3T peut aider à exporter ces données vers la base de données locale grâce à ses fonctions d'exportation.)

ou qui a besoin d'une base de données mais n'a pas accès à l'internet

et tous ceux qui ont besoin d'une base de données locale efficace et gratuite

Mais... les arguments contre MongoDB local

Bien sûr, il y a des mises en garde à ce sujet.

Production - MongoDB sera toujours un cluster de trois machines ou plus exécutant MongoDB. L'exécution d'un serveur MongoDB local autonome est très performante, mais c'est tout.

Réplication, latence et autres personnes - si vous développez sur un MongoDB autonome, ne vous attendez pas à la même performance lorsque vous transférez votre application sur le nuage. Le cluster de production fera de la réplication, il sera distant et il y aura de la latence, et si vous allez en production sur une plateforme partagée, il y aura d'autres personnes en compétition pour les ressources. Ce n'est pas une raison pour ne pas construire localement, mais plutôt pour tester dans le nuage afin de s'assurer que vous n'avez pas trop appuyé sur le bouton de performance.

Absence de sauvegardes - À moins que vous ne soyez bien organisé et que vous ne sauvegardiez votre ordinateur portable ou de bureau, il est probable que votre base de données ne soit pas sauvegardée. Si vous corrompez ou supprimez accidentellement vos données, vous devrez les recréer.

Pas de fonctionnalités telles que le cryptage au repos et d'autres options d'entreprise - Si vous optez pour l'édition communautaire de MongoDB, vous ne pourrez pas utiliser les diverses fonctionnalités d'entreprise, mais, cela dit, la plupart d'entre elles sont des fonctionnalités opérationnelles/déploiement pour les grands déploiements.

Sécurité - vous êtes responsable de la sécurité sur votre machine locale. Lorsque vous installez MongoDB, il ne se lie qu'à l'hôte local, mais attention ! Si vous vous liez à une adresse IP pour donner à d'autres l'accès à votre MongoDB, vous avez ouvert une boîte de Pandore - vous devrez vous assurer que vous avez des utilisateurs et une authentification configurés pour gérer les connexions entrantes.