Stream Operator Time Metadata for Real-Time Tuple Processing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Database systems are not well-suited for real-time processing and analysis of large amounts of streaming data, often failing to store, index, and analyze such data efficiently or in real-time, which is critical for applications like financial arbitrage that require sub-millisecond analysis.

Innovation Solution

A method and system for processing tuples in a stream-based computing application that involves adding time metadata, determining time metrics, and ending processing if these metrics are outside a dynamic time limit, allowing for efficient handling of time-sensitive data streams by transmitting tuples within a defined time zone or limit, and dynamically adjusting these limits based on monitoring data.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If database systems store and index data in memory before querying, then data can be accessed and manipulated, but real-time processing of large amounts of streaming data becomes inefficient

Engineering Contradiction:
Improvedata analysis accuracyVSAvoidprocessing time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The system performs preliminary actions by adding time metadata to tuples at the source and pre-establishing time limits before processing begins. This allows downstream operators to make quick time-based decisions without waiting for complete data processing, resolving the contradiction between accurate analysis and processing speed.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The invention extracts the time-based filtering function from the traditional database indexing process. Instead of storing all data and then filtering, the system extracts and processes only tuples that meet time criteria in real-time as they stream through the operator graph, eliminating the time delay inherent in batch processing.

Inventive Principle:
Principle #2Taking out (Extraction)

2Reliability

If the system processes all incoming tuples completely, then data analysis is thorough, but processing speed decreases due to time-consuming operations

Engineering Contradiction:
Improveanalysis completenessVSAvoidprocessing throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system applies partial action by processing only the necessary portion of each tuple up to the time limit threshold. If a tuple cannot be fully processed within the time limit, the system stops processing at the appropriate cutoff point rather than completing all operations, thereby maintaining throughput while ensuring timely decisions.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system implements feedback mechanisms where time metadata and time limits provide continuous feedback to processing operators. This feedback allows dynamic adjustment of processing depth based on remaining time, ensuring that processing stops automatically when time limits are approached, balancing completeness and speed.

Inventive Principle:
Principle #23Feedback

3Speed

If fixed time limits are used for processing tuples, then processing speed is maintained, but adaptability to varying data conditions is reduced

Engineering Contradiction:
Improveprocessing speedVSAvoidtime limit flexibility
Core Design Contradiction:
SpeedVSAdaptability or versatility

Solution Approach 1:

The system transitions from fixed to dynamic time limits by allowing the time limit parameter to be adjusted based on monitoring data and varying conditions. The time limit becomes a dynamic parameter that can adapt to different data streams and processing requirements while maintaining the core speed benefit of time-based filtering.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The invention changes the parameter of time limits from static to dynamic values. By allowing time limits to be modified based on monitoring data and system conditions, the system maintains processing speed through time-based constraints while gaining the adaptability needed for varying data conditions.

Inventive Principle:
Principle #35Parameter changes

4Loss of information

If the system processes tuples beyond time limits, then data freshness is maintained, but stale analysis slows down processing

Engineering Contradiction:
Improvedata freshnessVSAvoidprocessing efficiency
Core Design Contradiction:
Loss of informationVSProductivity

Solution Approach 1:

The system extracts and removes tuples that exceed time limits from further processing. By taking out stale tuples that cannot be processed within acceptable time frames, the system prevents them from slowing down processing while maintaining data freshness for tuples that can be processed timely.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system applies the skipping principle by rushing through processing of tuples that can be completed within time limits while skipping or discarding those that would exceed the time limit. This selective processing maintains data freshness for valid tuples while preventing stale analysis from reducing overall processing efficiency.

Inventive Principle:
Principle #21Skipping (Rushing through)

Data Source

PatentUS9426194B2Ending tuple processing in a stream-based computing application
Publication Date: 2016.08.23 INTERNATIONAL BUSINESS MACHINE CORPORATION
  • US9426194B2 patent drawing
  • US9426194B2 patent drawing
  • US9426194B2 patent drawing

AI summary

A method includes receiving streaming data to be processed by a plurality of processing elements comprising one or more stream operators. Time metadata may be added to a parent tuple at a first stream operator. A first time metric may be determined for a first child tuple of the parent tuple at a second stream operator. The first time metric may be determined, at least in part, from the time metadata. The second stream operator may receive the first child tuple from the first stream operator. The method may include transmitting a second child tuple of the parent tuple from the second stream operator to a third stream operator if the time metric is inside a time limit. In addition, the method may include ending processing of the first child tuple if the time metric is outside of the time limit.