웹페이지 크롤링 결과는 어떻게 저장하는 게 좋은가

웹페이지 크롤링 결과는 어떻게 저장하는 게 좋은가

Scope

핵심 질문

웹 크롤링 결과를 장기 보존·재처리·검색·분석까지 고려해 어떤 계층으로 저장하는 것이 좋은가?

Research

핵심 근거

• 원본 HTML과 추출된 구조화 데이터를 분리하면 재파싱과 분석을 각각 최적화할 수 있다.
• URL, crawl timestamp, status, content hash 같은 metadata는 DB에 두면 증분 갱신과 중복제거가 쉽다.
• 분석용 대량 데이터는 Parquet 같은 columnar format이 유리하고 원문은 object/file storage가 단순하다.

참고 자료

• Apache Parquet: https://parquet.apache.org/

Draft

크롤링 결과는 하나의 저장 형식에 모두 넣기보다 원문, 상태, 분석용 데이터를 분리하는 편이 좋다.

원문

HTML 원문은 나중에 parser를 바꾸거나 추출 오류를 검증할 때 필요하다. 압축 파일이나 object storage에 저장하고 URL과 시각을 metadata로 연결하는 방식이 단순하다.

상태와 Metadata

URL, 마지막 성공 시각, HTTP status, ETag, content hash, retry 상태는 DB나 KV store에 두는 것이 좋다. 이 값은 자주 조회·수정되기 때문이다.

구조화 데이터

제목, 본문, 작성일처럼 추출된 데이터는 검색이나 분석 목적에 맞게 별도로 저장한다. 수백만 건을 SQL·DuckDB·Spark로 분석한다면 Parquet가 효율적이다.

검색

전문검색이 필요하면 검색엔진이나 FTS index를 별도로 구축한다. 원본 storage를 직접 검색 시스템으로 쓰는 것은 비효율적이다.

권장 구조

작은 시스템이라도 원문 storage + metadata DB + 필요 시 Parquet snapshot 정도로 나누면 확장하기 쉽다. 저장 형식은 데이터 종류보다 접근패턴을 기준으로 선택해야 한다.