What is the recommended approach to multi-tenant databases in MongoDB?

Question

I am thinking of creating a multi-tenant application using MongoDB. I have no clue as to how many tenants I would have, but I would like to be able to scale thousands.

I can think of three strategies:

• All tenants in the same collection, using special fields for security
• 1 Tenant fee in one common database
• 1 Database for each tenant

A voice in my head suggests that I go with option 2.

Thoughts and consequences, anyone?

Answer 1

I need to solve the same problem, and also consider options. Since I have many years of experience creating multi-tenant SaaS applications, I was also going to choose the second option based on my previous experience with relational databases.

During my research, I found this article on the mongodb support site (a way back has been added since it left): https://web.archive.org/web/20140812091703/http://support.mongohq.com/ use-cases / multi -tenant.html

The guys said that they are avoiding 2 options at all costs, which, as I understand it, is not particularly characteristic of mongodb. I got the impression that this applies to most of the NoSQL databases I have studied (CoachDB, Cassandra, CouchBase Server, etc.) due to the design of the database.

Collections (or groups, or as they call them in different databases) are not the same as security schemes in a DBMS, despite the fact that they behave like a container for documents that are useless for applying the correct separation of clients. I could not find a NoSQL database that could apply collection-based security restrictions.

Of course, you can use mongodb role-based security to restrict database / server access. ( http://docs.mongodb.org/manual/core/authorization/ )

I would recommend the 1st option when:

• You have enough time and resources to deal with the complexity of designing, implementing, and testing this scenario.
• If you are not going to have big differences in the structure and functionality in the database for different tenants.
• The design of your application will allow tenants to make only minimal adjustments at runtime.
• If you want to optimize space and minimize the use of hardware resources.
• If you are going to have thousands of tenants.
• If you want fast and at a good price.
• If you are NOT going to back up data based on tenants (keep separate backups for each tenant). This can be done even in this scenario, but the effort will be tremendous.

I would go for option 3 if:

• You will have a small list of tenants (several hundred).
• The specifics of the business requires that you can maintain large differences in the database structure for different tenants (for example, integration with third-party systems, import-export data).
• The design of your application will allow customers (tenants) to make significant changes during the execution of the application (adding modules, setting fields, etc.).
• If you have enough resources to quickly scale with new hardware nodes.
• If you need to keep versions / backups of data for each tenant. Also, recovery will be easy.
• There are legislative / regulatory restrictions that force you to keep different tenants in different databases (even in data centers).
• If you want to make full use of mongodb's predefined security features, such as roles.
• There are large differences in size between tenants (you have many small tenants and few very large tenants).

If you post more information about your application, I may be able to give you more detailed advice.

Answer 2

I found a good answer in the comments at this link:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

Basically, option # 2 seems to be the best way.

Quote from David Mitton's comment:

We decided not to have a database for the client because of how MongoDB allocates its data files. each database uses its own set of files:

The first file for the database is dbname.0, then dbname.1, etc. dbname.0 will be 64MB, dbname.1 128MB, etc., up to 2GB. Once files reach 2 GB in size, each subsequent file is also 2 GB.

Thus, if the last data file is present, say 1 GB, this file can be 90% empty if it has recently been reached.

from the manual.

As users subscribe to the trial and let everything go, marry more and more databases, which are at least 2 GB in size, even if all the data in the file has not been used. We found that it used a huge amount of disk space to have multiple databases for all clients, where disk space could be used for maximum efficiency.

The cladding will be included in each collection as a standard, which is a problem when the collection never reaches the minimum size to start shards, as in the case of quite a few of ours (for example, collections simply store data for logging in). However, we asked that it also be able to make a level in each database. See http://jira.mongodb.org/browse/SHARDING-41

There are no tradeoffs in performance using multiple collections. See http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Answer 3

There is a reasonable article on MSDN about the multi-tenant data architecture that you might want to refer to. Some key topics covered in this article:

• Economic considerations
• Security
• Tenant Recommendations
• Normative (legal)
• Skill poses challenges

Some software as a service (SaaS) configuration patterns are also affected.

In addition, gander is worth an interesting entry from the SQL Anywhere guys .

My own personal approach - if you are not sure about the forced security / trust, I would go with option 3, or if scalability problems at least prohibit returning to option 2. Nevertheless ... I'm not a professional with MongoDB. I am very nervous using the general “scheme”, but I will be happy to treat more experienced practitioners.

Answer 4

I would choose option 2.

However, you can set the mongod.exe --smallfiles command line option. This means that the maximum file size is 0.5 gigabytes, not 2 gigabytes. I tested this with mongo 1.42. Therefore, option 3 is not impossible.

Answer 5

While the discussion here is about NoSQL and primarily MongoDB, we at Postus use PostgreSQL and create a distributed / tenant database.

Our file usage guide looks at an example application covering the schema and various specific functions of several tenants.

For more unstructured data, we use the PostgreSQL JSONB column to store such data and data related to the tenant.

Answer 6

According to my research at MongoDB. Trucos y consejos. Aplicaciones multitenant. this option is not recommended if you do not know how many tenants you can have, there can be several thousand, and it will be difficult when it comes to sharding, also imagine that there are thousands of collections in one database ... So in your case it is recommended to use the first option. Now, if you have a limited number of users, it is already different, and yes, you can use the second option, as you thought.