Hypercube Version Merging With Snapshot Chains and MVCC

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing query evaluation systems face challenges in efficiently managing large and complex hypercubes, particularly in maintaining data consistency and scalability when dealing with changing data over time, leading to resource-intensive cloning operations and scalability bottlenecks.

Innovation Solution

Implementing a multiversion concurrency control system that uses snapshot chains and anchor objects to manage hypercube versions efficiently, allowing localized storage and reduced memory overhead by referencing base and scenario versions without full duplication.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If full copies of hypercube data are stored to maintain data consistency during long-running processes, then data consistency is improved, but memory resource consumption increases substantially

Engineering Contradiction:

Improvedata consistencyVSAvoidmemory resource consumption

Core Design Contradiction:

ReliabilityVSQuantity of substance

Solution Approach 1:

The patent segments the hypercube data into multiple versions (base version and scenario versions) and stores them separately in the data store. Instead of loading entire hypercube copies into memory, only necessary portions are loaded, reducing memory consumption while maintaining data consistency through versioned storage.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The system performs preliminary actions by creating and storing multiple versions of the hypercube in the data store before they are needed. Version information is pre-computed and stored, allowing efficient retrieval and consistency maintenance without substantial memory resource consumption during runtime.

Inventive Principle:

Principle #10Preliminary action

2Productivity

If multiple versions of hypercubes are loaded simultaneously into memory, then version management efficiency is improved, but memory resource constraints are worsened

Engineering Contradiction:

Improveversion management efficiencyVSAvoidmemory resource constraints

Core Design Contradiction:

ProductivityVSQuantity of substance

Solution Approach 1:

The patent moves version management from the memory dimension to the storage dimension by implementing versioned storage in the data store. Multiple hypercube versions are stored externally with version information, allowing efficient version management through metadata tracking rather than loading all versions into memory simultaneously.

Inventive Principle:

Principle #17Another dimension (Dimensionality change)

Solution Approach 2:

Instead of copying entire hypercube versions into memory, the system creates lightweight version references and loads only necessary data portions. Full copies are stored in the data store, and memory contains only the essential working copies, reducing memory resource constraints while maintaining version management efficiency.

Inventive Principle:

Principle #26Copying

3Quantity of substance

If localized storage of hypercube versions is implemented, then storage overhead is reduced, but system complexity increases

Engineering Contradiction:

Improvestorage overheadVSAvoidsystem complexity

Core Design Contradiction:

Quantity of substanceVSDevice complexity

Solution Approach 1:

The patent segments hypercube data into localized versioned storage units in the data store, with each version stored separately. This segmentation reduces storage overhead by avoiding redundant data duplication while managing complexity through structured version information and organized storage segments.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS12632430B2What if scenario planning—merging a scenario

Publication Date: 2026.05.19 WORKDAY INC

AI summary

A system, method, and device for storing a scenario version as a base version for a hypercube are provided. The method includes (i) obtaining a request to store a scenario version of a hypercube as a base version; (ii) obtaining a set of transactions corresponding to hypercube updates for the scenario version, and (iii) writing the set of transactions to the base version.