Study On Multi-Tenant Data Storage And Data Migration On Basic-Table Combined With Extension-Table Schema

In2006, Microsoft proposed a novel schema based on Basic-Table combined with Extension-Table to support Multi-tenants’ data storage. Tenants’ common fields are stored into Basic-Table, while the extension fields are stored into the Extension-Table. We can access the data in Basic-Table by usual method with high efficiency. But to the data in Extension-Table, tuple reconstruction will be involved and the processing efficiency is low. In tenants’actual business, if they access the extension data frequently but seldom access the Basic-Table, the advantage of the Basic-Table disappears. We wish we can store some of the tenants’extension fields which are accessed frequently into the Basic-Table. Then we can access these data without tuple reconstruction and the efficiency will be higher. However, the schema of Basic-Table is defined by the SaaS provider in the development stage and it’s hard to store tenants’variety extension fields into Basic-Table. In this article, we improve the Basic-Table combined with Extension-Table data storage architecture to store some tenants’extension data into the Basic-Table.With the development of cloud computing, Multi-Tenant data will to be stored on multiple data nodes instead of single data node. A tenant’s data may be sliced into multiple data nodes which share the same metadata. When a tenant’s data storage schema evolution happens, all the data nodes which contain the tenant’s copies need to do data migration simultaneously and every data node has to maintain two schemas:the original schema (OGS) and target schema (TGS). However, the load state of each data node is different, if we start data migration on a data node which is in heavy load situation and this will expand the additional workload. Worse still, tenants may perceive that the response time becomes slow, and this should be avoided. On the other hand, all the data replicas share the same metadata, only until all the data node complete data migration, can we change the metadata and start to use the target schema. So even some data nodes have finished, they still need to maintian two schemas and wait for other nodes. We should avoid the expanded additional workload which generates by simultaneous data migration and the worthless workload during waiting. In this article, we propose the Multi-Version metadata technology for data migration in multiple data nodes.The main work and achievements of the paper include:(1) Improve the Basic-Table combined with Extension-Table data storage architecture to store some tenants’ extension data into the Basic-Table. We create the Basic-Table with some reserved fields which are used to store tenants’extension data. We build statistical model and evaluation function for every tenant’s extension data to identify the high-frequency accessed extension data and selecte which extension data can be migrated into the basic-table. Based on the improved schema we proposed a dynamic data migration algorithm which implements the data sustainable accessibility by maintainting OGS and TGS two schemas and achieves the data consistency by compensation strategy for update operation.(2) Proposed the Multi-Version metadata technology based on the novel Basic-Table combined with Extension-Table for data migration in multiple data nodes. Designed and implemented the cloud multi-tenant data storage architecture and access process for Multi-Version metadata technology. The migration can be done on each data node by its load state separately and minimize the cost and negative impact during the synchronized data migration. In the end, we designed the novel data engine to support the realization of multi-version metadata technology.