Database Interface Agent Tenant Upgrade Footprint
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing tenant-based upgrade systems face inefficiencies due to large deployment footprints, unnecessary updates, and increased memory and storage costs, as they often require updating unused software and persistence, leading to longer lifecycle times and wasted resources.
Innovation Solution
A database interface agent facilitates tenant-based upgrades by implementing a 'copy-on-access' and 'copy-on-write' strategy, materializing only used tables and objects, and minimizing upgrade activities to only what is necessary, while also 'garbage-collecting' unused materialized objects, thus optimizing the upgrade process and reducing the footprint.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a full deployment footprint is maintained for all tenants, then all tenants can access all software entities, but unused software and persistence consume excessive memory and storage resources
Solution Approach 1:
The patent implements local quality by allowing different tenants to have different sets of materialized entities based on their actual usage patterns. Each tenant's database instance contains only the subset of entities they access, rather than a universal full deployment footprint. This is achieved through tracking materialization flags and selectively copying entities from the deployment to individual tenant databases based on access patterns.
2Stability of the object's composition
If all entities are updated during upgrade, then deployment consistency is maintained, but lifecycle time increases due to unnecessary updates
Solution Approach 1:
The patent extracts the upgrade process to operate selectively on only those entities that are both part of the deployment and actually materialized in the tenant's database. The upgrade mechanism queries the materialization flags to identify the subset of entities requiring updates, rather than forcing a full deployment-wide update. This extraction of necessary upgrade operations reduces lifecycle time while maintaining consistency for actually used entities.
3Adaptability or versatility
If unused persistence is maintained in tenant databases, then schema flexibility is preserved, but storage costs increase unnecessarily
Solution Approach 1:
The patent implements discarding and recovering by implementing a garbage collection mechanism that identifies and removes materialized entities that are no longer referenced by the deployment. The system tracks which entities are materialized in tenant databases and periodically cleans up those that have been discarded from the deployment schema. This maintains schema flexibility for currently used entities while eliminating storage costs for obsolete persistence.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A system may include a shared storage data store containing a first version of entities with original content and a local tenant storage data store to contain information associated with a tenant's application server. A database interface agent may enter a copy-on-access mode and maintain materialization and modification flags. The agent may then initiate an upgrade process during which the first version of the entities are utilized by the application server. The agent may then enter a copy-on-write mode and delete, from the local tenant storage data store, entities having flags that indicate the table was migrated but did not receive customer data. The structure of the remaining entities may then be updated in view of the structure of the second version of the entities. Finally, the content of the entities may be updated in view of the content of the second version of entitles and previously received customer data.