Disaggregated Cloud Database Architectures: Decoupling Compute and Storage
This article discusses the architectural shift towards disaggregated cloud databases, emphasizing the decoupling of compute and storage due to economic and operational drivers. It explores how this disaggregation enables elastic scaling, cost efficiency, and improved fault isolation, contrasting it with traditional monolithic and replicated database architectures. The presentation highlights key implementations like Amazon Aurora and Alibaba PolarDB, focusing on their approaches to log replication and state materialization over a network-centric design.
Read original on InfoQ ArchitectureThe presentation, "Parting the Clouds: The Rise of Disaggregated Systems," explores the fundamental shift in cloud database architectures from monolithic systems to disaggregated designs. This change is primarily driven by cloud economics, specifically the inherent impedance mismatch between compute and storage resources. Compute is often costly and fluctuates rapidly in demand, while storage is cheaper and more stable. Tightly coupling them leads to inefficiencies, forcing users to overprovision one resource when they only need more of the other.
Benefits of Disaggregated Architectures
- Elastic Scalability: Compute can scale independently to zero, providing true pay-per-use models. This includes both vertical scaling (better boxes for latency) and horizontal scaling (more bandwidth via sharding).
- Cost Efficiency: Achieved through I/O pooling at the storage tier (multi-tenant storage) and optimized resource allocation.
- Fault Isolation: A compute node crash does not entail storage loss, simplifying recovery and making compute nodes easy to stand up over shared storage.
- Simplified Operations: Databases transform from heavy, stateful boxes into lightweight, elastic services running on shared storage.
Architectural Evolution of Databases
Database architectures have evolved through three main phases:
- Monolithic: Traditional databases (e.g., PostgreSQL, MySQL) where compute and storage are tightly coupled within a single process and disk.
- Replicated (Cloud 1.0): To address availability and durability in the cloud, monolithic databases were often wrapped with replication protocols like Paxos or Raft. While improving resilience, this approach often led to over-replication of data (e.g., 3x database replication on top of 3x cloud storage replication) and didn't solve the compute-storage coupling problem.
- Disaggregated: The modern approach, where ephemeral compute is decoupled from shared storage. Storage itself can be further disaggregated into Log Stores and Page Stores. This allows for independent scaling and optimized resource use.
Key Innovation: Network as the New Backplane
The advent of high-speed networks (hundreds of Gbps, RDMA, SmartNICs, CXL) has been critical, allowing the network to replace local I/O. The data center is conceptualized as a giant computer, with the network serving as its backplane. This shift dictates many design decisions in disaggregated systems, especially regarding minimizing network traversals.