Shared HTAP Storage Fairness Scheduling for Multi-Tenant Scan Bursts
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing hybrid transactional/analytical processing (HTAP) databases face challenges in ensuring data freshness for real-time complex queries and managing burst concurrent workloads, especially in multi-tenant environments, which can lead to performance issues or crashes, and adding resources is costly.
Innovation Solution
A hybrid transactional/analytical processing (HTAP) database with separate OLTP and OLAP engines and a shared storage that employs fairness scheduling, scan deadlines, quality of service controls, and adaptive computation techniques to manage concurrent workloads and optimize resource usage.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Use of energy by stationary object
If OLAP systems update data periodically, then data processing cost is reduced, but data freshness is compromised for real-time queries
Solution Approach 1:
The patent segments the storage system into multiple storage tiers with different update frequencies. Hot data is stored in faster storage with more frequent updates, while cold data is stored in slower storage with less frequent updates. This segmentation allows the system to maintain data freshness for frequently accessed data while reducing processing costs for less frequently accessed data.
Solution Approach 2:
The patent implements dynamic data placement and update strategies where the update frequency and storage location of data are adjusted based on access patterns. Recently accessed or frequently accessed data is kept in faster storage with higher update frequency, while inactive data is moved to slower storage with lower update frequency, optimizing both freshness and cost dynamically.
2Reliability
If more resources are added to handle burst concurrent workloads, then system reliability is improved, but cost increases
Solution Approach 1:
The patent merges OLTP and OLAP workloads into a single shared storage system, allowing both types of operations to share the same physical resources. This consolidation eliminates the need for separate resource pools for transactional and analytical processing, reducing total resource requirements while maintaining system stability through unified resource management.
Solution Approach 2:
The patent dynamically adjusts storage parameters such as update frequency, cache size, and I/O priorities based on workload conditions. During burst concurrent workloads, the system adjusts parameters to prioritize stability and fairness, while during normal conditions, it optimizes for performance, eliminating the need for over-provisioning resources for peak loads.
3Productivity
If the shared storage executes multiple concurrent scan requests, then productivity is improved, but resource utilization becomes unbalanced leading to system crashes
Solution Approach 1:
The patent implements feedback mechanisms that continuously monitor resource usage during concurrent scan operations. When resource utilization thresholds are approached, the system dynamically adjusts the execution of ongoing scans, pausing or throttling certain operations to prevent resource exhaustion and system crashes, while still maintaining high overall productivity.
Solution Approach 2:
The patent employs periodic resource allocation and fairness scheduling where scan operations are executed in periodic batches with controlled concurrency. Instead of allowing unlimited simultaneous scans, the system processes scans in controlled waves, ensuring balanced resource utilization across multiple tenants while maintaining high throughput over time.
Data Source
Figure 1
Figure 2
Figure 3A
AI summary
A hybrid transactional/analytical processing, HTAP, database (10) includes an online transaction processing, OLTP, engine, an online analytical processing, OLAP, engine (14) provided separately from the OLTP engine (12), and a shared storage (26) holding data of multiple tenants. The shared storage (26) is configured to receive (302) a request for a first scan from a first tenant and a request for a second scan from a second tenant, execute (304) the first scan, and after a predetermined first period of time has elapsed without the first scan finishing, pause (306) the first scan and execute the second scan.