An analytics team runs queries that scan billions of rows of sales history, but each query reads only three or four of the table's 120 columns to compute totals. Which storage model reduces the disk I/O for this workload the most?
Select an answer to reveal the explanation.
Short Explanation
If you only need four columns out of 120, why read the other 116? Column-oriented storage keeps each column together, so your query touches just what it uses and compresses beautifully too. The trap is row storage: great for grabbing a whole record, wasteful for scanning a few columns.
Full Explanation
Column-oriented databases physically store all values of a column contiguously instead of storing each row's values together. An aggregate such as SUM(amount) grouped by region therefore reads only the amount and region column segments and skips the remaining columns entirely, which on a 120-column table eliminates most of the I/O. Values within a column share a data type and often repeat, so columnar formats compress very well, further reducing the bytes read. This is why analytical (OLAP) engines and data warehouses favor columnar storage. Row-oriented storage is efficient for transactional work that inserts or reads whole records, but a scan that needs four columns still drags every column of every row through the disk and memory path. A key-value store is built for retrieving a single value by an exact key; it offers no efficient way to aggregate billions of values across a few attributes. A graph database optimizes multi-hop relationship traversal, which is not the access pattern of large aggregate scans. Exam caveat: columnar storage is weaker for frequent single-row updates, so it suits analytics rather than high-volume OLTP writes. Operational check: run the same aggregate against row and columnar copies of the table and compare bytes scanned and elapsed time in the execution statistics.