Citywide smart-meter history no longer fits or processes in time on one powerful server. What is the core rationale for moving to cluster computing?
Select an answer to reveal the explanation.
Short Explanation
When one beefy box runs out of room and clock, polishing that single machine stops helping. Line up many workers that share the load instead.
Full Explanation
When citywide smart-meter history no longer fits or processes in time on one powerful server, the core rationale for cluster computing is scale-out: capacity and parallelism across many machines beyond a single server’s CPU, memory, and disk limits. Municipal Big Data problems are often too large or too slow for vertical scaling alone, even when that one box is expensive and well tuned by vendors. Clusters do not exist only to make slide decks look more technical to council; they solve concrete capacity and runtime limits for utilities analytics that residents ultimately fund. A cluster never replaces the need for data models or quality checks—distributed compute still requires trustworthy, well-modeled meter inputs before parallelism helps. One large server does not automatically shard files without a distributed framework; buying a bigger box is scale-up, not scale-out, and eventually hits a hard ceiling. Exam caveat: horizontal scale and parallelism are the conceptual drivers on the exam, not Hadoop used as an empty buzzword in a budget narrative. Operational check: measure single-node job wall time and storage headroom on meter archives, compare projected growth for the next budget cycle, justify cluster adoption with capacity and parallelism metrics in the architecture brief to utilities leadership, and revisit those metrics after the first production season.