Action-Based Transaction Routing for OLTP Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
High-throughput online transaction processing (OLTP) systems face inefficiencies due to poor instruction-data locality and increased overhead from lock and latch conflicts, as well as difficulties with profiling system performance, particularly in distributed database environments where multiple threads access shared data.
Innovation Solution
A data-oriented transaction processing model is implemented, where transactions are divided into actions based on data dependencies, allowing each action to be routed and executed by the nodes that store the relevant data, reducing the need for data transfer and minimizing lock conflicts through action-based routing and the use of agent threads for parallel execution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If multiple worker threads execute transactions concurrently on distributed servers, then inter-transaction parallelism is improved, but instruction-data locality deteriorates and query overhead increases
Solution Approach 1:
Instead of having threads execute transactions and access data wherever it resides, the patent inverts the approach by routing transactions to the servers where the data is located. The routing node receives a transaction, determines which server holds the relevant data, and directs the transaction to that specific server, thereby eliminating the need for threads to remotely access data and compile queries on the fly.
Solution Approach 2:
The patent introduces a routing node as an intermediary between the thread executing the transaction and the server storing the data. This routing node acts as a mediator that analyzes the transaction, identifies the appropriate data location, and directs the transaction to the correct server, thereby simplifying the overall system architecture and reducing query overhead.
2Adaptability or versatility
If threads access shared data from distributed nodes, then transaction flexibility is improved, but lock and latch conflicts increase
Solution Approach 1:
The patent applies local quality by ensuring that each server processes transactions locally on data that resides on that same server. This localization means that threads on different servers operate on different data partitions, thereby eliminating or significantly reducing lock and latch conflicts that would occur if multiple threads attempted to access the same shared data simultaneously.
3Ease of operation
If data is brought from distributed nodes to a transaction, then transaction execution is simplified, but network traffic and overhead increase
Solution Approach 1:
The patent inverts the traditional approach by instead of bringing data to the transaction, routing the transaction to where the data is located. This eliminates the need for extensive data movement across the network, thereby reducing network traffic overhead while maintaining transaction execution simplicity through the automated routing process.
4Adaptability or versatility
If traditional SQL query processing is used, then data manipulation is standardized, but compilation and execution overhead increase
Solution Approach 1:
The patent extracts the overhead-intensive steps of query compilation and execution plan generation from the traditional SQL processing path. By routing transactions directly to the appropriate server based on data location, the system eliminates the need for complex query compilation and execution planning, thereby improving throughput while maintaining standardized data manipulation capabilities.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A request to perform a transaction on a database in an online transaction processing system is accessed by a node. The sets of data in the database that the transaction is to act on are determined. The transaction is then separated into actions according to the data dependencies of the actions; an action is established for each set of data that is acted on by the transaction. The actions are communicated to the nodes that store the data that the respective actions depend on. The actions are then performed on the nodes to which they were routed.