Database Version Deployment With Dual Runtime Buffers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional database version updates require significant downtime and resource consumption due to table cloning, which hinders Continuous Improvement/Continuous Development (CI/CD) approaches and increases costs.
Innovation Solution
Implementing two work process-specific application server runtime buffers, one for the current and one for the target database version, allowing simultaneous access and gradual user migration to the target version without cloning tables, thus minimizing downtime and resource overhead.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If table cloning is used to update database version, then database can be updated while running, but deployment time increases significantly
Solution Approach 1:
The patent segments the database update process into two independent paths: a current database version handling existing user requests and a target database version receiving new requests. This segmentation allows the target version to be updated without blocking the current version, enabling continuous operation while reducing the effective deployment time perceived by users.
Solution Approach 2:
The patent implements preliminary action by pre-creating and pre-filling the target database version with new application content before switching users. The target version is prepared in advance with all necessary table structures, data, and configurations, so when users switch, they immediately access the updated version without waiting for real-time cloning during their interaction.
2Productivity
If table cloning is performed, then database updates can proceed, but memory and hardware resources are doubled
Solution Approach 1:
The patent applies local quality by maintaining different database versions (current and target) with distinct characteristics - the current version handles active user workloads while the target version stores new content. This allows selective resource allocation where only the necessary portions of the database are replicated, rather than cloning the entire database structure, thereby reducing overall memory and hardware requirements.
3Reliability
If full table cloning is used, then database version can be updated, but deployment frequency is limited
Solution Approach 1:
The patent implements dynamics by enabling the database system to dynamically switch between current and target versions based on user requests. The system can dynamically create, update, and switch database versions without requiring full table cloning, allowing frequent deployments while maintaining version consistency. This dynamic approach enables continuous integration and deployment pipelines to operate at higher frequencies.
Data Source
AI summary
Systems and methods include determination of a plurality of artifacts of a first data schema and a first view schema of a first database version to be updated in a second database version, determination of target structures of a plurality of runtime objects for the second database version based on the artifacts, and loading of current structures of the runtime objects into a runtime buffer of a first work process connected to the first view schema. While the first work process serves first incoming requests using the runtime buffer and the first view schema, the runtime objects are updated to the determined target structures in the first data schema and in a second view schema of the second database version, a second work process is connected to the second view schema, and the second work process serves second incoming requests, the second view schema and the updated first data schema.