Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases
Alexandre Verbitski, Anurag Gupta, Debanjan Saha, et al.2017SIGMOD 2017
Read it on doi.org(opens in a new tab)Why this one
Read this after The Log-Structured Merge-Tree and Spanner. Aurora is the cleanest example of a cloud database design where the useful boundary is not SQL versus NoSQL, but compute versus storage. The trick is to stop shipping pages around and ship redo records to a storage fleet that knows enough database semantics to repair, replicate, and serve pages. People often remember Aurora as "MySQL, but managed". That misses the paper. The important move is architectural: once storage is remote, replicated, and programmable, the old buffer pool, WAL, checkpoint, and recovery design can be rearranged around network cost and failure domains. If you build services that persist state, this is worth your evening because it shows how a familiar API can sit on top of a very different machine.
What to take away
- Aurora sends redo log records to storage nodes instead of forcing the database engine to write full data pages.
- Quorum reads and writes are tuned for six storage replicas across three availability zones.
- Recovery gets faster because storage continuously materializes pages from logs instead of waiting for database crash replay.
Reads with
- The Log-Structured Merge-Tree (LSM-Tree)
aurora's redo-only storage path is easier to see after log-structured write design
- Spanner: Google's Globally-Distributed Database
aurora is the cloud-storage split answer to spanner's globally synchronized database
- Bigtable: A Distributed Storage System for Structured Data
shows the earlier move of pushing database structure into a distributed storage service