Data Storage and Operations
Data Storage and Operations covers the physical and operational side: choosing storage engines, designing for recovery, and running databases reliably. The exam tests trade-offs such as row versus columnar, indexing, partitioning, and backup and recovery objectives, and whether you can reason from a stated requirement to a defensible design.
Core rules and concepts
- Row-oriented stores suit transactional writes and single-record lookups; columnar stores suit scans and aggregation over few columns. Neither is universally better; mixed workloads often use both.
- ACID (atomicity, consistency, isolation, durability) protects transactions; BASE trades immediate consistency for availability. Isolation levels control dirty reads, non-repeatable reads, and phantoms.
- Indexes speed reads and slow writes; index selective predicates used in filters and joins, and watch for unused or duplicate indexes.
- Partitioning and sharding: partitioning splits within a database, often by date range, for pruning and maintenance; sharding distributes across nodes and complicates cross-shard joins.
- Recovery objectives: RPO is the acceptable data loss window, RTO is the acceptable downtime. Backups, log shipping, and replicas are chosen to meet both. RAID protects against disk failure, not against deletion or corruption.
- Lifecycle: classify data, tier it (hot, warm, archive), and apply retention and deletion so that operations and privacy obligations agree.
Worked example
A regulated system must lose no more than five minutes of committed transactions and be running again within one hour. Reasoning: an RPO of five minutes rules out nightly full backups alone; it requires continuous transaction log archiving or synchronous replication to a second site. An RTO of one hour rules out restoring a multi-terabyte full backup from tape; it points to a warm standby with automated failover, or snapshots plus log replay that are timed and rehearsed. RAID is assumed but never counted as the recovery plan. Document the tested restore time, not the theoretical one.
Traps that cost marks
- Confusing RPO with RTO, or quoting a backup schedule as a recovery objective.
- Treating RAID or replication as a backup; both propagate deletions.
- Putting a columnar engine under heavy single-row OLTP updates.
- Indexing every column and then blaming the write path.
- Sharding early, before partitioning and query tuning are exhausted.