Research on Semi-Structured and Unstructured Data Storage and Management Model for Multi-Tenant

2. Related Work

At present, many domestic and foreign scholars have done a lot of research work on the SaaS multi-tenant data storage and management, and the representative research results are as follows.

Frederick Chong et al. (2006) as early as 2006 put forward three kinds of data sharing approaches which are the separate databases model, the shared database separate schemas model, and the shared database shared schemas model. The shared database shared schemas model can reflect that the SaaS application is based on the characteristics of sharing to achieve customization.

Waters (2006) and Aulbach et al. (2008) proposed a private table storage mode. The scheme allocates private table for each tenant and stores all the data for the tenant. This approach has good isolation and security, but if the number of tenants is too large, it will produce too much redundant data, resulting in low efficiency and waste of resources.

Greg Gianforte (2005) presented an Extension table storage mode. In this storage scheme, a large number of data were extracted, and then placed in a shared base table, while the tenant's own custom data stored in an extension of the table, the two table are connected through the tenant key (Tenant ID) to connect. This scheme can effectively reduce data redundancy, and save more space. But due to the use of the extended table, when we need to implement the operation involving customized data, it is bound to be a multi table joint, this will lead to low efficiency.

The storage method of Universal table proposed by Craig D Weissman (2009) is a data sharing storage structure based on the metadata-driven, the core thought is to place all the tenants' data in a large universal table for shared storage. Because we need to store data for all tenants, so the number of columns of universal table should be greater than the number of columns of the tenant with the largest number of attributes. The parts of the custom differences between tenants are set to null values, namely, the field which is not required for the tenant is set to null. The custom operation in this scheme does not require multiple tables, but because the number of table columns cannot be predicted, the space left out will lead to the waste of storage space, and be detrimental to the extendibility.