배경

1000만개의 Product 데이터를 DB에 업로드하는 상황이었습니다. 대용량의 데이터였기에, 성능 등의 여러 이슈에 대해서 고려하였고, 다음 문제에 대해서 고민하게 되었습니다.

• DB insert 성능을 어떻게 확보할 것인가
• 어떻게 하면 사람의 개입을 최소화할 수 있을까
• insert 도중 실패에 어떻게 대처할 것인가

요약

• Batch Insert 선택
  • Bulk Load의 문제 : 파일 변환, FK 분할, 불확실한 데이터 구조 등 전처리 비용이 너무 큼
  • 속도를 포기하고 유연성 우선하여 4가지 방법으로 속도를 보완
• Streaming 파이프라인 구축
  • 로컬 저장의 문제 : 수백 GB 데이터를 담을 디스크 공간이 없음
  • 다운로드·압축해제·적재를 하나의 흐름으로 연결,
  • Streaming의 한계 : 네트워크가 끊기면 해당 파일을 처음부터 다시 받아야 함
  • 근본적 해결보다 자동 재시도로 우회 → 사람 개입 최소화
• 실패는 중단 없이 기록으로 처리
  • 중단 시, 문제 : 파일 하나에 수백만 건이라, 실패로 멈추면 처음부터 다시 읽어야 함
  • 실패한 batch는 파일로 저장하고 계속 진행한 뒤, 나중에 원인 분석 후 별도 재시도

문제 상황

DB Batch Insert 방식을 선택한 이유

🔍 Bulk Load가 어려웠던 이유

빠른 업로드를 위해 DB의 **bulk load**를 고려하였습니다. bulk load가 데이터를 모두 write한 후에 인덱스를 생성하고, Log 작성도 최소화 하기에 속도가 빠르기 때문입니다.

하지만 다음과 같은 이유로 작업 속도는 오히려 늦어질 수 있다고 생각했습니다.

1️⃣ JSONL 파일을 csv 로 변환