Architectures
0-day streakReview

Your progress

Level 1

0 XP100 XP to level 2
0day streak
0best streak
0topics started
0cards reviewed
    Review cards

    Progress is stored only in this browser. No account is required.

    Database architectures: the 60-second story

    Database architectures

    A thali kitchen runs like a database server.

    The host takes orders, a manager admits them, the head cook plans, line cooks cook, and every order is written down first.

    Follow one query: every hop is a place a limit appears

    Too many connections strain the front door. A bad plan is the optimiser’s. Memory, hot locks and log flushes are storage’s.

    Does every app need a database server?

    Bad: Always run a server

    One more thing to patch and fail over.

    Good: SQLite competes with fopen()

    A library, one file, no network hop. One writer at a time.

    Many machines: what do they share?

    Shared memory is one big box. Shared disk must sync locks and caches between nodes. Shared nothing partitions the data; only cross-partition work coordinates.

    Shared nothing needs two-phase commit when a transaction spans nodes. Why bet on it?

    Stonebraker, 1986

    Partition well and most transactions touch one node. He estimated 85% of TP1’s transactions did, and called that “delightful”.

    Aurora: the log is the database

    Only redo records cross the network; storage builds the pages. Six copies in three zones, and a write needs four.

    Aurora’s writer and readers share one volume. Isn’t that shared disk, with its lock traffic?

    Shared disk, reinvented

    Only one node writes, so there is nothing to coordinate. The price: still one writer.

    Three walls push you off one primary

    1. Writes: assume 0.5 ms each, ≈ 38,000/s on 32 vCPUs
    2. Restore: 10 TB at 500 MB/s takes 5.6 hours
    3. Geography: Mumbai to Frankfurt costs ≥ 66 ms per write

    Remember

    Start with one primary and replicas. Move up only when writes, restore time or geography force you.