CODEWITHSUNDEEP
node.jsmongodbdevops
Phương Hầu
Phương Hầu

Reputation: 89

Which MongoDB scaling strategy (Sharding, Replication) is suitable for concurrent connections?

Consider scenario that

The problem becomes apparent that while 50 instances is running at the same time, but only 5 people actually perform read/write operations against their own instances. So other 45 running instances waste the server's resources.

Should I use only one MongoDB cluster by combining a set of MongoDB instances ,for everyone so that they can connect to 1 endpoint only (via internal network) to avoid wasting resources.

I am considering the sharding strategy, but the problem is there are chances that if one node taken down (one VM shut down), is that ok for availability (redundancy)?

I am pretty new to sharding and replication, looking forward to know your solutions. Thank you

Upvotes: 0

Views: 142

Answers (1)

D. SM
D. SM

Reputation: 14520

If each developer expects to have full control over their database deployment, you can't combine the deployments. Otherwise one developer can delete all data in the deployment, etc.

If each developer expects to have access to one database, you can deploy a single replica set serving all developers and assign one database per developer (via authentication).

Sharding in MongoDB sense (a sharded cluster) is not really going to help in this scenario since an application generally uses all of the shards. You can of course "shard manually" by setting up multiple replica sets.

Upvotes: 1

Related Questions