A retail chain stores years of item sales in one wide table, and analysts usually request only store, date, and revenue. The platform team wants a layout that reads those fields without walking every field of every row the way a plain text table does. Which layout matches that need?
Select an answer to reveal the explanation.
Short Explanation
Picture a warehouse where each fact has its own aisle, so you can walk the revenue aisle and leave the others alone. A columnar layout stores each field that way and reads only the columns you named. The trap is a plain text row, which still drags every unused field past you.
Full Explanation
Columnar storage lays each field down as its own contiguous run, so a scan for store, date, and revenue touches only those three runs and leaves the rest of a wide sales row unread. That is the layout that matches a narrow analytic query over a tall retail table. A row-oriented text table stores every field of a sale on one line, so selecting three fields still forces the reader to walk the whole line and discard the unused pieces. A nested document keeps the entire sale inside a single record, and opening that record brings fields the query never named. A key-value payload is fetched as one value, so asking for revenue still returns the whole sale rather than a field run. The practical boundary is workload shape: a job that needs most fields of each row gains little from a columnar arrangement and can pay a cost to reassemble the row. Exam caveat: columnar organization is about which values sit together, not about whether the file is compressed, and compression can sit on either a row layout or a column layout. Operational check: review the scan for a store-date-revenue request and confirm the bytes read correspond to those three fields rather than the full width of every sale.