Click “like” to see, form a habit, the public account search [dime technology] pay attention to more original technical articles. This article has been included in GitHub org_Hejianhui /JavaStudy.

preface

There’s a phrase we hear a lot in the cloud space: multi-tenant. This word has different meanings in different contexts. Next, I will summarize the previous projects from theory to practice, as well as practice a Demo. This paper first introduces the concept of multi-tenant in cloud platform and the idea of implementing multi-tenant support.

What is multi-tenancy

Multi-tenancy technology (also called multi-tenancy technology) is a software architecture technology that enables users to share the same system or program components in a multi-user environment (typically for enterprise users) and ensures data isolation among users. Simply put: A single application instance runs on a server, which provides services for multiple tenants (customers). As can be understood from the definition, multi-tenant is an architecture that enables the use of the same set of programs in multi-user environments and ensures data isolation between users. The key point of multi-tenant is the isolation of multi-user data under the same set of applications

Demand analysis

The traditional software mode refers to the sale of software products. It is a simple relationship of buying and selling. Customers acquire the right to use the software by buying it out, and the source code of the software belongs to customers.

The Saas model refers to a software service provided by a service provider. Applications are deployed on the server of the service provider, and customers can pay as required. Users buy web-based software instead of installing it on their computers, and they do not need to regularly maintain and manage the software


In SaaS platform, it is necessary to use a shared data center to provide the same or even customized services as most clients with a single system architecture, and still ensure the normal use of customer data. This creates a new challenge in how to design application data to support multi-tenancy by balancing data sharing, security isolation, and performance.

Multi-tenant database solution analysis

Currently, there are three database design schemes based on multi-tenancy:

  • Standalone database
  • Independent Schema Shared database
  • Share databases and share tables

Standalone database

This approach to standalone databases first requires that the business layer be able to support the configuration of multiple data sources and create or initialize a database for each tenant. The application and database are separate instances, so it does not interact with any other separate instances. It serves only one tenant and has a separate service, a separate database, and separate request processing.

Independent database: One database per tenant.

  • Advantages: Provide independent databases for different tenants, which helps simplify the extended design of the data model and meet the unique needs of different tenants; If a failure occurs, data recovery is relatively simple;
  • Disadvantages: Increased number of database installations, resulting in increased maintenance and acquisition costs.

This solution is similar to the traditional solution of one customer, one set of data, and one set of deployment, except that the software is uniformly deployed on the carrier. It can be seen that this scheme has high level of user data isolation and good security, but high cost.

Shared database, independent Schema

Shared database, independent Schema, is to put the data of multiple or all tenants in a database service, but establish an independent Schema for each tenant. Data between tenants is logically invisible to each other, and the implementation of the upper layer application is as simple as a standalone database. (Add: The schema in mysql data is special, it is not the next level of the database, but is equivalent to the database.)

Advantages: This device is suitable for tenants with high security requirements. Provides some degree of logical data isolation, but not complete; Each database can support a larger number of tenants.

Disadvantages: In the event of a failure, data recovery is difficult because restoring the database involves data of other tenants; There are difficulties if cross-tenant statistics are required. This scheme is a variant of scheme I. You only need to install one database service to isolate data from different tenants using different schemas. Because database services are shared, the cost is relatively low.

This scheme is a variant of scheme I. You only need to install one database service to isolate data from different tenants using different schemas. Because database services are shared, the cost is relatively low.

Share databases and tables

Sharing databases and tables: Tenants share the same Database and the same set of Database tables (all tenants’ data is stored in the same set of tables in the same Database). Add to the tableThe tenant IDEtc.The tenant signField indicating which tenant the record belongs to.

  • Advantages: All tenants use the same database, so the cost is low.
  • Disadvantages: Low isolation level, low security, need to increase the amount of security development during design and development, data backup and recovery is difficult.

This solution is no different from the database design based on traditional applications, but because all tenants use the same database tables, it is necessary to do a good job of isolating the security of each tenant’s data, which increases the complexity of system design and data management.

Choose a reasonable implementation pattern

The main consideration in measuring the three modes is whether they are isolated or shared.

Cost factor

The better the isolation, the more difficult and expensive the design and implementation, and the higher the initial cost. The better the sharing, the more users supported under the same operating cost, the lower the operating cost.

Safety factors

Consider business and customer security requirements. The higher the security requirements, the greater the preference for isolation.

In terms of the number of tenants

Consider the following factors

  • How many tenants does the system support? Hundreds of? Thousands or tens of thousands? The more possible tenants, the more likely they are to share.
  • Average space required by each tenant to store data. The more data you store, the more you tend to segregate.
  • The number of end users accessing the system simultaneously per tenant. The more support they need, the more they tend to segregate.
  • Whether you want to provide additional services for each tenant, such as data backup and recovery. The more demand there is, the more isolation there is

Technical reserves

The higher the sharing, the higher the technical requirements.

GitHub Org_Hejianhui /JavaStudy GitHub Hejianhui /JavaStudy