Transaction Ordering in Distributed Databases

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Distributed databases face challenges in maintaining Consistency and Isolation properties while ensuring fault tolerance and scalability, particularly in coordinating transactions across nodes to preserve causality.

Innovation Solution

The system implements transaction ordering techniques by associating time indications with read and transaction requests, detecting potential read anomalies, and reordering reads to ensure consistency, using a distributed database-optimized storage system that offloads durability and space management operations across multiple nodes, reducing network traffic and improving scalability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If distributed database systems coordinate transactions across nodes to preserve causality, then consistency and isolation properties are maintained, but system complexity and coordination overhead increase

Engineering Contradiction:
Improveconsistency and isolation propertiesVSAvoidcoordination overhead
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system assigns transaction order values to transactions before they are executed, establishing a predetermined ordering scheme. This preliminary assignment of order values allows nodes to independently determine transaction execution order without complex real-time coordination, reducing coordination overhead while maintaining consistency and isolation properties.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If distributed database systems use traditional concurrency control protocols, then transaction isolation is ensured, but performance and scalability deteriorate

Engineering Contradiction:
Improvetransaction isolationVSAvoidperformance and scalability
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system introduces transaction order values as a new parameter to traditional concurrency control protocols. By incorporating this additional parameter into the ordering and execution logic, the system achieves both strong isolation guarantees and improved scalability, as nodes can make independent ordering decisions based on these values without extensive inter-node communication.

Inventive Principle:
Principle #35Parameter changes

3Reliability

If distributed database systems replicate data across multiple nodes, then fault tolerance and durability are improved, but network traffic and synchronization costs increase

Engineering Contradiction:
Improvefault tolerance and durabilityVSAvoidnetwork traffic and synchronization costs
Core Design Contradiction:
ReliabilityVSLoss of energy

Solution Approach 1:

The system pre-assigns transaction order values to transactions before replication and execution across nodes. This preliminary ordering information allows replicated nodes to independently process transactions in the correct sequence without requiring extensive network communication for synchronization, thereby reducing network traffic and synchronization costs while maintaining fault tolerance and durability.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP2997490B1Transaction ordering
Publication Date: 2022.01.19 AMAZON TECH INC
  • EP2997490B1 patent drawingFigure 1
  • EP2997490B1 patent drawingFigure 2
  • EP2997490B1 patent drawingFigure 3

AI summary

Nodes of a database service may receive a read request to perform a read of a record stored by the database service and a transaction request to perform a transaction to the record. First and second indications of time may be associated with the read and transaction, respectively. A potential read anomaly (e.g., fuzzy read, read skew, etc.) may be detected based, at least in part, on a determination that the first indication of time is within a threshold value of the second indication of time. In response to detecting the potential read anomaly, the read may be performed after the transaction specified by the transaction request, regardless of whether the first indication of time is indicative of an earlier point in time than the second indication of time.