Unbundling Transaction Services in the Cloud

TL;DR

This paper proposes a modular architecture for DBMS engines by separating logical transaction management from physical data storage, facilitating flexible deployment and better hardware utilization, especially in cloud environments.

Contribution

It introduces a two-layer unbundled architecture with distinct Transactional and Data Components, enabling flexible, application-specific physical structures and improved multi-core performance.

Findings

Supports atomic record operations via system transactions

Enables multi-level redo mechanisms

Facilitates deployment of application-specific physical structures

Abstract

The traditional architecture for a DBMS engine has the recovery, concurrency control and access method code tightly bound together in a storage engine for records. We propose a different approach, where the storage engine is factored into two layers (each of which might have multiple heterogeneous instances). A Transactional Component (TC) works at a logical level only: it knows about transactions and their "logical" concurrency control and undo/redo recovery, but it does not know about page layout, B-trees etc. A Data Component (DC) knows about the physical storage structure. It supports a record oriented interface that provides atomic operations, but it does not know about transactions. Providing atomic record operations may itself involve DC-local concurrency control and recovery, which can be implemented using system transactions. The interaction of the mechanisms in TC and DC leads to multi-level redo (unlike the repeat history paradigm for redo in integrated engines). This refactoring of the system architecture could allow easier deployment of application-specific physical structures and may also be helpful to exploit multi-core hardware. Particularly promising is its potential to enable flexible transactions in cloud database deployments. We describe the necessary principles for unbundled recovery, and discuss implementation issues.