SSD Persistent Cache for Database Systems

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current database caching techniques rely on volatile RAM for performance improvement, which is costly and limited in capacity, and previous SSD-based solutions do not fully utilize SSD performance due to reliability concerns and inefficient data handling during system crashes or shutdowns.

Innovation Solution

Implementing solid state drives as a persistent second level cache, with a cache manager that handles data page requests, evictions, and checkpoint flushing to ensure data persistence and efficient access, allowing for quicker recovery and improved performance by utilizing SSDs' capacity and reliability advancements.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Speed

If volatile RAM is used for database caching to improve access speed, then data access speed is improved, but cost and capacity limitations worsen

Engineering Contradiction:
Improvedata access speedVSAvoidcache capacity
Core Design Contradiction:
SpeedVSQuantity of substance

Solution Approach 1:

The cache is segmented into multiple levels: volatile RAM cache for frequently accessed data and persistent SSD cache for less frequently accessed data. This segmentation allows the system to maintain high-speed access for hot data while using lower-cost storage for cold data, effectively resolving the contradiction between access speed and cache capacity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a new dimension of persistence to the cache hierarchy by using SSDs with battery backup or capacitive storage. This creates a three-tier structure (RAM, persistent SSD cache, disk storage) that adds the dimension of data persistence while maintaining speed advantages, allowing the system to overcome both capacity and cost limitations of volatile RAM.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

2Speed

If volatile RAM is used for database caching to improve access speed, then data access speed is improved, but cost worsens

Engineering Contradiction:
Improvedata access speedVSAvoidcost
Core Design Contradiction:
SpeedVSEase of manufacture

Solution Approach 1:

Different storage media are assigned to different data access patterns: volatile RAM is used locally for frequently accessed data requiring high speed, while persistent SSDs are used for less frequently accessed data. This local quality assignment optimizes the cost-performance ratio by matching storage characteristics to data access requirements.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements a copying mechanism where data is copied from disk storage to persistent SSD cache, and then to volatile RAM cache as needed. This copying strategy allows the system to use cheaper storage media for bulk storage while maintaining fast access paths for active data, reducing overall system cost while preserving speed performance.

Inventive Principle:
Principle #26Copying

3Quantity of substance

If SSDs are used as persistent cache to increase capacity and reduce cost, then cache capacity is improved, but data access speed worsens compared to RAM

Engineering Contradiction:
Improvecache capacityVSAvoiddata access speed
Core Design Contradiction:
Quantity of substanceVSSpeed

Solution Approach 1:

Volatile RAM acts as an intermediary between the persistent SSD cache and the database system. Data is transferred from SSD cache to RAM for active access, allowing the SSD to provide large capacity while RAM maintains high-speed access. This intermediary layer resolves the speed disadvantage of SSDs while preserving their capacity advantages.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system performs preliminary actions by pre-loading data from persistent SSD cache into volatile RAM cache before it is needed for database operations. This anticipatory loading ensures that data is already in high-speed memory when needed, eliminating the speed penalty of SSD access during actual database operations.

Inventive Principle:
Principle #10Preliminary action

4Ease of manufacture

If SSDs are used as persistent cache to reduce cost, then cost is reduced, but reliability concerns worsen

Engineering Contradiction:
ImprovecostVSAvoiddata persistence reliability
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The patent implements beforehand cushioning through battery backup or capacitive storage circuits that protect against power loss. These protective mechanisms are built into the persistent cache system to cushion against potential data loss events, ensuring reliability while maintaining the cost benefits of SSD technology.

Inventive Principle:
Principle #11Beforehand cushioning (Prior cushioning)

Solution Approach 2:

The system changes the reliability parameter of SSDs by introducing power protection mechanisms (battery or capacitor) that fundamentally alter the failure mode. This parameter change transforms SSDs from potentially unreliable persistent storage to reliable persistent cache, matching the reliability of volatile RAM while maintaining cost advantages.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS9442858B2Solid state drives as a persistent cache for database systems
Publication Date: 2016.09.13 IANYWHERE SOLUTIONS INC
  • US9442858B2 patent drawing
  • US9442858B2 patent drawing
  • US9442858B2 patent drawing

AI summary

Disclosed herein are systems, methods, and computer readable storage media for a database system using solid state drives as a second level cache. A database system includes random access memory configured to operate as a first level cache, solid state disk drives configured to operate as a persistent second level cache, and hard disk drives configured to operate as disk storage. The database system also includes a cache manager configured to receive a request for a data page and determine whether the data page is in cache or disk storage. If the data page is on disk, or in the second level cache, it is copied to the first level cache. If copying the data page results in an eviction, the evicted data page is copied to the second level cache. At checkpoint, dirty pages stored in the second level cache are flushed in place in the second level cache.