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 my first post on Multi-Tenant Database Architectures, I outlined the various factors that must be considered when choosing a multi-tenant architecture. In my second post I examined the “Separate server” and “Shared server, separate database server process” architectures. In this third post, I will outline the “Shared database server process, Separate database” model.
I am compelled to reiterate that there is no “one-size-fits-all” approach to implementing a multi-tenant database, only trade-offs. You must choose the correct approach for your needs based on the specific requirements you have for your business.
Shared Database Server, Separate Database
This architecture builds on the separate server process model in that each tenant continues to use their own database, but there is only a single database server process. Several tenants share a single server machine, as well as a single database server process. This approach continues to allow each tenant to have their data isolated from other tenants. An improvement is that the single database server process can share resources such as database cache effectively between tenants. This allows for improved utilization of machine resources, at a modest reduction in performance predictability for each tenant.
Many of the factors to consider will remain similar to the previously described models in which each tenant has their own database:
- Development time – There is minimal additional development time when compared to an on-premise solution.
- Hardware cost – This architecture allows for improved utilization of machine memory resources, however still requires overhead for unique databases per tenant.
- Application and database performance – The performance of one tenant may be impacted by the activities of other tenants sharing the server machine.
- Security – Each tenant has their own database, completely isolating them from other tenants.
- Customization requirements – Each tenant has their own database, so it is easy to customize the database schema for the differing needs of each tenant.
- The number of tenants – Able to handle more tenants than the separate server approach, but still limited based on the need to administer and store separate database files for each tenant.
Similar to the previous model, migration of tenants is easily accomplished for tenants who require improved performance and isolation. Using SQL Anywhere, a tenant can be moved to their own machine simply by moving the database file. This relies on the self-contained and machine independent nature of SQL Anywhere database files.
This is the model implemented by our SQL Anywhere on-demand edition.
- SAP Managed Tags:
