OLTP through the looking glass, and what we found there

By Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, M. Stonebraker. SIGMOD Conference, 2008

379 citations recorded by the source corpus.

Online Transaction Processing (OLTP) databases include a suite of features - disk-resident B-trees and heap files, locking-based concurrency control, support for multi-threading - that were optimized for computer technology of the late 1970's. Advances in modern processors, memories, and networks mean that today's computers are vastly different from those of 30 years ago, such that many OLTP databases will now fit in main memory, and most OLTP transactions can be processed in milliseconds or less. Yet database architecture has changed little. Based on this observation, we look at some interesting variants of conventional database systems that one might build that exploit recent hardware trends, and speculate on their performance through a detailed instruction-level breakdown of the major components involved in a transaction processing database system (Shore) running a subset of TPC-C. Rather than simply profiling Shore, we progressively modified it so that after every feature removal or optimization, we had a (faster) working system that fully ran our workload. Overall, we identify overheads and optimizations that explain a total difference of about a factor of 20x in raw performance. We also show that there is no single "high pole in the tent" in modern (memory resident) database systems, but that substantial time is spent in logging, latching, locking, B-tree, and buffer management operations.

Subfields: Computer Networks and Communications

View Paper: https://www.semanticscholar.org/paper/77122f978b45e0644ab6a8cbed0750558752b13f

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Computer Networks and Communications

Citations in the corpus

Skew-aware automatic database partitioning in shared-nothing, parallel OLTP systems (2012, methodology): “Given these requirements, our cost model is predicated on the key observation that the execution overhead of a multi-partition transaction is signiﬁcantly more than a single-partition transaction [43, 24].”
In-Memory Big Data Management and Processing: A Survey (2015, background): “However, there has been a surge in interests in recent years [222].”
HyPer: A hybrid OLTP&OLAP main memory database system based on virtual memory snapshots (2011, methodology): “Therefore, we can rely on a single-threading approach first advocated in [5] whereby all OLTP transactions are executed sequentially.”