The unexplored TPC-E

To represent real-life OLTP workloads more realistically, TPC presented TPC-E [193] as an alternative to the dominant TPC-C. This subsection gives an overview of TPC-E while pointing out its differences mainly from TPC-C.

Model

TPC-E models a brokerage house. The database tables keep information about customers, brokers, and a market. The transactions simulate a workload where either the customers initiate requests to the brokerage house (customer initiated transactions) or the market sends ticker feeds or trade results to the brokerage house (market-triggered transactions). The brokerage house responds to the customers, checks the orders to decide whether to submit them or not, submits the related brokerage requests (brokerage initiated transactions), and analyzes or updates the database. One could say that the TPC-E benchmark represents a more complicated business model compared to the TPC-C benchmark.

Database

TPC-E has more tables than TPC-C; thirty-three tables instead of nine:

• nine of TPC-E’s tables are offixedsize,

• sixteen arescalingbased on the number ofCustomers, and

• eight aregrowing.

However, the growth rate of thegrowingtables varies and, in general, it is greater than the growth rates of thegrowingtables in TPC-C. In addition, the TPC-E tables are populated with pseudo-real data and exhibit data skew. By contrast, TPC-C tables have randomly generated data that face a low degree of skew.

The scaling factor determines the number ofBranches in TPC-B and the number ofWarehouses in TPC-C. TPC-E has a scaling factor that controls the number ofCustomers in the database. However, unlike TPC-B and TPC-C, where a single scaling factor (via the number ofBranches andWarehouses) is the only parameter that determines the initial size of the database, TPC-E has two additional parameters that affect the database size right after database population. In particular, the parameters calledworking daysandscaling factorcontrol the cardinality of theTradetable and in turn all the othergrowingtables in TPC-E. TPC-E also has agrowing

table,Trade_Request, which right after database population starts as an empty table and then grows. Neither TPC-B nor TPC-C has empty tables after the initial database population.

2.4. Evolution of TPC’s OLTP benchmarks

Table 2.1: TPC-E transactions.

Transaction Weight Access Category Frames Executed % in Mix BrokerVolume Mid to Heavy RO BI 1 (out of 1) 4.9 CustomerPosition Mid to Heavy RO CI 2/3 (out of 3) 13

MarketFeed Medium RW MT 1 (out of 1) 1

MarketWatch Medium RO CI 1 (out of 1) 18

SecurityDetail Medium RO CI 1 (out of 1) 14

TradeLookup Medium RO BI/CI 1 (out of 4) 8

TradeOrder Heavy RW CI 2/5/6 (out of 6) 10.1

TradeResult Heavy RW MT 5/6 (out of 6) 10

TradeStatus Light RO CI 1 (out of 1) 19

TradeUpdate Medium RW BI/CI 1 (out of 3) 2

BI: Brokerage Initiated, CI: Customer Initiated, MT: Market Triggered, RO: Read-Only, RW: Read-Write

Transactions

TPC-E contains twelve transactions in total, which are shown inTable 2.1. Only ten of the transactions belong to the regular transaction mix. Two of them, DataMaintenanceand

TradeCleanup, get executed separately. DataMaintenanceis executed periodically, every minute, alongside the transaction mix, whereasTradeCleanupneeds to be executed before each run if one wants to clean up the submitted or pending trades from a previous run in order to restore the initial database state. In TPC-C, all the five transactions are included in the transaction mix.

The TPC-E transactions consist offrames, which are parts of a long transaction with a distinc- tive task. For some transactions only a subset of their frames are executed depending on the input values or whether they are initiated by a customer or brokerage; like inTradeLookupand

TradeUpdate. TPC-C does not contain as complicated and long transactions. All transactions in TPC-C have only one frame.

Another significant distinction of TPC-E from its predecessors is that a majority of the transac- tions in the mix are Read-Only (RO). That is, in TPC-E around 75% of the transactions executed are read-only, whereas TPC-C has 92% Read-Write (RW) transactions in the mix.

TPC-E also enforces dependencies among some of its transactions. More specifically, the market-triggered transactions,TradeResultandMarketFeed, require theTradeOrdertrans- actions to submit input for them. Therefore, they cannot be executed independently from the transaction mix. In TPC-C none of the transactions have such dependencies.

The TPC-E specification also introduces skew in transaction inputs, harness control measures within the transactions, and checks for referential integrity constraints, which do not exist in TPC-C. Moreover, for high performance, TPC-E needs to perform lookups and scans through

non-primary indexes in almost all its transactions (ten out of twelve), whereas TPC-C uses secondary indexes in only two of its transactions.

Overall, TPC-E is a much more sophisticated OLTP benchmark compared to its predecessors and therefore, it offers a more interesting and mature environment for testing OLTP engines. On the other hand, it is also harder to adopt for people from both industry and academia, which have been optimizing their systems mainly based on TPC-C for the last twenty years.

Table 2.2: Evolution of TPC’s OLTP benchmarks.

TPC-A TPC-B TPC-C TPC-E

First release Nov 1989 Aug 1990 Aug 1992 Feb 2007 Last update Jun 1994 Jun 1994 Feb 2010 Apr 2014 Business model Banking Banking Wholesale supplier Brokerage house

Tables Fixed 0 0 1 9 Scaling 3 3 4 16 Growing 1 1 4 8 Total 4 4 9 33 Transactions RW 1 1 3 6 RO 0 0 2 6 Transaction RW 100% 100% 92% 23.1% Mix % RO 0% 0% 8% 76.9% Transactions using None None 2 10 secondary indexes

Data population Random Random Random Pseudo-real