This paper from 2008 provides an instruction-level breakdown of the performance impact of each major component of a OLTP database, running a subset of TPC-C.
Since the invention of transactional databases in the 1970s and 1980s, a few things have changes:
- Hardware improvements. CPUs are faster so that each transaction now only takes a few microseconds to complete. Memory is getting cheaper so that most OLTP databases fit in memory.
- Modern internet applications and data intensive applications no long require full standard database features, and can live with varying levels of consistency, reliability, concurrency, replication and query-ability.
Some alternative database designs are now worth considering, such log-less databases, single-threaded databases, and transaction-less databases.
The authors started with a system called Shore, and progressively striped down each of the following components of it, to identify the overhead of each one. The benchmark they run were NewOrder and Payment transactions from TPC-C.
- Logging
- Locking
- Latching
- Buffer management
The detailed instruction count breakdown was given by figure 5 and figure 6 of the paper.
Buffer management and locking operations are the most significant contributors to performance overhead, followed by logging and latching operations.
The authors concluded that unless one strips down all of these components, it is hard to get a main-memory optimized database that performs much better than a traditional database where most data fits into RAM. But if one does strip down all of the components, i.e, to design a single-threaded, in-memory, transaction-less databases that uses copy-state-over-network recovery, the performance will be orders of magnitude better than the system one starts with.
Write Behind Log 