Multi-tenancy is an architectural approach that enables a single instance of an application to be shared among multiple organizations/users,also called tenants.
According to Oracle Multitenant’s description on IT Central Station, multitenant architecture is “a new architecture that enables customers to easily consolidate multiple databases, without changing their applications.”
"Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations..."
In SaaS, usually a multitenant application has one software layer and one database, but each customer logs in to what appears to be his exclusive app environment. He can only see and manage its own information.
Sometimes, single customer applications can be easily converted into a multitenant application by using "database schemas" (as provided by Postgres, but not MySQL).
In SaaS, usually a multitenant application has one software layer and one database, but each customer logs in to what appears to be his exclusive app environment. He can only see and manage its own information.
Sometimes, single customer applications can be easily converted into a multitenant application by using "database schemas" (as provided by Postgres, but not MySQL).
Multi-tenancy allows a single application instance to be served for multiple tenants on a single hosting server. This is usually performed by either separating databases, separating schemas, or sharing schemas. This architecture therefore allows for a single instance to service different companies. Multi-tenancy works by using the concept of tenants, each tenant has access only to his corresponding data, even if they are in the same or different database. It means that you can have multiple tenants (usually one per client) who will use your application as if it were a single application. Amazing, isn’t it?
Multi-Tenancy Implementation: Software Architecture
Let’s start with the basic, multi-tenancy has three different ways to implement:
- Separate databases: Each tenant has its own database.
- Separate schemas: Tenants share common database but each tenant has its own set of tables (schema).
- Shared schema(Discriminator Based): Tenants share common schema and are distinguished by a tenant discriminator column.
Read Here more : Way of multitenancy implementation from database side.
No choice is better than another, every choice has different advantages and disadvantages, therefore it all boils down to what you want to compromise:
- Quantity of tenants
- Performance
- Time of development
- Reliability
- Disaster recovery
- And so on…
Factors that matters in multitenancy:
A number of factors, including economic, security, skill set, etc., contribute to the selection of the best suitable configuration. In this post, from my experience, I’ll share the following practical requirements that introduce additional implementation challenges:- Each account needs to have a maximum allowed space on the database (economic).
- Data from one account should never be accessible to other accounts (security).
- However, for backend usage, we need the ability to run queries across all accounts.
- Size limiting is quite hard. It almost forces the use of a separate database or schema per account. Even then, most databases today don’t have a clean mechanism to exert such a hard limit.
- Separate databases reduce the chance of cross-account data leaks. But backend tasks suffer for this. For example, your monthly billing processor needs to generate a bill for all accounts. With one database per account, it cannot do one simple query to a single database anymore.
- Also, most ORM libraries don’t support separate databases for a single type. For example, to fetch the orders from the database, the ORM library needs to connect to database A for account X, but to database B for account Y and so on. At this point, if possible, you’ll need to tweak the ORMs a lot or fall back to your own ORM, which is almost never a good idea.
- Connection pooling is another challenge. It’s generally a good practice to use connection pooling, to save the overhead of establishing a connection before every query. With separate databases, and hundreds, if not thousands, of accounts being served from an app server, the connection pool would either have too many or too few connections in it to be useful.
References:
1. https://en.wikipedia.org/wiki/Multitenancy
2. https://dzone.com/articles/multi-tenancy-using-jpa-spring-and-hibernate-part
3. https://dzone.com/articles/implementation-challenges
Comments
Post a Comment