Key-Value Store Epoch Counter Hybrid Log

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing key-value store systems struggle to efficiently manage large amounts of state data that exceed main memory capacity, particularly in update-intensive and real-time applications, due to underutilization of resources and complex recovery mechanisms.

Innovation Solution

A key-value store system utilizing a shared atomic epoch counter and thread epoch counters, combined with a hybrid log that spans main memory and secondary storage, enabling fast in-place updates and lazy propagation of changes, while supporting advanced update types like read-modify-writes and blind updates through dynamic code generation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If a key-value store system stores large amounts of state data beyond main memory capacity, then the system can support larger data volumes, but access speed and throughput deteriorate due to slower secondary storage access

Engineering Contradiction:
Improvedata volumeVSAvoidaccess speed
Core Design Contradiction:
Quantity of substanceVSSpeed

Solution Approach 1:

The system segments state data into hot data (frequently accessed) and cold data (infrequently accessed). Hot data is stored in main memory for fast access, while cold data is stored in secondary storage. This segmentation allows the system to support large data volumes while maintaining high access speeds for the most frequently accessed data.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system applies different storage quality characteristics to different portions of data based on access patterns. Frequently accessed data receives premium main memory storage with fast access characteristics, while infrequently accessed data is placed in secondary storage with slower but cheaper access characteristics. This local quality differentiation resolves the contradiction between data volume and access speed.

Inventive Principle:
Principle #3Local quality

2Reliability

If the system implements complex recovery mechanisms to ensure data durability, then data reliability improves, but system complexity and overhead increase

Engineering Contradiction:
Improvedata durabilityVSAvoidrecovery mechanism complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs preliminary actions by writing data to the log structure before committing transactions. The log structure pre-establishes a recovery path by recording all state changes in a durable format. This preliminary action ensures that if a failure occurs, recovery can proceed systematically without complex real-time decision-making, reducing both complexity and overhead.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system creates copies of data in a log structure that serves as a recovery copy. This copy mechanism allows the system to maintain data durability through simple log replay during recovery, rather than implementing complex distributed recovery protocols. The copying approach simplifies the recovery mechanism while ensuring data reliability.

Inventive Principle:
Principle #26Copying

3Adaptability or versatility

If the system uses fine-grained statistics and metadata to manage changing hot sets, then adaptability improves, but memory overhead and system complexity increase

Engineering Contradiction:
Improvehot set adaptationVSAvoidmetadata overhead
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system implements self-service adaptability through the log structure that automatically tracks and manages hot sets based on access patterns. Rather than requiring external fine-grained statistics collection and management, the log structure inherently provides this information through its sequential write pattern and timestamp mechanisms. This self-service approach enables hot set adaptation without additional metadata overhead or system complexity.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS11663187B2Key-value store system
Publication Date: 2023.05.30 MICROSOFT TECHNOLOGY LICENSING LLC
  • US11663187B2 patent drawing
  • US11663187B2 patent drawing
  • US11663187B2 patent drawing

AI summary

A system includes a processor and a memory storing multiple records in a key-value data structure and processor executable instructions for managing access to records in the key-value data structure. The instructions are executable to perform operations including managing a shared atomic epoch counter and thread epoch counters, determining a maximal safe epoch as a function of the shared atomic epoch counter and the thread epoch counters, maintaining a drain list of trigger actions, and triggering the trigger actions in the drain list as a function of an update of the shared atomic epoch counter and the maximal safe epoch.