Friday, July 10, 2009

Benefits and disadvantages of multi-tenancy

One of the main advantages of an ideal multi-tenant application is the operational benefit. Because all application code is in one place, it is much easier (and cheaper!) to maintain, update and backup the application and its data.

Another advantage of multi-tenancy is the lower system requirements. Because an application and database are shared by multiple clients, it is not necessary to have a dedicated server for every client. This is a clear improvement in resources utilization.

Because multiple clients share a server, scalability may become a problem. In single-tenant applications, all clients have their own resources and whenever a new client wants to use the application, resources are added. In multi-tenant applications, all clients share the same resources and it is possible that, at some point, these resources become overloaded. Something that influences the time before this point is reached, is the database implementation of the application (see 'Supporting Database Applications as a Service'). One can define roughly three implementations of multi-tenancy databases:
  • Independent database, independent database instances (IDII)
  • Independent tables, shared database instances (ITSI)
  • Shared tables, shared database instances (STSI)
Clearly, IDII is not a real multi-tenant database approach. However, it is one that is quite often used as it is very easy to implement. The obvious downside of this approach is that it is very heavy on resources: for example, starting a MySQL database requires about 30M memory. When multiple instances are started, the system will run out of memory quickly.

ITSI is a semi-multi-tenant solution, in which all clients use the same database, but each have their own tables. This approach suffers from the same problem as IDII, however it does take longer before the limits are reached, as a table instance requires less memory than a database instance.

With regard to resources, the ideal solution is STSI. All tenants are in the same table and retrieve their records using the SQL syntax 'SELECT .... WHERE tenant_id = xxx'.

The problem with the STSI approach can be described as an isolation problem. Because application and database are shared, it is important that tenants are isolated from each other regarding security, customization performance, etc. In a next blog post I will discuss ways to isolate tenants from each other in more detail.

2 comments:

  1. In an STSI, indexes can become huge and inserting a new tenant into the database will be very slow. Queries can also become very slow. How does that influence the choice of architecture?

    ReplyDelete