Change Data Capture System for Distributed Databases

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Traditional data replication systems face challenges in handling large data sets, particularly in big data environments, due to issues with availability, scalability, and fault-tolerance, and struggle with latency when moving data between different database environments.

Innovation Solution

A system and method for capturing change data from a distributed data source system, supporting features like distributed source topology-awareness, initial load, deduplication, and recovery, which enables incremental change capture, automatic deduplication, and seamless node management across multiple nodes, ensuring data integrity and availability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional data replication systems are used to handle large data sets in big data environments, then data can be replicated between databases, but the systems face challenges with availability, scalability, and fault-tolerance

Engineering Contradiction:
ImproveavailabilityVSAvoidscalability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system segments the distributed data source into multiple nodes, each maintaining its own state and data. The replication system processes changes from individual nodes independently, allowing the system to scale by simply adding more nodes without requiring complex reconfiguration of the entire system.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The replication system is designed to work with heterogeneous database targets and support multiple distributed data source types (Apache Cassandra, Kafka, MongoDB, Oracle NoSQL, Google Bigtable) through a unified interface, making it universally applicable across different big data environments while maintaining consistent replication behavior.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Reliability

If data is replicated from distributed data sources to ensure availability and fault-tolerance, then data redundancy is improved, but handling dynamic topology changes and node failures increases system complexity

Engineering Contradiction:
Improvefault-toleranceVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The replication system automatically detects node failures and topology changes in the distributed data source, dynamically adjusts its replication strategy, and recovers from failures without requiring manual intervention. The system self-manages the complexity of handling dynamic topology changes while maintaining fault-tolerance.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system continuously monitors the state of distributed data source nodes and uses this feedback to dynamically adjust replication operations. When nodes are added or removed, the system receives feedback about topology changes and automatically reconfigures replication to maintain data integrity and fault-tolerance.

Inventive Principle:
Principle #23Feedback

3Loss of information

If change data is captured from multiple nodes in a distributed system, then data completeness is improved, but duplicate data may be replicated to targets

Engineering Contradiction:
Improvedata completenessVSAvoiddata duplication
Core Design Contradiction:
Loss of informationVSLoss of substance

Solution Approach 1:

The system introduces an intermediary deduplication layer between the distributed data source nodes and the target database. This intermediary component receives change data from multiple nodes, identifies and eliminates duplicates using various strategies (exact match, fuzzy match, or based on primary key), and forwards only unique changes to the target, ensuring data completeness without duplication.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Reliability

If the replication system processes changes from all distributed data source nodes, then data synchronization is improved, but latency increases when moving data between different database environments

Engineering Contradiction:
Improvedata synchronizationVSAvoidlatency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system implements selective replication where changes are processed and replicated based on configuration and priority. High-priority changes are replicated immediately, while lower-priority changes may be batched or delayed. This partial action approach maintains data synchronization for critical data while reducing overall latency by not processing every single change with the same urgency.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentEP3676725B1System and method for capture of change data from distributed data sources, for use with heterogeneous targets
Publication Date: 2024.08.07 ORACLE INT CORP
  • EP3676725B1 patent drawingFigure 1
  • EP3676725B1 patent drawingFigure 2
  • EP3676725B1 patent drawingFigure 3

AI summary

In accordance with an embodiment, described herein is a system and method for capture of change data from a distributed data source system, for example a distributed database or a distributed data stream, and preparation of a canonical format output, for use with one or more heterogeneous targets, for example a database or message queue. The change data capture system can include support for features such as distributed source topology-awareness, initial load, deduplication, and recovery. A technical purpose of the systems and methods described herein includes determination and communication of changes performed to data at a distributed data source that includes a large amount of data across a plurality of nodes, to one or more target computer systems.