Streaming Data Storage Event Ordering via Position Indexing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Contemporary data storage systems like PRAVEGA struggle to provide data consumption in a user-defined order, as they guarantee ordering within a stream based on ingestion order, which may not align with the desired consumption order for readers.
Innovation Solution
Introducing an ordered segment that includes a position value with each event, allowing events to be read in a user-specified order by incorporating an index segment and tail index for efficient reordering and batch updates, enabling events to be read in position order regardless of ingestion order.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If events are stored in ingestion order in stream segments, then ordering within the stream is guaranteed, but events cannot be consumed in user-defined order
Solution Approach 1:
The system divides stream data into two separate segments: an event segment that stores events in ingestion order (maintaining reliability), and an index segment that stores position information enabling user-defined order consumption (providing adaptability). This segmentation allows both ordering guarantees and flexible consumption patterns to coexist without interfering with each other.
Solution Approach 2:
The patent introduces an intermediary indexing mechanism that maps user-specified positions to actual event locations in the stream. This intermediary layer (the index segment with tail index) translates user consumption requests into efficient data retrieval operations, enabling flexible ordering without disrupting the immutable ingestion-order storage structure.
2Adaptability or versatility
If events are reordered to match user-defined consumption order, then flexibility is improved, but system complexity increases
Solution Approach 1:
By separating event storage from indexing functionality into distinct segments, the system adds flexibility without complicating the core event storage mechanism. The event segment remains simple and immutable, while the index segment handles all reordering logic, keeping complexity isolated and manageable.
Solution Approach 2:
The system performs preliminary indexing actions by maintaining a tail index that pre-computes position mappings. This preliminary action prepares the data structure in advance, so when users request events in custom order, the reordering can be executed efficiently using pre-established index information rather than complex real-time reordering logic.
3Adaptability or versatility
If an index structure is added to enable position-based ordering, then user-defined consumption is enabled, but write performance may deteriorate
Solution Approach 1:
The tail index structure performs preliminary indexing operations during the write process, computing and storing position mappings as events are ingested. This preliminary action ensures that the index is ready in advance, avoiding expensive post-write reordering operations and minimizing the performance impact of maintaining indexing structures.
Solution Approach 2:
The system maintains a copy of position information in the tail index without duplicating the actual event data. This lightweight copying approach enables efficient position-based queries and reordering while keeping the overhead of index maintenance minimal, as only metadata (position mappings) is stored and updated rather than full event copies.
Data Source
AI summary
The described technology is generally directed towards a streaming data storage system that maintains streamed events, including in a manner that facilitates the ordering of those events based on external ordering (position) data. An event is appended to an event segment, and an index segment maintains offset information to the event relative to the offsets of other previously appended events. The index segment is ordered by position data provided with the event, such that the events (e.g., for a given event routing key) can be read back in position order instead of append order. An ongoing read that returns an event (that matches ongoing read criteria) as the event arrives can also be handled. Also described is the use of a tail index and an indexing queue for more efficient handling of events prior to writing the offset information into the index segment.


