피드로 돌아가기
Product Tree Denormalization in Side Projects: Is It Really Necessary?
Dev.toDev.to
Database

데이터 규모와 트래픽에 근거한 Product Tree Denormalization 최적 시점 판단

Product Tree Denormalization in Side Projects: Is It Really Necessary?

Mustafa ERBAY2026년 6월 3일9intermediate

Context

계층 구조를 가진 Product Tree 데이터 모델에서 깊은 Depth의 Recursive Query 발생 시 CPU 및 I/O 부하로 인한 성능 저하가 발생함. 특히 Enterprise 규모의 ERP 시스템에서는 7단계 이상의 Depth와 수천 행의 Scan으로 인해 리포트 지연 및 생산 계획 차질이 나타나는 한계점이 존재함.

Technical Solution

  • Self-referencing Table 기반의 정규화 모델을 기본으로 채택하여 데이터 정합성 유지
  • PostgreSQL의 WITH RECURSIVE 구문을 활용한 계층 데이터의 동적 확장 및 조회 수행
  • 읽기 부하가 극심한 경우 Path-based(예: 001.002) 또는 Parent Array 저장 방식의 Denormalization 검토
  • 불필요한 복잡성 제거를 위해 Indexing, Materialized View, Caching 등 비침습적 최적화 우선 적용
  • 비즈니스 규모(수백 명 vs 수만 명)와 쿼리 응답 속도(50ms vs 200ms)의 Trade-off를 분석하여 최적화 시점 결정

- 현재 데이터 Depth가 3~4단계 수준이며 응답 속도가 사용자 경험에 영향을 주지 않는지 확인 - Write 작업 빈도가 높고 Read 부하가 낮다면 Denormalization으로 인한 데이터 동기화 비용 검토 - 수만 건 이상의 대규모 데이터셋으로 확장되기 전까지는 정규화 모델과 Indexing 최적화 유지 - 성능 측정 지표 없이 추측만으로 복잡한 아키텍처를 도입하는 Over-engineering 경계

원문 읽기