In-Memory Database Concurrency via Row Versioning

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Existing in-memory storage engines for database systems are not optimized for modern multi-processor computer systems, leading to bottlenecks due to the use of locks and latches, which limit concurrency and throughput.

Innovation Solution

An in-memory database system utilizing lock-free data structures, versioning of database table rows, a non-blocking multi-version concurrency control scheme, and a non-blocking cooperative garbage collection technique to execute transactions without blocking and thread switching, thereby avoiding bottlenecks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If locks and latches are used to protect shared data, then data consistency is maintained, but concurrency and throughput are limited

Engineering Contradiction:
Improvedata consistencyVSAvoidthroughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent segments data access into versioned rows with unique identifiers, allowing multiple transactions to operate on different versions simultaneously. Each row is divided into versioned copies that can be accessed independently, eliminating the need for global locks and enabling parallel processing across multiple CPU cores.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system dynamically creates and manages multiple versions of rows as transactions execute. Instead of using static locks that block access, the system dynamically generates versioned copies that can be read and written by different transactions concurrently, with newer versions automatically replacing older ones.

Inventive Principle:
Principle #15Dynamics

2Reliability

If locks and latches are used to protect shared data, then data consistency is maintained, but the level of concurrency is limited

Engineering Contradiction:
Improvedata consistencyVSAvoidconcurrency
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent segments data access into versioned rows with unique identifiers, allowing multiple transactions to operate on different versions simultaneously. Each row is divided into versioned copies that can be accessed independently, eliminating the need for global locks and enabling parallel processing across multiple CPU cores.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system creates copies of data rows as versions, allowing multiple transactions to read and write different versions concurrently. Each transaction works with its own version copy, and changes are propagated through version chains, enabling high concurrency without data consistency issues.

Inventive Principle:
Principle #26Copying

3Quantity of substance

If traditional storage engines paginate data in and out of memory, then disk storage is utilized, but memory efficiency is reduced

Engineering Contradiction:
Improvestorage capacityVSAvoidmemory access efficiency
Core Design Contradiction:
Quantity of substanceVSUse of energy by moving object

Solution Approach 1:

The patent loads entire tables into memory upfront and maintains them there, eliminating the need for paging operations. By pre-loading data and keeping it in memory, the system avoids the overhead of frequent disk-to-memory transfers, significantly improving memory access efficiency and reducing I/O operations.

Inventive Principle:
Principle #10Preliminary action

4Reliability

If transactions block and switch threads, then transaction isolation is maintained, but system overhead increases

Engineering Contradiction:
Improvetransaction isolationVSAvoidthread switching overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system dynamically creates and manages multiple versions of rows as transactions execute. Instead of using static locks that block access, the system dynamically generates versioned copies that can be read and written by different transactions concurrently, with newer versions automatically replacing older ones.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

Transactions execute continuously without blocking or thread switching. Multiple transactions can proceed simultaneously on different versions of the same data, and the system automatically manages version transitions. This eliminates interruptions and reduces overhead associated with context switching and lock acquisition.

Inventive Principle:
Principle #20Continuity of useful action

Data Source

PatentUS11048691B2In-memory database system
Publication Date: 2021.06.29 MICROSOFT TECHNOLOGY LICENSING LLC
  • US11048691B2 patent drawing
  • US11048691B2 patent drawing
  • US11048691B2 patent drawing

AI summary

An in-memory database system stores an entirety of a database within main memory of the computer system. The database includes a table comprising a plurality of rows including a particular row. A first transaction updating the particular row is executed to create a first version of the particular row. A second transaction updating the particular row is executed to create a second version of the particular row. The first version is visible only to the first transaction, and the second version is visible only to the second transaction. The in-memory database system may associate an index with the database table, the index referencing the plurality of rows, including referencing the first version of the particular row and the second version of the particular row. The in-memory database system may initiate garbage collection of the first version of the particular row and/or the second version of the particular row.