Data Enginnering

대량 데이터 처리와 데이터 아키텍처 설계(OLAP & OLTP)

Somaz 2025. 4. 29. 12:39
728x90
반응형

Overview

오늘날 대부분의 웹 서비스와 엔터프라이즈 시스템은 대량의 데이터를 다루게 된다. 단일 서버나 단순한 데이터베이스 구조로는 이러한 대규모 데이터를 효율적으로 처리하기 어렵기 때문에, 효과적인 데이터 아키텍처 설계가 필수적이다.

 

본 글에서는 대량 데이터 처리를 위한 기본 개념인 OLTP와 OLAP의 차이점을 살펴보고, 데이터베이스 샤딩(Sharding)과 파티셔닝(Partitioning) 전략에 대해 정리해보겠다.

 

출처 : https://www.boardinfinity.com/blog/difference-between-olap-and-oltp/

 

 

 

 

📅 관련 글

2024.04.25 - [Database] - DB 샤딩(Sharding): 개념 및 동작방식

2023.04.21 - [Database] - DB 스키마란?(Schema)

 

 

 

 

 

 

 

 

 

1. OLTP vs. OLAP

 

 

OLTP (Online Transaction Processing)

  • 정의: 트랜잭션 중심의 데이터베이스로, 빠른 CRUD(Create, Read, Update, Delete) 작업에 최적화됨

 

  • 특징:
    • 짧고 빈번한 트랜잭션
    • 데이터 무결성이 중요
    • 정규화된 스키마 사용
    • 예: 쇼핑몰 주문 처리, 은행 거래 시스템 등

 

 

 

 

OLAP (Online Analytical Processing)

  • 정의: 분석 중심의 데이터베이스로, 대량의 데이터를 대상으로 복잡한 쿼리와 통계를 수행

 

  • 특징:
    • 다차원 분석 (Multidimensional Analysis)
    • 집계, 그룹화 쿼리 중심
    • 반정규화된 스키마(스타 스키마, 스노우플레이크 스키마 등)
    • 예: BI 도구, 데이터 웨어하우스, 마케팅 리포트

 

 

 

 

비교

항목 OLTP OLAP
목적 트랜잭션 처리 데이터 분석
작업 유형 CRUD 복잡한 쿼리, 집계
성능 지향 빠른 응답 시간 대량 처리 최적화
스키마 정규화 반정규화
사용 예시 쇼핑, 은행, ERP BI, 리포트, 의사결정

 

 

 

 

 

 

 

2. 대량 데이터 처리 전략

대규모 데이터를 효율적으로 처리하려면 수평적 확장이 가능한 구조가 필요하며, 대표적으로 샤딩과 파티셔닝 전략이 사용된다.

 

 

 

샤딩 (Sharding)

  • 정의: 데이터를 여러 DB 인스턴스로 분산 저장하는 방식 (수평적 분할)

 

  • 장점:
    • 성능 향상 (읽기/쓰기 부하 분산)
    • 데이터베이스 단위의 확장성
    • 단일 장애 지점 감소

 

  • 예시:
    • 사용자 ID의 해시값을 기준으로 `user_0`, `user_1`, `user_2` DB에 나눠 저장

 

 

 

실전 적용 사례

  • Facebook: 사용자 데이터를 지역 기반으로 샤딩
  • Shopify: 상점별로 샤드를 나누고 독립적으로 관리하여 확장성과 고가용성 확보

 

샤딩 키 고려사항

  • 쿼리 패턴과 잘 맞는 필드 선택 (예: 자주 조회되는 `user_id`)
  • 데이터 분포 균형 유지 (데이터 쏠림 방지)
  • 자주 업데이트 되거나 조인되는 필드는 피하는 것이 좋음

 

 

 

 

파티셔닝 (Partitioning)

  • 정의: 하나의 데이터베이스 안에서 테이블을 논리적으로 나누는 방식

 

  • 종류:
    • Range Partitioning: 날짜나 숫자 범위로 분할
    • List Partitioning: 특정 값 집합으로 분할
    • Hash Partitioning: 해시값으로 분산

 

  • 장점:
    • 쿼리 성능 최적화 (파티션 프루닝)
    • 백업, 유지보수 용이

 

 

 

 

파티션 프루닝

  • DBMS가 쿼리 조건에 따라 필요한 파티션만 읽는 최적화 기법
  • 예: `SELECT * FROM logs WHERE created_at >= '2024-01-01'` → 특정 날짜 파티션만 스캔

 

 

 

 

 

샤딩 vs 파티셔닝

항목 샤딩 파티셔닝
단위 DB 인스턴스 테이블 내 파티션
확장성 수평적 확장 논리적 분할
운영 복잡도 높음 (샤드 키 관리) 비교적 낮음
사용 예시 글로벌 사용자 분산 날짜별 로그 분할

 

 

 

 

 

3. 설계 시 고려 체크리스트

항목 설명
데이터량 수백 GB 이상이라면 분산 구조 고려
쿼리 패턴 단일 키 기반 조회가 많을 경우 샤딩 효과적
확장 필요성 트래픽 급증 예상 시 사전 설계 필요
백업/복구 전략 샤딩된 환경에선 백업/복구 복잡도 고려

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

샤딩 이후 운영 시 고려 사항

 

Cross-Shard Query 문제

샤딩된 환경에서는 서로 다른 샤드에 있는 데이터를 동시에 조회해야 하는 경우 성능 저하가 발생할 수 있다.

  • 예: `user_id` 는 샤딩되어 있지만, `user_logs` 같은 테이블과 조인할 때
  • 해결 방안:
    • 샤드 게이트웨이를 통해 여러 샤드에 병렬 쿼리 요청
    • 데이터 복제 또는 조인 전 데이터 집계 등의 아키텍처 설계 필

 

 

샤드 재조정(Re-sharding)

초기에 잘 설계한 샤딩 키라도 트래픽이 쏠리는 경우가 생긴다.

  • 예: 특정 지역 사용자 수 급증
  • 해결 방안:
    • 가상 샤드(Virtual Shard) 개념 도입
    • 샤드를 물리적 서버와 분리하여 유연하게 재배치 가능

 

 

 

파티셔닝 시 주의할 점

  • 너무 많은 파티션 생성은 오히려 성능 저하 (예: PostgreSQL에서 1000개 이상의 파티션)
  • 파티션 유지 관리 자동화 필요 (예: 매일 로그 테이블 생성 → 자동 스케줄링으로 파티션 추가)

 

 

 

 

 

샤딩/파티셔닝 선택 가이드

고려 요소 권장 전략
글로벌 사용자 기반, 고가용성 필요 샤딩
시간 기반 로그, 이벤트 스트림 파티셔닝
트래픽 급증 대비 확장성 샤딩 우선 고려
운영 간편함, 쿼리 최적화 파티셔닝

 

 

 

 

 

기술 스택 예시

전략 대표 도구
샤딩 MongoDB, Vitess(MySQL), CockroachDB, YugabyteDB
파티셔닝 PostgreSQL, BigQuery, Redshift, Snowflake

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

마무리

대규모 데이터를 처리하는 시스템에서는 단순한 스키마나 단일 노드 운영으로는 한계가 명확하다.

 

트랜잭션 중심의 OLTP와 분석 중심의 OLAP의 차이를 명확히 이해하고, 상황에 맞게 샤딩과 파티셔닝을 적절히 조합하는 것이 중요하다. 궁극적으로는 데이터 구조, 쿼리 유형, 유지보수 편의성까지 고려하여 시스템을 설계해야 하며, 이를 통해 성능과 확장성을 모두 만족하는 아키텍처를 구현할 수 있다.

 

앞으로는 이러한 구조 위에 데이터 웨어하우스, 데이터 레이크, 실시간 스트리밍 처리 등 다양한 아키텍처들이 융합되는 방향으로 진화할 것이다.

 

 

 

 

 

 

 

 

 

Reference

 

728x90
반응형

'Data Enginnering' 카테고리의 다른 글

Data ETL Pipeline 구성 요소 및 설명  (0) 2025.04.14
Airflow란? (개념 및 설치)  (0) 2025.04.04

'Data Enginnering'의 다른글

  • 현재글대량 데이터 처리와 데이터 아키텍처 설계(OLAP & OLTP)

관련글

댓글

티스토리툴바