CODEWITHSUNDEEP
node.jsmongodbexpressarchitecturemern
Devansh Jain
Devansh Jain

Reputation: 21

Running two instances of MongoDB

I am working on a highly I/O Intensive application (A selection based on the availability of seats) using MERN Stack. The app is expected to get 2000 concurrent users. I want to know whether it's wise to use two instances of MongoDB, one on the RAM (in memory) and another on the Hard drive.

The RAM one to be used to store the available seats. And the Hard drive one to backup the data after regular intervals. But at the same time I know that if the server crashes my MongoDB data on the RAM is lost.

Could anyone guide me please?

I am using Socket IO instead of AJAX...

Upvotes: 1

Views: 1515

Answers (3)

Markus W Mahlberg
Markus W Mahlberg

Reputation: 20703

What you are talking about is a scaling problem. You have two options when it comes to scaling: Add resources causing the bottleneck to your existing setup (more RAM and faster disks, usually) or expand your setup. You should first add resources, almost up to the point where adding resources does not give you an according bang for the buck.

At some point, this "scaling up" will not be feasible any more and you have to distribute the load amongst more nodes.

MongoDB comes with a feature for distributing load amongst (logical) nodes: sharding.

Basically, it works like this: multiple replica sets each form a logical node called a shard. Each shard in turn only holds a subset of your data. Instead of connecting to the shards directly, you acres your data via a mongos query router which is aware of which shard holds the data to answer the query and where to write new data.

By carefully selecting your shard key, your reads and writes should be evenly distributed between the shards.

Side note: putting production data on a standalone instance instead of a replica set crosses the border of negligence in my book. Given the prices of today's (rented) hardware, it has never been easier to eliminate a single point of failure than with a MongoDB replica set.

Upvotes: 0

Philipp
Philipp

Reputation: 69663

This seems unnecessary, because MongoDB already behaves exactly like that out-of-the-box.

The old engine (MMAPv1) was using memory-mapped files, which means that if you have as much RAM as you have data, it practically behaves like an in-memory database with automatic hard-drive backing.

The new engine (Wired Tiger) works a bit different in detail, but the same in general. It allows you to set a cache size (config key storage.wiredTiger.engineConfig.cacheSizeGB). When the cache size is as large enough, you again have an in-memory database with automatic hard-drive mirroring.

More about that in the storage FAQ.

Upvotes: 2

andresk
andresk

Reputation: 2845

I don't think you need this. You can get a good server, with a good amount of RAM, and if you create your indexes correctly, everything should work fine.

Also Mongo 3 won't lock the entire database on each update, like Mongo 2 used to do.

I believe the best approach would be using something like Memcached in order to improve reads. Also, in order to improve database performance and have automated failover use sharding and replica sets.

Consider also that you would have headaches when your server restarted and you lose your data...

Upvotes: 2

Related Questions