11.8: Detailed Captions - Chapter 11

Overview

• Chapter: 11 — Data Management in the Cloud
• Total Figures Proposed: 8
• Figure Types Used: Comparison Table, Architecture Diagram, Conceptual Illustration, Flowchart, Network Diagram, Infographic

Figure 11.1.1

Title: Cloud Storage Models Comparison — Block, File, and Object Storage

Detailed Caption: Three columns sit side by side beneath navy header pills — Block Storage, File Storage, and Object Storage. The left panel shows a vertical stack of four uniformly sized teal "Block 1–4" tiles annotated "Fixed-size chunks, no metadata," with a downward teal arrow into a small disk-pack icon labeled in gold "Low-latency, random I/O · VMs, Databases." The middle panel renders a hierarchical tree rooted at a gold "/ root" folder branching to "/docs" and "/imgs" subfolders, each holding leaf files (a.txt, b.txt, 1.png, 2.png), captioned "Hierarchical directories" and "Shared access via NFS/SMB · Home dirs, shared content." The right panel arrays four mint cylinders for objects (photo.jpg, log.csv, backup.tar, data.json), each tagged with a gold "meta" sticker, beneath the labels "Flat namespace, rich metadata" and "API access (HTTP), massive scale · Media, backups, data lakes." Footer pills below each column anchor the model to real services — AWS EBS · Azure Managed Disks; Amazon EFS · Azure Files; Amazon S3 · Azure Blob Storage. By visualizing the underlying data structure of each model, the figure makes the trade-offs concrete: block is for fast random I/O behind a single mount, file is for shared hierarchies and POSIX semantics, object is for unbounded scale with rich metadata.

Figure 11.2.1

Title: HDFS Architecture — NameNode and DataNode Interaction

Detailed Caption: A wide navy "NameNode (Metadata Server)" banner across the top — subtitled "File namespace · Block locations · Permissions" with the italic note "Manages metadata, does not store data" — sends dashed lines down to three teal "DataNode" tiles arrayed across the bottom. Each DataNode contains three colored block tiles in coral, blue, and green for Block A, Block B, and Block C, with the placement engineered so each block appears in exactly three different DataNodes (3× replication), and a gold-bordered "Replication (3x)" legend on the right confirms the assignment. A computer Client icon on the upper-left fires three numbered, color-coded arrows: a gold "1. Request file metadata" upward to the NameNode, a gold "2. Return block locations" back to the Client, and a teal "3. Read/Write blocks directly" diagonal arrow into the DataNodes; small gray dashed lines back to the NameNode are labeled "Heartbeat / Block Report." The figure makes the HDFS scaling trick visible at a glance: metadata travels through the master, but bulk data flows directly between client and DataNode, which is what lets a single NameNode supervise petabytes without becoming the throughput bottleneck.

Figure 11.3.1

Title: SQL vs. NoSQL vs. NewSQL — Feature Comparison Matrix

Detailed Caption: A four-column matrix runs beneath three navy header pills (SQL (Relational), NoSQL, NewSQL) with a teal "Dimension" sidebar listing six rows on the left: Data Model, Schema, Scalability, Consistency, Query Language, and Examples. Each cell distills the comparison into one or two phrases: SQL pairs Tables/Rows/Columns with Fixed schema, Vertical scaling, ACID/Strong consistency, SQL query language, and Amazon RDS / Aurora / Cloud SQL; NoSQL pairs Key-value/Document/Wide-column/Graph models with Flexible/Schema-less, Horizontal scaling, Eventual (tunable) consistency, varying query languages, and DynamoDB / Cosmos DB / Cassandra; NewSQL pairs distributed Tables/Rows with Fixed schema, Horizontal scaling, ACID/Strong (distributed) consistency highlighted in a gold callout, SQL, and Google Spanner / CockroachDB / VoltDB. Alternating row shading aids horizontal scanning, and the gold highlight on NewSQL's Consistency cell singles out the category's defining differentiator. The matrix collapses pages of comparison into a one-page reference and surfaces the practical decision: SQL for predictable structure, NoSQL for flexibility and scale, NewSQL when both relational guarantees and horizontal scale are non-negotiable.

Figure 11.3.2

Title: NoSQL Database Types and Their Data Models

Detailed Caption: A 2×2 grid of four panels, each topped by a navy header pill, shows one NoSQL data model per quadrant with a representative visual. The Key-Value Store (top-left) renders a two-column table with concrete keys (user:101, session:42, cart:789) paired with opaque "{blob data}" values, anchored by the gold caption "DynamoDB, Redis · Simple lookup by unique key." The Document Store (top-right) shows two JSON-like document boxes with nested fields ("name", "address.city", "orders[]"), labeled "MongoDB, Cosmos DB · Nested JSON/BSON documents." The Wide-Column Store (bottom-left) renders a sparse grid where each user row populates a different mix of Name/Email/Phone/Age/City columns, captioned "Cassandra, Bigtable · Sparse columns — rows can have different columns." The Graph Database (bottom-right) shows four labeled nodes (Alice, Bob — both "Person"; Laptop, Phone — both "Product") connected by gold-labeled directional edges (KNOWS, PURCHASED, SIMILAR_TO), captioned "Neo4j, Neptune." By visualizing the actual data shape each engine stores, the figure replaces vocabulary with intuition — students can see why a graph DB is the natural choice for relationship queries that would force ugly joins on a relational store.

Figure 11.4.1

Title: Data Replication Strategies — Single-Leader, Multi-Leader, and Quorum

Detailed Caption: Three vertical panels under navy header pills — Single-Leader, Multi-Leader, and Quorum (W+R > N) — visualize the three strategies. The left panel shows a Client sending a gold "Write" arrow to a single "Leader (Primary)" node and a teal "Read" arrow to "Follower 1," with dashed gray "Replicate" arrows fanning from the Leader down to two Followers, captioned "Writes go to leader only. Followers serve reads." The middle panel arranges three Leader nodes (A, B, C) in a triangle with bidirectional dashed "Sync / Conflict Resolution" lines between every pair and gold "Write" arrows from two separate Clients into Leaders A and B, captioned "All nodes accept writes. Conflicts resolved async." The right panel arrays five teal nodes (N1–N5) with gold downward "W = 3 (write to 3 nodes)" arrows hitting N1–N3, an "Overlap: N2, N3" pill, and teal "R = 3 (read from 3 nodes)" arrows hitting N2–N4; a gold-bordered footnote reads "W + R > N ensures at least one node has the latest write" with the example "N=5, W=3, R=3, 3+3=6>5 (guaranteed overlap)." The side-by-side framing lets students compare consistency and write-availability trade-offs directly: single-leader is simple but bottlenecks on one writer, multi-leader maximizes write availability but inherits conflict resolution work, and quorum offers tunable consistency at the cost of arithmetic discipline.

Figure 11.4.2

Title: The CAP Theorem — Trade-offs in Distributed Systems

Detailed Caption: A large triangle dominates the figure with three navy vertex pills — Consistency (C) at the top, Availability (A) at the bottom-left, and Partition Tolerance (P) at the bottom-right. A teal "CP" callout near the top-left edge attaches a "CP Systems" card listing MongoDB (strict mode), Redis Cluster, HBase, and Google Spanner, while a warm-gold "AP" pill near the bottom edge attaches an "AP Systems" card naming Cassandra, DynamoDB, CouchDB, and DNS. A dashed-bordered card up by the C–P edge labeled "CA — Impractical in distributed systems (network partitions always possible)" signals that the third overlap is theoretical only, and a centered banner inside the triangle reads "During a network partition, a system must choose between C and A." By mapping real cloud datastores onto specific edges of the theorem, the figure transforms an abstract impossibility result into a working compass for choosing a database — students can read off what each system gave up to get the other two guarantees, and reason about which trade-off fits their workload.

Figure 11.5.1

Title: Cloud Backup and Recovery Strategy — The 3-2-1 Rule in Practice

Detailed Caption: Three color-coded badge headers across the top — navy "3 Copies," teal "2 Storage Types," and gold "1 Off-site" — sit above three matching tier cards. The leftmost navy "Copy 1 — Production" card holds a Primary DB cylinder labeled "Live production database, Region A"; a teal "Nightly" arrow runs right into the middle teal "Copy 2 — Snapshots" card containing an object-storage tile labeled "Object Storage (S3 Standard), Same Region A"; and a gold "Weekly" arrow continues right into the gold "Copy 3 — Off-site Archive" card labeled "S3 Glacier / Cross-Region, Region B (Off-site)." A retention timeline strip beneath all three cards reads "Daily snapshots: 7 days → Weekly snapshots: 4 weeks → Monthly snapshots: 12 months → Archive tier: long-term," and three small footer rationale tiles map each rule to its purpose — Data Resilience (protects against hardware failure, corruption, deletion), Media Diversity (different storage types reduce correlated failures), and Geographic Separation (off-site copy survives regional disasters). The figure operationalizes the 3-2-1 rule by binding each numerical requirement to a concrete cloud service and a defended failure mode, turning a memorable mantra into a defensible architecture.

Figure 11.6.1

Title: Name Services and Metadata Management in Cloud Distributed Systems

Detailed Caption: A "Client / Application" tile at the top emits two parallel labeled arrows — a navy "Lookup service address" arrow into a navy-bordered "Name / Discovery Service" panel on the left, and a teal "Query file/data location" arrow into a teal-bordered "Metadata Service" panel on the right. The Name panel contains three navy sub-tiles for DNS (Route 53), Service Registry (Consul / Cloud Map), and Coordination Service (ZooKeeper / etcd) with the footer "Resolves service names to network addresses," while the Metadata panel contains three teal sub-tiles for NameNode (HDFS), MDS (CephFS), and Data Catalog (AWS Glue) with the footer "Maps file/data names to physical block locations." Below each panel, downstream arrows flow into a row of gray endpoint tiles — Microservice A and Microservice B on the left ("Route to service") and DataNode 1, 2, and 3 on the right ("Direct client to data blocks") — and a gold-bordered callout at the bottom reads "Both layers must be highly available — Replicated with consensus protocols (Raft / Paxos)." The figure unifies two often-confused concepts on one canvas: the Name layer turns logical names into addresses for services, while the Metadata layer turns logical names into block locations for data, and both must be HA because every other operation depends on them.