This set of articles was first published on my Sybase blog in 2009. Since that time, this 5 part series has been one of the most requested set of articles. As part of Sybase's integration with SAP, I am republishing them on the SAP SCN, and taking the opportunity to update them.
In Part 1, I outlined the various factors that must be considered when choosing a multi-tenant architecture. In this post I’ll examine the “Separate server” and “Shared server, separate database server process” architectures, and highlight the factors mentioned previously. Remember, there is no “one-size-fits-all” approach to implementing a multi-tenant database, only trade-offs.
Separate Server
The separate server architecture is at the extreme end of the spectrum of isolation. Each customer / tenant has a hosted server machine that only serves their database. This architecture may be appropriate for some customers who require a very high degree of isolation, have very large databases, a large number of users, or who have very specific performance requirements.
- Development time – The separate server model requires minimal additional development time when compared to an on-premise solution.
- Hardware cost – This is the most expensive architecture, because every tenant requires their own server hardware. Additionally, any fail-over implementation will further add to the cost.
- Application and database performance – This architecture has the most predictable performance, because one tenant’s performance is not impacted by any other tenant.
- Security – Because of the complete isolation from other tenants, each tenant’s data can be very securely locked down.
- Customization requirements – Each tenant has their own database, so it is the easiest to customize.
- The number of tenants – This approach makes it much harder to handle a very large number of tenants.
Shared Server, Separate Database Server Process
This architecture is similar to the separate server model in that each tenant has their own database. Several tenants share a single server machine, each with their own server process. This approach reduces the hardware costs for the hosting company, while still maintaining many of the isolation benefits.
- Development time – Theres is minimal additional development time when compared to an on-premise solution.
- Hardware cost – This architecture is cheaper that the separate server approach because several tenants share hardware, however both memory and storage may become an issue with each tenant having their own database files, and their own server process.
- Application and database performance – The performance of one tenant may be impacted by the activities of other tenants sharing the server machine. In practice, this may be minimized because there will likely be only a small number of tenants per server.
- Security – Each tenant has their own database, and server process, completely isolating them from other tenants.
- Customization requirements – Each tenant has their own database, so it is the easiest to customize.
- The number of tenants – Able to handle more tenants than the separate server approach.
Another operational factor comes into play with this model, and that is Migration of Tenants. With each tenant having a separate database, it is very easy to migrate tenants who require improved performance or isolation to their own machine with minimal effort.
The problem with this architecture arises because each tenant has their own database server process. These servers cannot share resources such as database cache effectively between tenants. While this allows improved predictability for each tenant, it does mean that a given server machine may not be fully utilized when one tenant could take advantage of unused space being held by another tenant’s server process.
This architecture also describes a typical virtualization environment. The resources on a given server machine are subdivided for each tenant. Each tenant has their own server process and database. Each virtualized operating environment reserving its own memory and disk resources, and is unable to share unused resources with other virtualized environments.
This Shared Server, Separate Database Server process model can be easily demonstrated with SQL Anywhere.
- SAP Managed Tags:
