Why would the city store multi-terabyte camera index archives on HDFS rather than relying on a conventional NAS share alone?
Select an answer to reveal the explanation.
Short Explanation
Giant camera indexes want a filesystem that spreads blocks, survives node loss, and sits next to cluster compute. That is HDFS’s job description.
Full Explanation
Multi-terabyte camera index archives belong on HDFS rather than a conventional NAS share alone because HDFS is built for large-scale, fault-tolerant distributed storage that pairs with parallel cluster processing—co-locating big analytical data with Big Data compute for municipal public-safety and traffic workloads. NAS can share office files, but it is not the same distributed compute filesystem model for multi-terabyte analytical scans. HDFS is not intended only to host tiny configuration files under one megabyte. NAS shares do not automatically run MapReduce without a distributed filesystem and processing framework sitting beside the data. HDFS does not forbid replication; claiming it needs less planning than NAS because it forbids replication is factually wrong and dangerous for civic archives. Exam caveat: the HDFS value proposition is scale, fault tolerance, and compute locality for analytics—not generic departmental file sharing. Operational check: place camera index archives on HDFS with appropriate replication, run a sample distributed scan, compare job locality and failure behavior against NAS-only access, and capture the comparison in the architecture review with public-safety IT.