Graph Database Online Offline Architecture Scalability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional graph databases are not scalable to support vast numbers of vertices and edges, fail to retrieve data in real-time efficiently, and are not stable for real-time production use.

Innovation Solution

A graph database system with online and offline components, where the online component handles real-time data storage and retrieval using a real-time graph database, and the offline component updates and recovers data using graph logs, generates snapshots, and tests graph schemas, ensuring data integrity and scalability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If conventional graph databases use key-value data sets to model use cases, then data storage is simplified, but scalability to support vast numbers of vertices and edges is limited

Engineering Contradiction:
Improvenumber of vertices and edgesVSAvoidsystem architecture complexity
Core Design Contradiction:
Quantity of substanceVSDevice complexity

Solution Approach 1:

The system is divided into distinct modules including a storage engine with separate components for vertices and edges, a query engine, and a metadata layer. This segmentation allows each component to handle specific aspects of graph data independently, enabling the system to scale to trillions of vertices and edges while maintaining manageable complexity through modular architecture.

Inventive Principle:
Principle #1Segmentation

2Quantity of substance

If conventional graph databases store large quantities of graph data, then data capacity increases, but real-time data retrieval efficiency decreases

Engineering Contradiction:
Improvequantity of graph dataVSAvoiddata retrieval speed
Core Design Contradiction:
Quantity of substanceVSSpeed

Solution Approach 1:

The system pre-computes and stores metadata about graph structures, including vertex and edge properties, relationships, and access patterns. This preliminary organization of data allows the query engine to quickly locate and retrieve relevant information without scanning entire datasets, maintaining high retrieval speeds even as data quantity grows to trillions of elements.

Inventive Principle:
Principle #10Preliminary action

3Productivity

If conventional graph databases are designed for real-time operations, then query performance improves, but stability and reliability for production use deteriorate

Engineering Contradiction:
Improvereal-time query performanceVSAvoidsystem stability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system implements multiple layers of error handling, data validation, and recovery mechanisms before failures can occur. Checksum verification, transaction logging, and automatic recovery procedures are built into the architecture to cushion against potential failures, ensuring both real-time performance and production-grade reliability simultaneously.

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

Data Source

PatentUS11442920B2Graph database system
Publication Date: 2022.09.13 PAYPAL INC
  • US11442920B2 patent drawing
  • US11442920B2 patent drawing
  • US11442920B2 patent drawing

AI summary

Systems and methods that describe a graph database system with an online component and an offline component, are provided. Write events that modify a first graph in a real-time graph database included in the online component are received. Graph logs that include changes to the first graph in the real-time graph database caused by the write events are generated. The graph logs are transmitted to an offline component of the graph database system in a chronological order. A second graph in the offline component is modified using the graph logs. The first graph and the second graph are instantiated using a graph schema.