한 페이지당 한 파일 저장은 왜 문제가 되는가

한 페이지당 한 파일 저장은 왜 문제가 되는가

Scope

핵심 질문

크롤링에서 페이지마다 작은 파일 하나를 만드는 방식은 언제 병목이 되고 대안은 무엇인가?

Research

핵심 근거

• 수백만 개의 작은 파일은 inode, directory listing, metadata backup/sync 비용을 크게 만든다.
• 개별 파일은 단순하고 손상 격리가 좋지만 대량 scan과 압축효율은 낮을 수 있다.
• archive/container, object storage, Parquet, DB 등으로 묶는 방식은 접근패턴에 따라 대안이 된다.

참고 자료

• 일반적인 분산시스템·데이터 엔지니어링 설계 원칙

Draft

한 페이지당 한 파일은 가장 이해하기 쉽고 디버깅하기 쉬운 저장 방식이다. 문제는 파일 수가 데이터 크기보다 더 빨리 운영비용을 키울 수 있다는 점이다.

Metadata 비용

파일 하나를 읽기 위해 filesystem은 inode와 directory metadata를 처리한다. 작은 파일 수백만 개를 list, backup, rsync하면 실제 payload보다 metadata operation이 병목이 되기 쉽다.

압축과 Scan

HTML 수천 개를 각각 압축하는 것보다 여러 문서를 큰 archive나 columnar file로 묶는 편이 압축률과 순차 읽기 효율이 좋다.

장점도 있다

개별 파일은 특정 URL 결과를 바로 열기 쉽고 한 파일 손상이 다른 문서로 퍼지지 않는다. 작은 규모에서는 가장 합리적인 방식일 수 있다.

대안

원문을 날짜별 archive로 묶거나 object storage에 저장하고 metadata DB로 위치를 찾을 수 있다. 분석용 추출 결과는 Parquet처럼 큰 파일 단위로 묶을 수 있다.

핵심

파일 수가 수천~수만 수준이면 단순 파일 구조도 충분하다. 수백만 개로 커질 가능성이 있다면 초기에 원문 storage와 index를 분리해두는 편이 좋다.