【SaaS】Multi-tenant system design

Multi-tenant system design

1. SaaS system classification

The 5 Levels of the SaaS System Architecture Maturity Model - From "Chaos" to "Utopia"

• Level 0 (Chaos): Every time a customer is added, an instance of the software is added.

• Level 1 (Controlled Chaos): All clients are running the same version of the software, and any customization is done by modifying the configuration.

• Level 2 (multi-tenant, highrise): All clients are already running on the same version of the software, and they are all running on the same "instance".

• Level 3 (Multi-tenant, Build-Out): At this point you have a multi-tenant, single-version software model. But you can still expand it through hardware scale-out.

• Level 4 (Utopia): Like level 3, except you can figure out an efficient way to run different versions of the software on different "instances".

2. The application must support multi-tenancy

Multi-tenancy can be broken down into several different categories:

• Simple virtualization in the cloud where only the hardware is shared.

• Shared applications, using different databases for each tenant.

• Shared applications and databases (maximum efficiency, true multi-tenancy).

3. Data isolation scheme

What we want to achieve is the most efficient and true multi-tenant business model. But the selection is a screening process. The following introduces various multi-tenant data isolation solutions.

3.1. Independent application and independent library

There are several different applications, each with its own database. Although this method ensures the isolation of tenant data, it is the worst in terms of scalability and cost, so this method should be eliminated first.

3.2. The same application, one library per tenant

• The advantage is

  • Tenant data is physically isolated in database maintenance,

  • Since there is a library for each tenant, the design of the library table can be expanded independently, but this also causes compatibility issues for applications

• weakness is

  • The maintenance cost of the database is high, and the development cost (for example: in the case of the same data structure, adding columns or indexes in the table requires operating multiple libraries) is also high.

3.3, the same application, the same database

• shortcoming:

  • A multi-tenant database necessarily sacrifices tenant isolation. Data for multiple tenants is stored together in a single database. During development, ensure that queries do not expose data from multiple tenants.

• advantage:

  • It is the lowest cost of all programs.

3.4. Fragmentation multi-tenancy

Fragmented multi-tenancy means: multi-tenant single application + multi-tenant single database (sharding)

Does it look similar to the first picture: the same application, one library per tenant, except that each library has more tenant data?

It's actually very different.

First of all, in the first mode, the libraries of different tenants can be expanded separately, that is, the structure can be different, but the multi-tenant sharding is the same data structure.

Secondly, the sharding mode is highly scalable. It can be one tenant per shard, or multiple tenants per shard, depending on the specific sharding strategy.

Let’s take a look at the specific indicators in the sharding mode:

index	Shard multi-tenancy
scalability	Unlimited 1-1000000s
Tenant isolation	medium
Database cost per tenant	lowest
Performance Monitoring and Management	Comprehensive and individual (partially comprehensive)
development complexity	medium
Operation and maintenance complexity	From low to high, the management of single tenants is more complicated

4. Our Model Selection

Based on the above analysis, we choose to adopt the sharding multi-tenant model, because it can obtain unlimited scalability and isolate tenant data better.

In this way, the database structure is unified, and different shards have the same database table structure. The specific sub-database rules can be configured. It is recommended to configure according to the strategy of one tenant and one database in the early stage.

4.1. Development practice

• The design of each table should consider whether to add the "tenant ID" field to distinguish between different "tenants" or different customers. In addition, it is also convenient to use "rental ID" as the sharding key later

• We will introduce ShardingSphere to help us do the sub-database and sub-table of the database, which is relatively transparent to the application and reduces the complexity of application development at the database level due to the introduction of sub-database and sub-table.

• We use sharding rules to shard the data, for example, according to the tenant ID, configure the rules for sharding database and sharding

# 配置分片规则
- !SHARDING
  tables:
    # 配置 t_order 表规则
    t_order: 
      actualDataNodes: ds${
    
    0..1}.t_order${
    
    0..1}
      # 配置分库策略
      databaseStrategy:
        standard:
          shardingColumn: user_id
          shardingAlgorithmName: database_inline
      # 配置分表策略
      tableStrategy:
        standard:
          shardingColumn: order_id
          shardingAlgorithmName: table_inline
    t_order_item: 
    # 省略配置 t_order_item 表规则。..
    # ...
    
  # 配置分片算法
  shardingAlgorithms:
    database_inline:
      type: INLINE
      props:
        algorithm-expression: ds${
    
    user_id % 2}
    table_inline:
      type: INLINE
      props:
        algorithm-expression: t_order_${
    
    order_id % 2}

When the structure of the database table is changed (DDL), ShardingProxy is used to modify the proxy, and ShardingProxy will automatically modify the multi-database tables according to the rules of sub-database and sub-table.

4.2, metadata/configuration driver

A good SaaS solution should be efficient multi-tenancy. Multi-tenancy can be achieved using per-tenant metadata. Metadata can be defined for each specific component. It defines the application data at runtime, the underlying functionality of the application, and tenant-specific data and customizations (if any).

reference

• https://linpxing.cn/cxy_saas_tenant_db_11/

• http://www.uml.org.cn/yunjisuan/2021051944.asp?artid=23981