Bounding the Makespan of Transaction Schedules
Abstract
The performance of transactional database systems is typically evaluated by measuring the amount of transactions they can commit to the database per second. However, fairly measuring this for the same workload on different systems is not trivial. It is therefore relevant to formalize schedule efficiency, investigate the space of all possible efficient schedules, and identify whether there is any room for improvement. Prior transaction theory largely centers on decision problems relating to safety, such as the serializability, robustness, and allocation problems. Most pertinently, these problems take already scheduled transactions as input, and do not directly consider the efficiency of those schedules.
In this work, we define schedules as assignments of operations on objects to discrete points in time. This allows us to quantify efficiency as the elapsed duration between the schedule’s beginning and end, more commonly known as the makespan in the scheduling literature. We establish that, given some set of transactions and a desired makespan, it is NP-complete to decide if there exists a conflict serializable schedule which is bounded by that makespan. We additionally provide an instance optimal algorithm for scheduling transaction sets with a single contention point, that is, exactly one object may appear in conflicting operations. Lastly, we give worst-case optimal bounds on the makespan, meaning that schedules can never exceed this bound, and for the worst transaction sets, the bound is optimal.
Keywords and phrases:
Transactions, Scheduling, Discrete Optimization, ComplexityCopyright and License:
2012 ACM Subject Classification:
Theory of computation Discrete optimization ; Information systems Database transaction processingFunding:
This work is partly funded by FWO-grant G019921N.Editors:
Balder ten Cate and Maurice FunkSeries and Publisher:
Leibniz International Proceedings in Informatics, Schloss Dagstuhl – Leibniz-Zentrum für Informatik
1 Introduction
Transaction processing is a core aspect of every database system. In most systems it is implemented through concurrency control, a set of principled protocols which orchestrate access to resources shared by multiple threads of execution. In the database systems literature, this aspect of the system is evaluated by measuring its throughput, or the amount of transactions it can commit to the database per second, on various predetermined workloads such as YCSB [7] or TPC-C [8]. Reliably executing the same workload on different systems is not always evident, as is demonstrated by numerous papers attempting to make this evaluation method less biased [1, 10, 26, 33, 34]. As database theorists, it is therefore pertinent for us to consider a formal theory of schedule efficiency, to investigate the space of all possible efficient schedules, and to identify whether there is room for improvement.
The current theory about transactions largely centers around safety properties [18, 23], and we elaborate on this work’s relation to this literature in Section 7. In its most elementary form, safety is about deciding if a given schedule is valid according to a definition of validity, the gold standard being conflict serializability. In other words, the main purpose is to delineate the space of schedules that is valid. In this work, we are concerned with identifying the space of optimal schedules within that space of valid ones.
Concretely, we formalize schedules as assignments of all operations in a set of transactions to positive integers, intuitively representing their point of execution in time. This enables us to explicitly reason about operations that run in parallel, rather than observing the total order of operations after execution has taken place. Moreover, it lets us quantify efficiency as the elapsed duration between a schedule’s beginning and end, a quantity better known in the scheduling literature as the makespan [4, 25].
Contributions
We focus on two central questions, the first being: “What is the complexity of finding a conflict serializable schedule of minimal makespan?”. To this extent, we contribute the following results.
-
1.
In Section 3, we show that the schedules with minimal makespan are among those constructed from a total order on the transactions. Hence, we can find a minimal makespan schedule in factorial time by enumerating all total orders on the given transactions.
-
2.
Next, in Section 4, we show that for a set of transactions and a positive integer , it is NP-complete to decide if there exists a schedule with a makespan less than or equal to .
-
3.
In Section 5, we give a polynomial time instance optimal scheduling algorithm for transaction sets with at most one object on which operations are allowed to be conflicting.
Second, we handle a complementary question: “Is there a bound on the optimal makespan?”. To this end, we provide the following contribution.
-
4.
In Section 6, we derive worst-case optimal bounds on the makespan. That is, the makespan can never exceed this bound, and for the worst transaction sets, the bound is optimal. The upper bounds (excluding Proposition 27) imply algorithms that can generate schedules with a makespan matching this bound.
To enable this analysis, we group transaction sets into a class based on the maximal number of operations in each transaction, the maximal number of contention points (i.e., objects on which operations are allowed to be conflicting), and the maximal number of transactions in the set. The derived bounds are given in Table 1.
2 Definitions
For integers and , we write as shorthand notation for , and write as a shorthand for . By we denote the positive integers, including .
We fix an infinite set of objects . A transaction over is a sequence of operations . We write to mean the number of operations in . To every operation we associate a and an . We say that is a read if and that it is a write if . Furthermore, we say that is an operation on object .
For an integer , we write to denote the th operation of . That is, . Slightly abusing notation, we will often treat transactions as sets of objects, allowing to write to mean that is one of its operations. For two operations of , we write to mean , and to mean . We will leave implicit when it can be derived from the context and say transaction instead of transaction over .
When considering a set of transactions , we will assume that every transaction has a unique id , and we write to make this id explicit. For notational convenience we assume that each transaction can read to each object at most once, and write to each object at most once. This is an assumption commonly made in other literature [18, 19, 30, 31], and the problems we consider become computationally more difficult if this is not the case. It also allows us to refer to a specific operation in , using the notation (resp., ), with and (resp., ).
As usual, we say that two operations and occurring in transactions in are conflicting if they are from different transactions in , and with and .
We define schedules as functions assigning integers to the operations of transactions, intuitively representing the timing of these operations.
Definition 1.
A schedule for a set of transactions is a function that assigns a to all the operations of transactions in .
For notational convenience, we will sometimes represent a schedule for as a sequence of sets of operations (with every operation of a transaction in occurring in precisely one of the sets ), which then should be interpreted as the schedule for with if . In other words, the set represents all operations that are executed at precisely time .
Henceforth, we will only consider schedules having the next two additional properties:
-
1.
for operations with , we have ;
-
2.
for conflicting operations we have or .
Property (1) expresses that must preserve the order in which operations occur in the transaction they belong to. Property (2) guarantees that conflicting operations are not executed at precisely the same time.
We call a schedule dense if for every operation , either or there is an operation with and either conflicts with or it is from the same transaction as . In other words, a schedule is dense if none of its operations can be moved one time unit to the left without invalidating Property (1) or Property (2).
Example 2.
We define a set of transactions , where
We remark that usage of blind writes, or a write to an object without first reading to it within the same transaction, is not common in real-world transaction workloads. However, we use them to keep examples concise. One can always replace each write operation with a read followed by a write.
We remark that this definition of schedules differs from most literature111[32] has a definition based on partial orders, but does not use them to reason about schedule efficiency., e.g. [11, 18, 19, 30, 31], which typically defines schedules as total orders on operations. We deviate from this because we need to reason about the specific length of a schedule . Two operations and in that execute in parallel, that is in our model, are usually reduced to a freely chosen order on in the total order definition. Since the length of a schedule matters in our setting, we make this parallelism more explicit.
We are interested in precisely those schedules that maximally execute operations in parallel, while simultaneously exhibiting the same outcome as a schedule that executes each transaction one by one. We first define the latter condition, and then discuss what it means to maximally parallelize operations.
If a schedule for executes transactions one by one we say it is serial. Formally, a schedule is serial if it has no concurrent operations (i.e., for every pair of different operations , in , we either have or ) and it is non-interleaving (i.e., for every pair of different transactions , in , and every pair of different operations in , with there is no with ).
If conflicts with and , then depends on in , which is written as . We now define conflict serializable schedules, which formalizes one notion of what it means for a schedule to have the same outcome as a serial schedule.
Definition 3 (Papadimitriou [23]).
Let be a set of transactions and let and be schedules for . Then, is conflict equivalent to if implies and vice versa, for all conflicting operations and in . Furthermore, is conflict serializable if there exists a serial schedule for such that is conflict equivalent to .
We can test whether a schedule is serializable by creating a conflict graph for , which is a directed graph , where if there exists with and for distinct . We can then apply the next textbook result to obtain a decision procedure.
Theorem 4 (Papadimitriou [23]).
A schedule is conflict serializable if, and only if, is a directed acyclic graph.
To be able to compare the efficiency of schedules, we associate every schedule with a cost that equals its makespan. The makespan of a schedule is defined as
Intuitively, can be thought of as the completion time of the final operation in the given schedule.
Example 5.
Both the schedule for from Example 2 and the schedule for defined in Figure 1(b) are serializable. Namely, is equivalent to a serial schedule which first executes , then and , and finally . For a possible equivalent serial schedule, is followed by , then and finally . The makespan of is , while the makespan of is . Hence, the more efficient schedule is .
3 Precedence Graphs and Canonical Schedules
We define the precedence graph of a schedule for some set of transactions as the directed graph with and
Further on in this paper, we will refer to the precedence graph . This is notation for the precedence graph of the unique dense serializable schedule for originating from a total order on . More formally one replaces in the above definition by all such that , with , and .
The following property follows directly from Theorem 4:
Corollary 6.
For a serializable schedule for some set of transactions, the precedence graph is acyclic and there is an order such that .
Note that for schedules that are not serializable, the precedence graph must be cyclic.
Let us now denote for an acyclic directed graph by the maximum number of nodes occurring in any directed path of . Then, for a totally ordered set of transactions corresponds to the makespan of a particular schedule for .
Definition 7.
The canonical schedule for is defined as the schedule over with , and
where , and is the set of directed edges in .
It is straightforward to verify that canonical schedules are dense by construction.
Next we will show that a minimal cost schedule can be found among the canonical schedules. For this, let . The following corollary is immediate.
Proposition 8.
Let be a set of transactions.
-
For every serializable schedule for , we have that . If is dense, then .
-
There exists a total order such that .
-
There exists a total order such that .
Notice that this implies .
Example 9.
Let be the set of transactions from Example 2. Then, with is the precedence graph depicted in Figure 2. The longest path consists of edges and hence . The canonical schedule for equals schedule from Example 2.
4 Time Complexity
Unfortunately, it is unlikely that there are tractable algorithms that find an optimal serialization order for arbitrary sets of transactions. In this section, we consider a decision variant222There exists an analog definition of NP-completeness for optimization problems called NPO-complete. One possible way to show membership in this class is precisely by showing that the decision problem we consider, often called the threshold problem, is an NP-complete decision problem [9, 15, 21]. of our scheduling problem asking for a set of transactions and number if a serializable schedule for exists with and show that it is .
Schedulability input: a set of transactions and positive integer . output: true if a serializable schedule for with exists; false otherwise.
By Proposition 8, we can also give a total order for with .
Theorem 10.
Schedulability is NP-complete.
First, we argue that Schedulability is straightforwardly in , because, if for and a schedule exists with , then trivially serves as polynomial-sized witness.
To show that Schedulability is , we make a reduction from a simpler problem called 2-Orientability. For its definition, let be an undirected graph and let be a total order on its nodes. Then by we denote the orientation of based on , that is, the directed graph with nodes and with the directed edges . Now, 2-Orientability asks for an undirected graph if there exists a total order on the nodes in such that the length (number of edges) of every directed path in is at most .
2-Orientability input: an undirected graph . output: true if a total order on exists such that the length of the longest path in is at most 2; false otherwise.
The next result follows from the Gallai-Roy-Vitaver Theorem [5].
Proposition 11.
2-Orientability is .
We now conclude the proof for Theorem 10 by showing there exists a polynomial-time reduction from this problem to Schedulability.
Proposition 12.
.
Given some graph as input for 2-Orientability, we will explain the construction of a set of transactions and will then argue that:
For the construction, we first fix an arbitrarily chosen order on the edges of , which allows referring to them as , , …, . We also associate to every edge three different and unique objects , , and . Then, the set that we construct, will consist of precisely transactions, such that there is one transaction for each node in . We write to denote the transaction associated to node . Every transaction consists of precisely operations, namely
The objects these operations interact with are chosen as follows: if , then , and are the earlier defined objects , , and , respectively. Otherwise, if , then , and are (all different) unique objects not occurring anywhere else in our construction.
We remark that this construction is indeed polynomial. To conclude the proof of Proposition 12, we make use of Proposition 8 and the next result.
Lemma 13.
For any total order on , the longest path in counts at most two edges if and only if , with .
Some visual intuition for this lemma, in particular the construction of these longest paths through , can be seen in Figure 3.
5 Instance Optimal Scheduling
We now turn our attention to instance optimal scheduling algorithms. That is, we will identify a restriction on transaction sets that will enable us to compute schedules with a minimal makespan, for any set adhering to this restriction, in polynomial time.
To this extent, we define the contention points of as a set of objects such that if and are conflicting operations in , then . The converse does not necessarily have to hold, not every contention point must appear in a conflicting operation. We will refer to an element of as a contention point, and say that a contends if contains an operation on a contention point.
We now define as a set of transaction sets with if for all , , and . Exclusively in this section, we write instead of , as all results can be phrased such that is the length of the longest transaction in our set, and we can let . We also define with if and contends for all .
Given , we can see each as a sequence:
where is the position in such that , and consists of a (potentially empty) subsequence of operations, followed by a conflicting operation to the contention point , and another (potentially empty) subsequence of operations. In the above sequence we can also replace by as long as it is a conflicting operation, we typically use throughout this section, this does not impact the generality of our results. We call the former subsequence the prefix of ; the latter is the suffix of . We define and to be the number of operations before the first (respectively, after the last) contention point.
Definition 14.
Let . An allocation of to is an injective function , which maps transactions to a such that and . We call the bin of .
We will also denote the inverse of by . Notice that, means there are bins in total, as we start counting from 0.
For any allocation of a to , we can use the allocation as an ordering on the transactions. Indeed, if for , then we define an order such that . Conversely, we can define an allocation to based on a total order with . Let this total order be . Then for each , with , we define such that is the minimal bin with , , and for all . We then have the following result.
Proposition 15.
There exists an allocation of to , if, and only if, there exists a total order of such that . Moreover, if exists then . And, if exists then .
The former characterization gives us a tool for constructing an optimal order, provided we have an algorithm for allocations. To that end, we define an algorithm .
It is clear that is sound by construction. That is, if it does not terminate with , it terminates with a valid allocation of to . Showing completeness, that is, termination with implies there exists no valid allocation from to , requires slightly more argumentation. The following lemma is a useful tool.
Lemma 16.
Let . For every , and every allocation of on , we have that .
Completeness follows from assuming a smaller allocation exists despite the algorithm yielding , and then showing it contradicts Lemma 16. Proposition 15 ensures no order exists either.
Theorem 17.
For any and , the algorithm runs in time and returns an allocation of to if it exists and otherwise.
We can repeat the algorithm with a that starts at the length of the largest transaction, incrementing whenever it yields . We terminate when the first allocation is returned. We remark that is at most , hence depends entirely on the transaction set, and therefore its time complexity is polynomial and entirely dependent on .
Until now, we have considered transactions from , but this restriction can be easily relaxed to any by only considering the transactions in which contend. To obtain an ordering for the full we can append the remaining transactions arbitrarily onto the allocation order. The corollary then readily follows from Proposition 15 and Theorem 17.
Corollary 18.
If and , then is decidable in time.
The algorithm in this section resembles an instance optimal algorithm for the Job Shop Scheduling problem called Johnson’s Rule [16]. We illustrate it is subtly different.
Example 19.
Job shop problem inputs consist of jobs (analogous to our transactions), containing a sequence of operations lasting a duration on machines (analogous to our objects). Johnson’s rule is applicable when all jobs have two operations on two machines in a single order, hence we represent jobs as pairs where and are the durations spent on the first and second operation.
Consider the job shop instance . Johnson’s rule repeatedly picks the operation with the shortest duration and places it in the first free position starting from the front of the schedule if that duration is for the first machine, and places it in the first free position starting from the end of the schedule if it is for the last machine, while breaking ties arbitrarily. A valid schedule would be .
If we now create transactions for each job such that and , then the allocation for matching the order is , , and . However, an allocation for is given by our algorithm, namely, , , . Hence, Johnson’s rule does not give an optimal schedule for the transaction scheduling problem.
6 Worst-Case Optimal Scheduling
We now look at the transaction scheduling problem from the perspective of worst-case analysis. More specifically, we derive a worst-case optimal bound on the makespan for any transaction set, and in doing so, construct algorithms for any transaction set which yield schedules with a makespan that never exceeds this bound. Additionally, on the worst-behaving transaction sets, the resulting schedules must be optimal.
We define the worst-case optimal cost for as
Since we are concerned with a worst-case scenario, we will consider transactions to be long enough for them to contain operations on each contention point, that is, . Alongside this, we always have and .
For , , and , this cost is trivial to determine. Indeed, if the makespan of all schedules is simply . Similarly, if we can always execute all transactions entirely in parallel, hence . Lastly, if , the lone operation on the contention point occurs in the same position in every transaction in all instances for which is maximal. An optimal schedule will shift each operation in each consecutive transaction forwards by one time unit, hence given . Determining the worst-case optimal makespan for and is non-trivial, and concerns the rest of this section.
6.1 Extra Notation
We first introduce some notation. Let be a finite sequence of distinct objects. We will write to denote the th object in . For a transaction in a transaction set , we will let represent the sequence of contention points ordered in the way accesses them. We write to refer to the position of the operation on the contention point in some transaction . Lastly, we define as .
Next, let and be two length sequences of distinct objects. We define the maximal overlap between and , denoted , as the maximal number such that for all and all we have ; if no such exists, then . Given a totally ordered finite set of same-length distinct object sequences , its total overlap is defined as the sum , where all are ordered as per . The maximal total overlap for is .
Finally, for any two disjoint ordered sets and , we define the concatenation of and as where is either with , or with , or and . Notice that this operation is associative, so we will write for .
6.2 Two Contention Points or Transactions
Transaction sets containing two transactions or two points of contention (or both) have the following worst-case optimal bound on their makespan.
Theorem 20.
We have that where and , and where and .
If and , then a trivial upper bound is as there are maximally that many operations in . A matching lower bound can be constructed by taking the set where and , where the dots “” represent read operations on unique objects, and with both transactions of length . Intuitively, flips the first and last operations in . Indeed, both total orders on lead to a schedule with an optimal makespan of as it is impossible for the transactions to be concurrently scheduled, that is, .
For the upper bound when and , we give the construction of an order for . Let . We have either or . In the former case, we will define on such that transactions with the largest distance between the first and second contention point, that is , appear first. And, in the latter case, let on such that transactions with the smallest appear first. Lastly, we get an order . We give a visualization of in Figure 4, which gives intuition for the next result.
Proposition 21.
For with and : .
Lastly, for the lower bound, we construct a transaction set with and . We will populate the set to reach transactions by adding copies of the transaction , and copies of , such that . A precedence graph for any order on , along with a longest path in this graph, is given in Figure 5.
Proposition 22.
.
Proof.
Let be a total order, and refer to ’s elements by , reflecting this order. Because must respect each transaction’s order of operations, there exists a path of nodes between each and for . And, because the directed edges in must respect for conflicting operations, there exists a path and a path in that both have nodes. Since there are transactions with and transactions with , there exists a path in of length for some . If we outline these paths such as in Figure 5, we see a grid-like pattern with columns and rows.
Clearly, the longest path starts in , passes through for all , and ends in . Hence, . The desired result follows by Proposition 8.
6.3 Three Contention Points
First, we concern ourselves with the case where . The following insight is key.
Proposition 23.
Every with satisfies .
We can use the above result for all in each transaction to obtain a transaction order in which the total overlap between transactions is . This results in an upper bound of . For the lower bound, consists of transactions of the shape , where each is unique in ordered as per the above result, and with “” being reads on unique objects.
Theorem 24.
Let and , then .
Once we allow , the new subproblem that arises is one of optimally scheduling all , since for some and . Notice that each is of the form:
where, for all , the dots “” represent read operations on unique objects, such that . We write these transactions as tuples if the is irrelevant. To find a lower bound, we need assignments for all in all , such that is maximal. We now give our best estimates. If , then . If , then this is . And finally, when then . To go beyond this, we can repeat any until . Figure 6 shows the worst optimal schedules we could find for these sets.
The above are concatenated with a maximal total overlap of (c.f., Theorem 24). Hence, the first 5 orders each add to the makespan, the final order adds . This leads to the following lower bound.
Proposition 25.
There exist with , such that
For the upper bound, we construct an order for with . First, define a total order such that the with the greatest are placed first. And, we define another total order such that the with the smallest are placed first. For all remaining with and we choose any total order . We then define a total order for . is illustrated in Figure 7.
Proposition 26.
For with and : .
6.4 Any Number of Contention Points
First, we notice that the upper bound for three contention points also holds for more than three contention points.
Proposition 27.
If , , and , then for all it is the case that .
This is not a worst-case optimal bound, and it is not constructive. A better upper or lower bound requires a generalization of Proposition 23 for arbitrary . It is possible to reduce the hamiltonian path problem–known to be NP-complete–to this problem, and it is therefore difficult to prove constructive results for.
Whenever we have transactions or more, we can make use of an interesting observation relating to object sequences. To this extent, we define the following concept.
Definition 28.
Let and be equal-length sequences of unique objects, then is an adjacent transposition of if for .
The notation denotes that is an adjacent transposition of . Intuitively, swaps precisely two adjacent elements in . We will write to mean that both and . Additionally, we call where each sequence has operations an adjacent transposition sequence for if . Adjacent transpositions have the following property.
Lemma 29.
If and are equal-length sequences of unique objects, and , then .
The next insight follows from the above lemma and the Steinhaus-Johnson-Trotter algorithm, which for a permutation of objects, generates an adjacent transposition sequence for [17, 28, 29]. This algorithm does not run in polynomial time, as it generates all possible sequences of objects.
Lemma 30.
If , , , and with containing all equal-length sequences of distinct objects, then .
The above results imply we can construct a transposition sequence such that . From this, we construct a total order for any , with and . For we define the total order such that a transaction appears earlier in if is larger. And, for we define the total order such that that appears earlier in if is smaller. For all other with , we choose an arbitrary total order . Lastly, we define to be a total order on . This then gives the next bounds.
Theorem 31.
If , , and , then .
If then the above scheduling method gives us the following upper bound.
Theorem 32.
If , , and , then for all we have that .
Table 1 summarizes the results given in this section.
7 Related Work
For years, serializability has been the gold standard for ensuring data consistency. In brief, a transaction schedule is serializable if it is equivalent (for some notion of equivalence) to some serial execution of these transactions. One straightforward notion of equivalence is view equivalence, which states that two schedules are equivalent if all read operations observe the same values and the final database state is the same for both schedules. A famous result by Papadimitriou [24] states that view serializability is NP-complete. Although view serializability is a natural notion of serializability, this negative result has led to the adoption of conflict serializability as the de facto standard for serializability in practice, and is frequently simply referred to as “serializability”. Contrasting view equivalence, conflict equivalence puts a more direct restriction on the order of operations. In particular, all pairs of conflicting operations must be ordered the same in both schedules. It is well known that conflict serializability of a schedule can be decided in polynomial time, and that every conflict serializable schedule is view serializable as well [23]. The serializability problem is orthogonal to the scheduling problem, as the former is concerned with deciding serializability for a given schedule, while the latter is concerned with finding the most efficient serializable schedule for a given set of transactions.
To the best of our knowledge, the only prior results on scheduling are also from Papadimitriou [24], who established that a scheduler which allows precisely all view serializable schedules will likely be inefficient unless . This result is to be expected, given the NP-completeness of deciding view serializability. Contrasting these results by Papadimitriou, we restrict the search space of schedules to those that are conflict serializable, a property which can be tested in polynomial time. Our NP-completeness result therefore strengthens this earlier work, and shows that a tractable notion of serializability does not necessarily lead to tractable scheduling algorithms.
Orthogonal to finding more efficient schedules that guarantee (conflict) serializability, database systems frequently offer lower levels of isolation, such as read committed or snapshot isolation. In fact, many commercial database systems offer these lower isolation levels by default, and some do not even support conflict serializability [3]. The relaxed consistency guarantees of these lower isolation levels allow for more concurrency, and therefore higher throughput. This performance increase comes at a cost, however, as these lower isolation levels no longer guarantee serializability. Recent work from the database theory community has looked into the transactional robustness problem [11, 18, 19, 30]. The robustness problem is concerned with the following question: given a set of transactions and a specific isolation level, is every allowed schedule (i.e., consistent with the isolation level) a serializable schedule? This robustness property guarantees that the set of transactions can be safely executed under the lower isolation level, thereby increasing performance, while still ensuring serializability. The allocation problem [11, 31] extends upon this problem by considering a setting where isolation levels can be mixed (i.e., different transactions are allocated to different isolation levels), and tries to identify the optimal allocation that still guarantees serializability for the given workload. We emphasize that this line of work relies on an existing scheduler. A key assumption is that, although this scheduler is guaranteed to produce a schedule in line with the chosen isolation levels, the produced output schedule cannot be chosen. Instead, robustness involves verifying serializability of every possible output schedule. The robustness and allocation problems are orthogonal to the scheduling problem, as they rely on an existing scheduler to execute transactions, rather than directly constructing an efficient serializable schedule over the provided workload.
Outside of the database literature, the job shop scheduling problem [4, 25] is the closest relative to the transaction scheduling problem. Indeed, one can see objects as machines, transactions as jobs, and operations as always lasting a single unit of time. The associated decision problem is similarly known to be NP-complete, even when limited to 3 machines [27], known to be approximable only if the operations are unit-time [20, 22], and has a polynomial time approximation scheme (PTAS) if the maximal job length and the number of machines is fixed [13]. However, the results do not carry over. The job shop scheduling problem is distinct because its resulting schedules are not conflict serializable.
The only systems doing explicit scheduling based on makespan in practice, to the best of our knowledge, are the system from Cheng et al. [6] and a prototype system discussed in a workshop article [2]. The former system [6] relies on a heuristic that clusters transactions based on the most frequently occuring contention point, and has seen promising performance. This demonstrates the viability of scheduling algorithms for transactions, and of utilizing contention points to perform workload analysis.
8 Discussion
We return to our central questions. First, “What is the complexity of finding a conflict serializable schedule of minimal makespan?”. We have shown there is a factorial time algorithm for this problem; that the decision variant is NP-complete; and lastly, that there is an instance optimal algorithm for single contention point transaction sets.
Secondly, “Is there a bound on the optimal makespan?”. Our bounds in Table 1 indicate that if the number of transactions is low, then worst-case optimal schedules are close to serial. This gets progressively better once , as the increased number of transactions enables more parallellism. Moreover, the most sensitive parameter is . Hence, workloads with many contention points are likely to make all transaction scheduling approaches struggle.
Open Problems
Many interesting problems remain open. There is still a gap between the number of contention points needed in the construction used for Theorem 10, and those needed for the algorithm in Section 5. A possibility would be extending techniques for job shop scheduling’s proofs. Given that the problem is known to be NP-hard for 3 machines, it may lead to similar results.
Furthermore, there are missing worst-case optimal bounds for the sets with , and in case and . We suspect that the upper bounds can be lower than the ones provided. Moreover, the upper bound provided in the case of for arbitrary is not constructive.
The work around bounds is necessary to investigate the approximation complexity of transaction scheduling. This domain has many interesting results for job shop scheduling (c.f., Mastrolilli et al. [22] and Fishkin et al. [12, 13]). It involves constructing approximation-preserving reductions (e.g., L-reductions [9, 15]) from existing problems in discrete optimization, which enable us to decide membership in the class of approximable optimization problems (APX), or the class that admits a polynomial time approximation scheme (PTAS). The former would show there are tractable algorithms for which the output schedule has a makespan within a constant factor of its optimal makespan. The latter implies that we can find a tractable algorithm that gets arbitrarily close to the optimal makespan.
Lastly, the algorithms provided in this work require knowledge of the transaction set before execution. To bridge this gap, queuing theory may be an inspiration [14]. This means entry of transactions into the system becomes a stochastic process, increasing complexity.
References
- [1] Dana Van Aken, Djellel Eddine Difallah, Andrew Pavlo, Carlo Curino, and Philippe Cudré-Mauroux. Benchpress: Dynamic workload control in the oltp-bench testbed. In Timos K. Sellis, Susan B. Davidson, and Zachary G. Ives, editors, Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data, Melbourne, Victoria, Australia, May 31 - June 4, 2015, pages 1069–1073. ACM, 2015. doi:10.1145/2723372.2735354.
- [2] Tim Baccaert and Bas Ketsman. Cascade: Optimal transaction scheduling for high-contention workloads. In PhD Symposium of the 40th IEEE International Conference on Data Engineering, ICDE 2024, Utrecht, The Netherlands, May 13-16, 2024, pages 5634–5638. IEEE, 2024. doi:10.1109/ICDE60146.2024.00452.
- [3] Peter Bailis, Aaron Davidson, Alan D. Fekete, Ali Ghodsi, Joseph M. Hellerstein, and Ion Stoica. Highly available transactions: Virtues and limitations. Proc. VLDB Endow., 7(3):181–192, 2013. doi:10.14778/2732232.2732237.
- [4] Peter Brucker. Scheduling algorithms (4. ed.). Springer, 2004.
- [5] Gerard J. Chang, Li-Da Tong, Jing-Ho Yan, and Hong-Gwa Yeh. A Note on The Gallai-Roy-Vitaver Theorem. Discret. Math., 256(1-2):441–444, 2002. doi:10.1016/S0012-365X(02)00386-2.
- [6] Audrey Cheng, Aaron N. Kabcenell, Jason Chan, Xiao Shi, Peter D. Bailis, Natacha Crooks, and Ion Stoica. Towards optimal transaction scheduling. Proc. VLDB Endow., 17(11):2694–2707, 2024. doi:10.14778/3681954.3681956.
- [7] Brian F. Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, and Russell Sears. Benchmarking cloud serving systems with YCSB. In Joseph M. Hellerstein, Surajit Chaudhuri, and Mendel Rosenblum, editors, Proceedings of the 1st ACM Symposium on Cloud Computing, SoCC 2010, Indianapolis, Indiana, USA, June 10-11, 2010, pages 143–154. ACM, 2010. doi:10.1145/1807128.1807152.
- [8] Transaction Processing Performance Council. Tpc benchmark c standard specification revision 5.2, 2006.
- [9] Pierluigi Crescenzi. A short guide to approximation preserving reductions. In Proceedings of the Twelfth Annual IEEE Conference on Computational Complexity, Ulm, Germany, June 24-27, 1997, pages 262–273. IEEE Computer Society, 1997. doi:10.1109/CCC.1997.612321.
- [10] Djellel Eddine Difallah, Andrew Pavlo, Carlo Curino, and Philippe Cudré-Mauroux. Oltp-bench: An extensible testbed for benchmarking relational databases. Proc. VLDB Endow., 7(4):277–288, 2013. doi:10.14778/2732240.2732246.
- [11] Alan D. Fekete. Allocating isolation levels to transactions. In Chen Li, editor, Proceedings of the Twenty-fourth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, June 13-15, 2005, Baltimore, Maryland, USA, pages 206–215. ACM, 2005. doi:10.1145/1065167.1065193.
- [12] Aleksei V. Fishkin, Klaus Jansen, and Monaldo Mastrolilli. On minimizing average weighted completion time: A PTAS for the job shop problem with release dates. In Toshihide Ibaraki, Naoki Katoh, and Hirotaka Ono, editors, Algorithms and Computation, 14th International Symposium, ISAAC 2003, Kyoto, Japan, December 15-17, 2003, Proceedings, volume 2906 of Lecture Notes in Computer Science, pages 319–328. Springer, 2003. doi:10.1007/978-3-540-24587-2_34.
- [13] Aleksei V. Fishkin, Klaus Jansen, and Monaldo Mastrolilli. Grouping techniques for scheduling problems: Simpler and faster. Algorithmica, 51(2):183–199, 2008. doi:10.1007/s00453-007-9086-6.
- [14] Donald Gross, John F. Shortle, James M. Thompson, and Carl M. Harris. Fundamentals of Queueing Theory, Fourth Edition. Wiley Series in Probability and Statistics. Wiley, 2008. doi:10.1002/9781118625651.
- [15] Juraj Hromkovic. Algorithmics for Hard Problems - Introduction to Combinatorial Optimization, Randomization, Approximation, and Heuristics. Texts in Theoretical Computer Science. An EATCS Series. Springer, 2001. doi:10.1007/978-3-662-04616-6.
- [16] S. M. Johnson. Optimal Two- and Three-stage Production Schedules with Setup Times Included. Naval Research Logistics Quarterly, 1(1):61–68, 1954.
- [17] Selmer M. Johnson. Generation of permutations by adjacent transposition. Mathematics of Computation, 17(83):282–285, 1963.
- [18] Bas Ketsman, Christoph Koch, Frank Neven, and Brecht Vandevoort. Concurrency control for database theorists. SIGMOD Rec., 51(4):6–17, 2022. doi:10.1145/3582302.3582304.
- [19] Bas Ketsman, Christoph Koch, Frank Neven, and Brecht Vandevoort. Deciding robustness for lower SQL isolation levels. ACM Trans. Database Syst., 47(4):13:1–13:41, 2022. doi:10.1145/3561049.
- [20] Frank Thomson Leighton, Bruce M. Maggs, and Andréa W. Richa. Fast algorithms for finding o(congestion + dilation) packet routing schedules. Comb., 19(3):375–401, 1999. doi:10.1007/s004930050061.
- [21] J.K. Lenstra and A.H.G. Rinnooy Kan. Computational complexity of discrete optimization problems. In P.L. Hammer, E.L. Johnson, and B.H. Korte, editors, Discrete Optimization I, volume 4 of Annals of Discrete Mathematics, pages 121–140. Elsevier, 1979.
- [22] Monaldo Mastrolilli and Ola Svensson. Hardness of approximating flow and job shop scheduling problems. J. ACM, 58(5):20:1–20:32, 2011. doi:10.1145/2027216.2027218.
- [23] Christos Papadimitriou. The theory of database concurrency control. Computer Science Press, Inc., USA, 1986.
- [24] Christos H. Papadimitriou. The serializability of concurrent database updates. J. ACM, 26(4):631–653, 1979. doi:10.1145/322154.322158.
- [25] Michael L. Pinedo. Scheduling: Theory, Algorithms, and Systems. Springer, 2022.
- [26] Luyi Qu, Yuming Li, Rong Zhang, Ting Chen, Ke Shu, Weining Qian, and Aoying Zhou. Application-oriented workload generation for transactional database performance evaluation. In 38th IEEE International Conference on Data Engineering, ICDE 2022, Kuala Lumpur, Malaysia, May 9-12, 2022, pages 420–432. IEEE, 2022. doi:10.1109/ICDE53745.2022.00036.
- [27] Yuri N. Sotskov and Natalia V. Shakhlevich. Np-hardness of shop-scheduling problems with three jobs. Discret. Appl. Math., 59(3):237–266, 1995. doi:10.1016/0166-218X(95)80004-N.
- [28] Hugo Steinhaus. One hundred problems in elementary mathematics. Basic Books, Inc., Publishers, New York, 1964.
- [29] H. F. Trotter. Algorithm 115: Perm. Commun. ACM, 5(8):434–435, August 1962. doi:10.1145/368637.368660.
- [30] Brecht Vandevoort. Optimizing Concurrency Control: Robustness Against Read Committed Revisited. PhD thesis, Hasselt University, Belgium, 2021. URL: https://hdl.handle.net/1942/35460.
- [31] Brecht Vandevoort, Bas Ketsman, and Frank Neven. Allocating isolation levels to transactions in a multiversion setting. In Floris Geerts, Hung Q. Ngo, and Stavros Sintos, editors, Proceedings of the 42nd ACM SIGMOD-SIGACT-SIGAI Symposium on Principles of Database Systems, PODS 2023, Seattle, WA, USA , June 18-23, 2023, pages 69–78. ACM, 2023. doi:10.1145/3584372.3588672.
- [32] Gerhard Weikum and Gottfried Vossen. Transactional Information Systems: Theory, Algorithms, and the Practice of Concurrency Control and Recovery. Morgan Kaufmann, 2002.
- [33] Siyang Weng, Qingshuai Wang, Luyi Qu, Rong Zhang, Peng Cai, Weining Qian, and Aoying Zhou. Lauca: A workload duplicator for benchmarking transactional database performance. IEEE Trans. Knowl. Data Eng., 36(7):3180–3194, 2024. doi:10.1109/TKDE.2024.3360116.
- [34] Huidong Zhang, Luyi Qu, Qingshuai Wang, Rong Zhang, Peng Cai, Quanqing Xu, Zhifeng Yang, and Chuanhui Yang. Dike: A benchmark suite for distributed transactional databases. In Sudipto Das, Ippokratis Pandis, K. Selçuk Candan, and Sihem Amer-Yahia, editors, Companion of the 2023 International Conference on Management of Data, SIGMOD/PODS 2023, Seattle, WA, USA, June 18-23, 2023, pages 95–98. ACM, 2023. doi:10.1145/3555041.3589710.
Appendix A Enumeration Scheduling
To construct an optimal serializable schedule, we can enumerate all possible linear orders for and pick one such order with a minimal . This is precisely the idea behind the enumerative scheduling algorithm EnumSchedule.
Proposition 33.
Let be a set of transactions, then computes a serializable schedule of minimal makespan in time.
Proof.
First, observe that is trivially serializable due to Proposition 8.
Furthermore, is minimal. Indeed, we consider all possible linear orders , hence, by Proposition 8 the order for which will be considered by the algorithm.
Finally, the time complexity follows from the fact that we consider all total orders on , of which there are precisely . For each order , we compute the longest vertex path in its accompanying precedence graph . Since is acyclic, we can compute this by doing a depth-first post-order traversal which has a time complexity of . However, we know hence this is equivalent to . Furthermore, is equal to , which gives an overall bound of .
Appendix B Missing Proofs for Section 3
B.1 Proof for Proposition 8
Proposition 34.
Let be a set of transactions. For every serializable schedule for , we have that . If is dense, then .
Proof.
Let be some serializable schedule. By definition, . The equality follows from a simple inductive argument showing that for the longest directed path in , the set cannot contain an operation with , thus implying .
By definition of dense schedule, for every , with , there is a such that is an edge in the precedence graph. The latter immediately implies that there is a directed path with nodes in , which means .
Proposition 35.
Let be a set of transactions. There exists an ordering over such that , with .
Proof.
Let be some serializable schedule for with . We assume that is dense. The latter is w.l.o.g., because otherwise we can repeatably pick a problematic operation and move it one step to the left, until the resulting schedule is dense. Clearly, the resulting schedule is equivalent to and thus remains conflict-serializable. We have and thus by choice of .
Appendix C Missing Proofs for Section 4
C.1 Proof for Lemma 13
Lemma 36.
For any total order on , the longest path in counts at most two edges if and only if , with .
Proof.
To follow along with the proof, it will be helpful to have some visual intuition about the structure of . Therefore, we recall that the nodes of coincide with the operations of transactions in and that an edge in either means that is the direct successor of in some transaction, or that and are conflicting operations from different transactions. More precisely, in the latter case it follows from the construction of that and with and with and for some integer . We call the latter edge a cross transaction edge from to .
(If.)
The proof is by contraposition, i.e., we show that if than there is a path in with three edges. For this, first recall that implies existence of a directed path in with nodes, and hence with a length of . Now, making use of the earlier developed intuition about , we observe that every path of length contains at least cross transaction edges (since every individual transaction is represented in by precisely edges, and by the fact that cross transaction edges are always from transactions to with .). Since in our case it follows that there are at least three cross transaction edges. Hence, we can assume that there is an edge , and with , , and , which implies that a directed path in exists, which is clearly of length three.
(Only-if.)
This direction is by contraposition as well, hence, we show that if there exists a directed path in of length then there exists a directed path in of length . For this, let be such a path of precisely length three, with , , and . Then, we construct a directed path in as follows: first traverse the consecutive operations of transaction up to (and including) its operation . Then traverse the cross transaction edge , followed by the consecutive operations of transaction consecutive to till (and including) operation . Then analogously as before, traverse the cross transaction edge followed by consecutive operations of in till (and including) after which yet another cross transaction edge is traversed, followed by the remaining operations of consecutive to . It can be verified that the constructed path has a length of precisely , which concludes the proof.
