MongoDB – Hosting Multiple Databases on One Instance or Cluster

mongodb

In MongoDB there are the following conecpts:

A MongoDB database exists as a logical unit on a MongoDB Instance which is either a singleton or a cluster running within some number of mongod processes on some number of servers.

There is lots of Q&A around answering the question: Should one run multiple production mongod processes on the same server? to which the answer is: In general no.

However, what about the question of having multiple production databases on the same instance? I.e.:

Set up a production grade mongodb cluster,
Create a number of databases by doing something like

use someDatabase; 
db.someDatabase.insert({});

3.Creating a User/Role that is limited in access to someDatabase

The above described configuration could obviously suffer from the noisy neighbor problem (& related DoS attacks), but otherwise is the above considered a normal and standard way of providing a logical & security barrier between tenants? What are the pros/cons of doing so? If I needed to migrate one of these logical DBs to its own MongoDB instance, would that be possible?

Best Answer

Q1. what about the question of having multiple production databases on the same instance?

A: It is very normal to have multiple databases on same instance.

Q2. Creating a User/Role that is limited in access to someDatabase the above considered a normal and standard way of providing a logical & security barrier between tenants?

A: Database level authorization, works very effectively for limiting the user access rights on databases, it is safe to use.

Q3. If I needed to migrate one of these logical DBs to its own MongoDB instance, would that be possible?

A. You cannot have two databases with same name on same instance or cluster.

(If more details required, do ask)

Related Solutions

MongoDB deployment best practices

In order :

There is one reason to have multiple mongod instances in one machine (other than machine efficient repset setups) and that one reason is the process wide write lock. If you run into a situation where you're bottlenecked by the write lock rather than any hardware resource bottleneck you can go for multiple mongod instances. In all other situations it's usually more practical to have one mongod process, especially given it's memory mapped based storage engine.
There's no ideal number. Adding shards (almost) linearly scales up write and read performance for sharded collections. It's a basic horizontal scaling solution and follows the rules for that sort of scaling.
Replica sets always consist of at least 3 members although 1 of them can be an arbiter (votes but does not replicate). If you add more you gain read performance if your application uses slaveOk flagged queries. Again, ideal number depends on your use case.
Depends. Most people use a hot backup scheme of some sort. There's no difference between MySQL backup conventions and MongoDB here.
Depends on whether or not you want to clone a single database or the entire cluster? Both are well documented.

MongoDB – Difference Between Sharding and Replication

A Replica-Set means that you have multiple instances of MongoDB which each mirror all the data of each other. A replica-set consists of one Master (also called "Primary") and one or more Slaves (aka Secondary). Read-operations can be served by any slave, so you can increase read-performance by adding more slaves to the replica-set (provided that your client application is capable to actually use different set-members). But write-operations always take place on the master of the replica-set and are then propagated to the slaves, so writes won't get faster when you add more slaves.

Replica-sets also offer fault-tolerance. When one of the members of the replica-set goes down, the others take over. When the master goes down, the slaves will elect a new master. For that reason it is suggested for productive deployment to always use MongoDB as a replica-set of at least three servers, two of them holding data (the third one is a data-less "arbiter" which is required for determining a new master when one of the slaves goes down).

A Sharded Cluster means that each shard of the cluster (which can also be a replica-set) takes care of a part of the data. Each request, both reads and writes, is served by the cluster where the data resides. This means that both read- and write performance can be increased by adding more shards to a cluster. Which document resides on which shard is determined by the shard key of each collection. It should be chosen in a way that the data can be evenly distributed on all clusters and so that it is clear for the most common queries where the shard-key resides (example: when you frequently query by user_name, your shard-key should include the field user_name so each query can be delegated to only the one shard which has that document).

The drawback is that the fault-tolerance suffers. When one shard of the cluster goes down, any data on it is inaccessible. For that reason each member of the cluster should also be a replica-set. This is not required. When you don't care about high-availability, a shard can also be a single mongod instance without replication. But for production-use you should always use replication.

So what does that mean for your example?

                            Sharded Cluster             
             /                    |                    \
      Shard A                  Shard B                  Shard C
        / \                      / \                      / \
+-------+ +---------+    +-------+ +---------+    +-------+ +---------+
|Primary| |Secondary|    |Primary| |Secondary|    |Primary| |Secondary|
|  25GB |=| 25GB    |    | 25 GB |=| 25 GB   |    | 25GB  |=| 25GB    |   
+-------+ +---------+    +-------+ +---------+    +-------+ +---------+

When you want to split your data of 75GB into 3 shards of 25GB each, you need at least 6 database servers organized in three replica-sets. Each replica-set consists of two servers who have the same 25GB of data.

You also need servers for the arbiters of the three replica-sets as well as the mongos router and the config server for the cluster. The arbiters are very lightweight and are only needed when a replica-set member goes down, so they can usually share the same hardware with something else. But Mongos router and config-server should be redundant and on their own servers.

Best Answer

Related Solutions

MongoDB deployment best practices

MongoDB – Difference Between Sharding and Replication

So what does that mean for your example?

Related Question