Transaction Object Storage for Reduced Write Overhead

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional mechanisms for implementing transactions in object storage systems require data to be written multiple times, leading to significant processing overhead, with no intermediate states permitted, resulting in inefficiencies.

Innovation Solution

A method using transaction objects, where each transaction requires data to be written only once to persistent storage, utilizing table of contents entries and metadata fragments to manage transactions, allowing a single copy of data to represent all intermediate states and post-commit states.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional mechanisms are used to implement transactions in object storage systems, then data integrity and consistency are maintained, but processing overhead increases significantly due to multiple write operations

Engineering Contradiction:
Improvedata consistencyVSAvoidprocessing overhead
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments the transaction implementation into distinct components: transaction objects that group multiple data items, table of contents entries that index these objects, and metadata fragments that store transaction state. This segmentation allows the system to manage transactions efficiently by operating on grouped data rather than individual items, reducing the number of write operations needed while maintaining consistency through structured organization.

Inventive Principle:
Principle #1Segmentation

2Reliability

If data is written multiple times to commit a transaction, then atomicity is ensured, but processing overhead and write amplification increase

Engineering Contradiction:
Improvetransaction atomicityVSAvoidwrite amplification
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The patent applies preliminary action by pre-organizing data into transaction objects and pre-creating table of contents entries before the actual commit operation. This preparation allows the system to perform a single write operation during commit rather than multiple writes, as the structural framework is already in place. The metadata fragments are also prepared in advance to track transaction state, enabling atomic commitment with minimal additional writes.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If traditional transaction mechanisms are implemented, then data consistency is maintained, but the complexity of the transaction management system increases

Engineering Contradiction:
Improvedata consistencyVSAvoidtransaction management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent creates universal structures that serve multiple functions: transaction objects serve as both the container for data items and the unit of commit operation; table of contents entries simultaneously provide indexing and transaction state tracking; metadata fragments store both structural information and consistency markers. This multi-functionality reduces the need for separate specialized components, simplifying the overall transaction management system while maintaining consistency guarantees.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentEP2972744B1Object-based transactions in a storage system
Publication Date: 2019.08.14 EMC IP HLDG CO LLC
  • EP2972744B1 patent drawingFigure 1
  • EP2972744B1 patent drawingFigure 2A~2D
  • EP2972744B1 patent drawingFigure 2E

AI summary

A method including creating a transaction object for a transaction identified by a TOI and associated with an object identified by an OID, storing a TE and a MD frag for the transaction object, receiving a write request to write data to the transaction object, storing second TE including a TOI and offset and a data frag including the data, storing an entry including a hash value and a physical address of the data frag, and receiving a commit request to commit the transaction. In response to the commit request storing a third TE and a second MD frag for the transaction object, where the second MD frag identifies the object and specifies that the transaction is committed and updating a second entry including a second hash value and a second physical address for a second data frag to replace the second physical address with the physical address.