Distributed Join Skew Handling via Heavy Hitter Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Clustered database management systems face performance issues due to data skew during join operations, where heavy hitter join key values lead to imbalance in data distribution across nodes, causing delays in distributed join operations.
Innovation Solution
Implementing run-time detection of heavy hitters in join operations, where the system identifies and broadcasts primary key heavy hitter tuples across nodes, allowing local processing on each node without overloading any single node, thus maintaining balanced load and performance across the cluster.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If database objects are distributed across cluster nodes for parallel processing, then processing speed is improved, but uneven distribution causes node overload and performance degradation
Solution Approach 1:
The system performs preliminary detection of heavy hitter join key values before executing the distributed join operation. By identifying which join keys will cause imbalance in advance, the system can pre-distribute these values across multiple nodes using broadcast, ensuring balanced load distribution before the actual join processing begins.
Solution Approach 2:
The system introduces an intermediary mechanism (the coordinator node and heavy hitter detection logic) that mediates between the data distribution requirement and the load balance requirement. This intermediary identifies heavy hitters and orchestrates their special distribution strategy, allowing the system to maintain both high productivity and good load balance.
2Device complexity
If heavy hitter join key values are concentrated on single nodes for simplified processing, then processing logic is simplified, but node overload causes delays in distributed join operations
Solution Approach 1:
The system segments the handling of join key values into two categories: heavy hitter values and non-heavy hitter values. Heavy hitters are distributed using broadcast to multiple nodes, while non-heavy hitters use traditional hash-based distribution. This segmentation allows the system to handle each type appropriately, preventing overload while maintaining processing efficiency.
Solution Approach 2:
The system changes the distribution parameter for heavy hitter join key values from hash-based routing to broadcast distribution. This parameter change ensures that heavy hitter values are replicated across multiple nodes rather than concentrated on a single node, preventing overload and reducing join operation delays.
3Ease of operation
If run-time detection of heavy hitters is implemented, then load balance is improved, but system complexity and overhead increase
Solution Approach 1:
The system implements feedback by detecting heavy hitter join key values during the run-time of the join operation. This feedback mechanism allows the system to dynamically identify which join keys are causing imbalance and adjust the distribution strategy accordingly, improving load balance while keeping the detection mechanism integrated into the existing query processing pipeline.
Data Source
AI summary
Techniques for detecting data skew while performing a distributed join operation on tables in a cluster of nodes managed by database management system (cDBMS), is disclosed. In an embodiment, heavy hitter values in a join column of a table are determined during the runtime of a distributed join operation of the table with another table. The cDBMS keeps in a datastore a count for each unique value read from the join column of the table. The datastore may be a hash table with the unique values serving as keys and may additionally include a heap or a sorted array for an efficient count based traversal. When a count for a particular value in the datastore exceeds a threshold, then the particular value is identified as a heavy hitter value. The tuples from the joined table that include the heavy hitter value, are kept local at the node that the tuples were originally distributed to, while the other joined table tuples are broadcasted to one or more nodes of the cDBMS that at least include the originally distributed nodes.