Key-Value Database Transaction Management for Distributed Consistency

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Implementing a scalable, transactional database architecture that is both distributed and efficient, particularly for handling large data sets, is challenging due to difficulties in managing data consistency and performance across multiple systems.

Innovation Solution

A database management system that employs a key-value database with a transactional layer, utilizing a microservice architecture and an enforcement application to manage transactions and enforce policies, ensuring ACID properties and optimizing memory usage through secondary storage for large data files.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If a distributed database architecture is implemented to achieve scalability, then the database can handle large data sets across multiple systems, but data consistency and transaction management become difficult to maintain

Engineering Contradiction:
ImprovescalabilityVSAvoiddata consistency
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent introduces a transaction manager as an intermediary component that sits between the distributed database systems and the clients. This transaction manager coordinates transactions across multiple database nodes, ensuring ACID properties are maintained while allowing the underlying distributed architecture to provide scalability. The transaction manager acts as a mediator that reconciles the needs of distributed storage with the requirements of consistent transaction processing.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The database system is segmented into independent distributed nodes that can operate autonomously while being coordinated by the transaction manager. Each node maintains its own data storage and can process local operations independently, enabling horizontal scalability. The segmentation allows the system to grow by adding more nodes without requiring a complete system redesign, while the transaction manager ensures consistency across these segmented components.

Inventive Principle:
Principle #1Segmentation

2Reliability

If transactional functionality is added to ensure ACID properties, then data integrity is improved, but system complexity and performance overhead increase

Engineering Contradiction:
Improvedata integrityVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The transaction manager serves as a specialized intermediary that handles all transactional complexity in a centralized manner. By concentrating transaction coordination logic in this single component, the patent isolates the complexity of implementing ACID properties in distributed systems. Individual database nodes can remain relatively simple, focusing on data storage and local operations, while the transaction manager handles the complex coordination required for distributed transactions.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent employs logging and checkpointing mechanisms that create copies of transaction states and data snapshots. These copies are used to implement recovery and consistency protocols without requiring complex real-time coordination for every operation. By maintaining redundant copies of critical information, the system can ensure data integrity through simpler replay and validation operations rather than complex continuous verification.

Inventive Principle:
Principle #26Copying

3Speed

If all data is stored in memory for fast access, then read performance is improved, but memory usage becomes excessive for large data sets

Engineering Contradiction:
Improveread performanceVSAvoidmemory usage
Core Design Contradiction:
SpeedVSQuantity of substance

Solution Approach 1:

The patent introduces a hierarchical storage architecture that adds a spatial dimension to data access by organizing data across multiple storage levels (memory and disk). Instead of forcing all data into a single memory space, the system creates a multi-layered storage hierarchy where frequently accessed data resides in memory while less frequently accessed data is stored on disk. This dimensional approach allows the system to handle large data sets without requiring proportional memory increases.

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

Solution Approach 2:

The system implements data preloading and caching mechanisms that anticipate future access patterns and load relevant data into memory in advance. By performing preliminary actions to populate memory with likely-needed data, the system maintains fast read performance for anticipated queries without requiring all possible data to be permanently resident in memory. This proactive approach allows efficient use of limited memory resources while preserving fast access performance.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP3617901B1Data storage method and system
Publication Date: 2022.09.14 PALANTIR TECHNOLOGIES INC
  • EP3617901B1 patent drawingFigure 1
  • EP3617901B1 patent drawingFigure 2
  • EP3617901B1 patent drawingFigure 3~4

AI summary

Example embodiments describe a data storage method and system. For example, the method described, performed by one or more processors, may comprise in an application for enforcing one or more policies for reading and writing data to a database receiving, over a data network, instructions for performing a read or write request for data, and sending the read or write request to a transaction manager for providing transactions for a key-value store of the database, the request being in accordance with one or more policies to be enforced by the enforcing application. The method may also comprise receiving, from the transaction manager, a response message based on operations performed by the transaction manager in response to the read or write request.