.jpg)
MultiTenant vs. Single Tenant: Choosing the right DBaaS Data Store from the start
Thursday, November 17, 2016
|
Michael Russo |
The Database-as-a-Service (DBaaS) model is an attractive option for rapid deployment of managed database assets in the cloud. If you’re thinking of using a DBaaS to power your cloud-based application’s database, you’ll want to understand the pros and cons of multi-tenant versus single-tenant datastores for housing your data. Both approaches have merit and by understanding the strengths of each, you can arrive at a choice that best fits for your specific requirements.
It might be helpful to think of multi-tenant DBaaS like housing your data in an apartment complex. You have your own space in the building, but you share walls with other families. You enjoy cost benefits from this arrangement and, it’s usually a simple task to secure a new lease and start moving in, but sometimes your neighbor throws a party and the noise affects your quality of life. You also must agree to a series of common rules when living in an apartment complex, so you don’t have full control over your environment.
Under the right circumstances, the multi-tenant shared model can deliver lower costs plus general reliability and adequate performance. This is especially true when your operational requirements are not particularly rigid. For instance, a typical WordPress blog with low to modest load can deliver a good end user experience with database response times from milliseconds to seconds, depending on the overall utilization of the database cluster. For scenarios where slight fluctuations in response times are acceptable, multi-tenant datastores are a great way to lower your cloud expenditures. While a properly-designed shared model will likely have mechanisms to prevent any particular task from monopolizing resources such as memory, CPU, bandwidth, etc., it will still be subject to varying performance as the load from individual tenants changes.
As mentioned, housing multiple database tenants on a single cluster can introduce restrictions. Take the example of a single database engine on a shared cluster; the software instance is also shared in this case, which provides the most efficient use of resources. This approach however, may make it impossible to implement certain features, especially those that by design might monopolize certain system resources. Some configurations must be set globally across a cluster and cannot be set differently for each tenant; for example, the localization settings of the database software may be fixed for all tenants.
If multi-tenant cloud datastores are like housing your data in an apartment complex, then single-tenant cloud datastores are like buying your data a single-family home. While the power of your infrastructure may determine whether your data lives in a cozy 2-bedroom cottage or a luxurious mansion on 20 acres of land, there are certain universal benefits to single-tenant that apply in all cases. As the single inhabitant of your castle, you can expect an improved quality of life plus more control over your environment.
Single tenant DBaaS models typically do not have the limitations noted in the multi-tenant discussion. The absence of shared resources means tenants enjoy consistent performance that can’t be impacted by noisy neighbors. That’s an extremely important benefit for mission critical applications that must deliver an optimal and consistent user experience.
You’ll typically gain a number of environmental control benefits with single-tenant cloud datastores, such as the ability to lock down a cluster with client-side certificates, or use of IP whitelisting. There is less need to enforce restrictive access controls to prevent co-mingling of information. The ‘simpler’ environment of single tenant systems also translates to easier diagnosis and remediation of issues, should they occur. From an operations standpoint, there is no need for concern about how actions such as restarts or backups will affect other users.
The majority of DBaaS users find multi-tenant restrictions absolutely acceptable for their small to moderate workloads. Some use multi-tenant databases for test/dev or staging environments, opting for the more powerful single-tenant services for their production workloads. For mission critical workloads and critical applications, single-tenant datastores are almost always the better choice.
Both multi-tenant and single-tenant environments have their merits, so a simple analysis of your own requirements up-front can help you choose the optimal path forward. As with any deployments, you are urged to choose wisely as changing the deployment model after the fact is seldom painless.
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.
It might be helpful to think of multi-tenant DBaaS like housing your data in an apartment complex. You have your own space in the building, but you share walls with other families. You enjoy cost benefits from this arrangement and, it’s usually a simple task to secure a new lease and start moving in, but sometimes your neighbor throws a party and the noise affects your quality of life. You also must agree to a series of common rules when living in an apartment complex, so you don’t have full control over your environment.
Under the right circumstances, the multi-tenant shared model can deliver lower costs plus general reliability and adequate performance. This is especially true when your operational requirements are not particularly rigid. For instance, a typical WordPress blog with low to modest load can deliver a good end user experience with database response times from milliseconds to seconds, depending on the overall utilization of the database cluster. For scenarios where slight fluctuations in response times are acceptable, multi-tenant datastores are a great way to lower your cloud expenditures. While a properly-designed shared model will likely have mechanisms to prevent any particular task from monopolizing resources such as memory, CPU, bandwidth, etc., it will still be subject to varying performance as the load from individual tenants changes.
As mentioned, housing multiple database tenants on a single cluster can introduce restrictions. Take the example of a single database engine on a shared cluster; the software instance is also shared in this case, which provides the most efficient use of resources. This approach however, may make it impossible to implement certain features, especially those that by design might monopolize certain system resources. Some configurations must be set globally across a cluster and cannot be set differently for each tenant; for example, the localization settings of the database software may be fixed for all tenants.
If multi-tenant cloud datastores are like housing your data in an apartment complex, then single-tenant cloud datastores are like buying your data a single-family home. While the power of your infrastructure may determine whether your data lives in a cozy 2-bedroom cottage or a luxurious mansion on 20 acres of land, there are certain universal benefits to single-tenant that apply in all cases. As the single inhabitant of your castle, you can expect an improved quality of life plus more control over your environment.
Single tenant DBaaS models typically do not have the limitations noted in the multi-tenant discussion. The absence of shared resources means tenants enjoy consistent performance that can’t be impacted by noisy neighbors. That’s an extremely important benefit for mission critical applications that must deliver an optimal and consistent user experience.
You’ll typically gain a number of environmental control benefits with single-tenant cloud datastores, such as the ability to lock down a cluster with client-side certificates, or use of IP whitelisting. There is less need to enforce restrictive access controls to prevent co-mingling of information. The ‘simpler’ environment of single tenant systems also translates to easier diagnosis and remediation of issues, should they occur. From an operations standpoint, there is no need for concern about how actions such as restarts or backups will affect other users.
The majority of DBaaS users find multi-tenant restrictions absolutely acceptable for their small to moderate workloads. Some use multi-tenant databases for test/dev or staging environments, opting for the more powerful single-tenant services for their production workloads. For mission critical workloads and critical applications, single-tenant datastores are almost always the better choice.
Both multi-tenant and single-tenant environments have their merits, so a simple analysis of your own requirements up-front can help you choose the optimal path forward. As with any deployments, you are urged to choose wisely as changing the deployment model after the fact is seldom painless.
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.
Become a subscriber of App Developer Magazine for just $5.99 a month and take advantage of all these perks.
MEMBERS GET ACCESS TO
- - Exclusive content from leaders in the industry
- - Q&A articles from industry leaders
- - Tips and tricks from the most successful developers weekly
- - Monthly issues, including all 90+ back-issues since 2012
- - Event discounts and early-bird signups
- - Gain insight from top achievers in the app store
- - Learn what tools to use, what SDK's to use, and more
Subscribe here
