Versioned Database Scenario Selection for Shared Memory Reclamation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Database administrators face challenges in reducing the memory footprint by deleting scenarios in versioned databases due to data sharing between scenarios, leading to inefficient memory reclamation.
Innovation Solution
A method and system utilizing a version graph and scenario structure to determine the optimal combination of scenarios for deletion, generating a version visibility data structure (VVDS) to evaluate and execute the deletion of scenarios that reclaim memory efficiently.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If scenarios are deleted to reduce memory footprint, then memory reclamation is attempted, but data sharing between scenarios prevents effective memory reclamation
Solution Approach 1:
The patent segments the database into versions and scenarios, creating a hierarchical structure where versions contain data and scenarios reference versions. This segmentation allows tracking which scenarios reference which versions, enabling precise identification of deletable data. The version graph divides the database into discrete units (versions) that can be independently analyzed for reclamation opportunities.
Solution Approach 2:
Instead of directly deleting scenarios and hoping for memory reclamation, the patent inverts the approach by first identifying versions that are not referenced by any remaining scenarios, then deleting those orphaned versions. This reverse approach ensures that only unreferenced data is deleted, guaranteeing memory reclamation without affecting active scenarios.
2Quantity of substance
If all combinations of scenario deletions are evaluated to find optimal memory reclamation, then memory optimization is achieved, but computational complexity increases exponentially
Solution Approach 1:
The patent performs preliminary actions by building a version graph and populating version scenario lists before any deletion decisions are made. This pre-computation establishes the reference relationships between versions and scenarios, so that when deletion is needed, the system can quickly query the pre-built structures to identify orphaned versions without performing complex combinatorial analysis at deletion time.
Solution Approach 2:
The version graph serves as an intermediary data structure that mediates between scenarios and versions. Instead of directly analyzing complex scenario deletion combinations, the system uses the version graph as an intermediate representation that simplifies the problem to identifying versions with empty version scenario lists, thereby reducing computational complexity.
3Adaptability or versatility
If scenarios share data between multiple scenarios, then data reusability is improved, but memory footprint increases due to inability to free shared data
Solution Approach 1:
The patent implements a copying mechanism where scenarios reference versions through the version graph rather than directly sharing data structures. Each version is a distinct copy of data, and scenarios reference these versions through the version scenario lists. This copying approach allows multiple scenarios to access the same logical data while maintaining separate references, enabling independent deletion of unreferenced versions.
Solution Approach 2:
The system enables discarding of scenario references and automatic recovery (reclamation) of version data when no longer needed. When scenarios are deleted, the version graph automatically identifies versions that are no longer referenced by any scenarios and marks them for reclamation. This allows the system to discard scenario references and recover the underlying version data, optimizing memory usage while maintaining data sharing when active scenarios require it.
Data Source
AI summary
Systems and methods for replicating data in a versioned database, comprising: receiving a maximum replication size; selecting, a lead scenario for placement in a replication set; the lead scenario having a size less than the maximum replication size; marking all scenarios in the versioned database as unprocessed and the lead scenario as processed; initializing the replication set; adding the lead scenario into the replication set; obtaining a list of candidate scenarios to place in the replication set; determining a best candidate scenario from the list of candidate scenarios; adding the best candidate scenario to the replication set the best candidate scenario as processed; and iterating a new list of candidate scenarios to place in the replication set until there are no more scenario candidates to place in the replication set.