Distributed Data Synchronization via Segmented Replicas

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In systems where data is constantly updated and accessed simultaneously, using locks to serialize reading and writing becomes inefficient due to high volumes of read and write requests, leading to potential data inconsistencies and bottlenecks.

Innovation Solution

Implementing a distributed computing environment where data is stored across multiple locations, with each location maintaining a local version that is periodically updated from a centralized version, reducing competition for data and allowing for efficient handling of requests while tolerating data variation and delay.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If locks are used to serialize reading and writing of data, then data consistency is maintained, but system efficiency and throughput deteriorate due to high volumes of concurrent read and write requests

Engineering Contradiction:
Improvedata consistencyVSAvoidsystem efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent divides the centralized data into multiple distributed replicas stored across different locations. Each replica can be independently accessed and updated, eliminating the need for a single lock to protect the entire dataset. This segmentation allows concurrent operations on different replicas without conflicts, significantly improving system throughput while maintaining data consistency through periodic synchronization.

Inventive Principle:
Principle #1Segmentation

2Reliability

If a single lock protects constantly updated and accessed data, then data access safety is ensured, but bottlenecks occur due to the volume of read and write requests

Engineering Contradiction:
Improvedata access safetyVSAvoidwait time for lock release
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent creates multiple copies (replicas) of the data stored in different locations within the distributed system. These copies allow concurrent read and write operations to proceed in parallel without requiring a single lock. The copying mechanism eliminates the bottleneck of lock acquisition and release, reducing wait time while maintaining data safety through version control and synchronization protocols.

Inventive Principle:
Principle #26Copying

3Reliability

If data is stored in a single centralized location with lock protection, then data consistency is maintained, but scalability deteriorates when handling large volumes of concurrent requests

Engineering Contradiction:
Improvedata consistencyVSAvoidsystem scalability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent transitions from a single-dimensional centralized storage model to a multi-dimensional distributed storage architecture. Data is replicated across multiple nodes and locations, adding spatial distribution as a new dimension. This dimensional change enables the system to handle concurrent requests in parallel, significantly improving scalability while maintaining consistency through synchronization mechanisms that operate across the distributed dimensions.

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

Data Source

PatentUS8868525B2Distributed information synchronization
Publication Date: 2014.10.21 META PLATFORMS INC
  • US8868525B2 patent drawing
  • US8868525B2 patent drawing
  • US8868525B2 patent drawing

AI summary

Processing a prepared update is disclosed. A prepared update associated with a request that has been used by the sender to update a local version of a data associated with the sender is received from a sender. Based at least in part on an identifier included in the prepared update, a selected data handler is selected among a plurality of data handlers. The selected data handler is used to update a centralized version of the data at least in part by using the received prepared update. The centralized version of the data has been previously updated using a plurality of prepared updates received from a plurality of senders. The updated centralized version of the data is sent to update the local version of the data associated with the sender.