Cadence telemetry from dozens of civic routers produces timestamped counter samples. Which storage consideration fits model-driven telemetry consumption?
Select an answer to reveal the explanation.
Short Explanation
Telemetry is a heartbeat log, not a novel you keep every draft of forever. A time-aware store with retention matches cadence measurements; an endless flat file just piles up.
Full Explanation
Cadence telemetry produces time-stamped samples that are naturally queried by time range. For counters from dozens of civic routers, use a time-series or similarly time-aware store with an explicit retention policy so graphs, rollups, and disk use stay manageable. Retention is part of consumption design, not an afterthought once flash fills.
Appending every publication forever to an unbounded flat file with no retention plan fails capacity and query performance. Storing each sample only in router NVRAM so collectors never need a database fails scale and durability for fleet-wide analytics. Keeping telemetry exclusively in a relational row-store never queried by time range fights the access pattern—though SQL can work if time indexing and retention are deliberate, the exam favors time-aware storage thinking.
Exam caveat: down-sampling older data pairs with retention; raw high-cadence samples rarely need infinite precision forever. Separate hot and cold tiers if municipal compliance requires longer audit keeps.
Operational check: configure retention (for example 15 days raw, 180 days down-sampled), load a day of cadence data, and confirm queries by time window remain fast while disk growth flattens after the retention horizon.