LayoutBench: 멀티미디어 데이터에 대한 클라우드 스토리지 레이아웃 성능 벤치마킹

LayoutBench: Performance Benchmarking of Cloud Storage Layouts for Multimedia Data

최신 멀티미디어 머신러닝 워크로드에서 대규모 데이터셋은 AWS S3와 같은 클라우드 객체 스토리지 서비스에 저장되는 경우가 많습니다. 이러한 샘플들이 물리적으로 어떻게 구성되느냐(즉, 스토리지 레이아웃)는 데이터를 얼마나 빠르고 저렴하게 검색할 수 있는지에 직접적인 영향을 미칩니다. 그러나 현재 스토리지 의사 결정을 안내하는 벤치마크는 주로 데이터베이스 엔진 및 쿼리 처리에 초점을 맞추고 있으며, 멀티미디어 데이터 검색에 대한 다양한 스토리지 레이아웃의 성능을 체계적으로 평가하는 것은 없습니다. 본 논문에서는 이러한 격차를 해소하기 위해 설계된 최초의 벤치마크인 LayoutBench를 제시합니다. LayoutBench는 세 가지 대표적인 레이아웃 전략을 평가합니다. 첫 번째 전략(L1)은 각 샘플을 개별 객체로 저장하고, 두 번째 전략(L2)은 샘플들을 순차적으로 tar 아카이브에 패킹하며, 세 번째 전략(L3)은 샘플들을 Parquet 파일의 열 단위로 구성합니다. ImageNet 데이터셋에 대해 11개의 다양한 결과 집합 크기의 쿼리를 사용하여 여섯 가지 AWS EC2 인스턴스 구성에서 검색 시간, 전송된 데이터 양 및 비용을 측정했습니다. 실험 결과, L2는 연결 재사용을 통해 L1 및 L3보다 낮은 지연 시간을 달성하지만, 검색 크기가 매우 커지면 이러한 장점을 잃게 됩니다. L3는 매우 큰 검색 작업에서 가장 빠르지만, 행 그룹(row-group) granularity로 인해 모든 쿼리 크기에서 훨씬 더 많은 데이터를 전송해야 하며, 상당한 양의 메모리가 필요합니다. 모든 레이아웃에서 데이터 전송 비용이 총 비용의 대부분을 차지하며, L3는 L1 또는 L2보다 수 배 더 높은 비용이 발생합니다.

Modern multimedia machine learning workloads increasingly store large-scale datasets in cloud object storage services such as AWS S3. How these samples are physically organized in storage (i.e.,storage layout) directly affects how quickly and cheaply they can be retrieved. Yet the benchmarks used to guide storage decisions today focus on database engines and query processing, and none systematically evaluates how different storage layouts perform for multimedia data retrieval. We present LayoutBench, the first benchmark designed to fill this gap. It evaluates three representative layout strategies: storing each sample as an individual object (L1), sequentially packing samples into tar archives (L2), and organizing samples as columns in Parquet files (L3). We measure retrieval time, data transferred, and monetary cost using 11 queries of varying result-set sizes on ImageNet across six AWS EC2 instance configurations that span different network bandwidth and memory tiers. Our experiments reveal that L2 achieves lower latency than L1 and L3 through connection reuse, but loses this advantage as retrieval sizes become very large. L3 is the fastest for very large retrievals but transfers substantially more data across all query sizes due to row-group granularity, and requires significantly more memory. Across all layouts, data transfer cost dominates total expenditure, with L3 costing an order of magnitude more than L1 or L2.