파티셔닝의 정의와 예시, 고려해야 하는 시점

파티셔닝 예시

파티셔닝은 하나의 도메인(카카오톡 발송 내역)을 여러 테이블에 나누어 저장하는 것을 말합니다.

카카오톡 발송 내역 파티셔닝 예시

1. 파티셔닝 전 (단일 테이블)

-- 파티셔닝 전: 모든 발송 내역이 하나의 테이블에 저장
CREATE TABLE kakao_messages (
    id BIGINT PRIMARY KEY,
    user_id BIGINT,
    template_id VARCHAR(50),
    phone_number VARCHAR(20),
    content TEXT,
    status VARCHAR(20),
    sent_at TIMESTAMP,
    delivered_at TIMESTAMP,
    created_at TIMESTAMP
);

2. 파티셔닝 후 (여러 테이블로 분할)

시간 기반 파티셔닝 (가장 일반적)

-- 2024년 1월 발송 내역
CREATE TABLE kakao_messages_2024_01 (
    id BIGINT PRIMARY KEY,
    user_id BIGINT,
    template_id VARCHAR(50),
    phone_number VARCHAR(20),
    content TEXT,
    status VARCHAR(20),
    sent_at TIMESTAMP,
    delivered_at TIMESTAMP,
    created_at TIMESTAMP
);

-- 2024년 2월 발송 내역
CREATE TABLE kakao_messages_2024_02 (
    -- 동일한 스키마
);

-- 2024년 3월 발송 내역
CREATE TABLE kakao_messages_2024_03 (
    -- 동일한 스키마
);

사용자 ID 기반 파티셔닝

-- 사용자 ID 1-1000번대 발송 내역
CREATE TABLE kakao_messages_user_1k (
    -- 스키마 동일
);

-- 사용자 ID 1001-2000번대 발송 내역
CREATE TABLE kakao_messages_user_2k (
    -- 스키마 동일
);

상태 기반 파티셔닝

-- 성공한 발송 내역
CREATE TABLE kakao_messages_success (
    -- 스키마 동일
);

-- 실패한 발송 내역
CREATE TABLE kakao_messages_failed (
    -- 스키마 동일
);

파티셔닝의 핵심 개념

1. 동일한 도메인, 다른 테이블

도메인: 카카오톡 발송 내역
├── 테이블1: kakao_messages_2024_01 (1월 데이터)
├── 테이블2: kakao_messages_2024_02 (2월 데이터)
├── 테이블3: kakao_messages_2024_03 (3월 데이터)
└── ...

2. 스키마는 동일, 데이터만 분산

• 모든 파티션 테이블의 컬럼 구조는 동일
• 데이터만 다른 테이블에 분산 저장
• 각 테이블은 전체 도메인의 일부 데이터만 담당

3. 애플리케이션에서 통합 관리

// 파티셔닝 전
public List<Message> getMessages(Long userId) {
    return jdbcTemplate.query(
        "SELECT * FROM kakao_messages WHERE user_id = ?", 
        userId
    );
}

// 파티셔닝 후
public List<Message> getMessages(Long userId) {
    List<Message> allMessages = new ArrayList<>();

    // 여러 파티션에서 데이터 수집
    allMessages.addAll(getMessagesFromPartition("kakao_messages_2024_01", userId));
    allMessages.addAll(getMessagesFromPartition("kakao_messages_2024_02", userId));
    allMessages.addAll(getMessagesFromPartition("kakao_messages_2024_03", userId));

    return allMessages;
}

실제 카카오톡 발송 내역 파티셔닝 시나리오

데이터 규모 가정

- 일일 발송량: 100만 건
- 월 발송량: 3,000만 건
- 로우 크기: 약 200 bytes
- 월 데이터 크기: 약 6GB
- 연 데이터 크기: 약 72GB

파티셔닝 전략

1. 월별 파티셔닝 (권장)

-- 2024년 월별 파티션
kakao_messages_2024_01  -- 6GB
kakao_messages_2024_02  -- 6GB
kakao_messages_2024_03  -- 6GB
...
kakao_messages_2024_12  -- 6GB

2. 분기별 파티셔닝

-- 2024년 분기별 파티션
kakao_messages_2024_q1  -- 18GB (1-3월)
kakao_messages_2024_q2  -- 18GB (4-6월)
kakao_messages_2024_q3  -- 18GB (7-9월)
kakao_messages_2024_q4  -- 18GB (10-12월)

3. 사용자별 파티셔닝

-- 사용자 ID 기반 파티션
kakao_messages_user_1m  -- 사용자 1-100만번대
kakao_messages_user_2m  -- 사용자 100만-200만번대
kakao_messages_user_3m  -- 사용자 200만-300만번대

파티셔닝의 장점

1. 성능 향상

• 쿼리 범위 축소: 특정 월 데이터만 조회
• 인덱스 효율성: 각 파티션의 인덱스가 작아짐
• 병렬 처리: 여러 파티션을 동시에 조회

2. 관리 용이성

• 백업/복구: 파티션별 개별 관리
• 데이터 보관: 오래된 파티션 삭제/아카이브
• 유지보수: 파티션별 독립적 작업

3. 확장성

• 새 파티션 추가: 새로운 기간/범위 추가
• 하드웨어 분산: 파티션별 다른 서버 배치
• 부하 분산: 파티션별 부하 분산

결론

파티셔닝은 하나의 도메인(카카오톡 발송 내역)을 논리적으로는 하나의 엔티티로 보지만, 물리적으로는 여러 테이블에 분산 저장하는 기술입니다.

• 도메인: 동일 (카카오톡 발송 내역)
• 테이블: 분할 (월별, 사용자별, 상태별 등)
• 데이터: 분산 (각 파티션에 일부 데이터만 저장)

이렇게 하면 대용량 데이터를 효율적으로 관리할 수 있습니다.

파티셔닝을 고려해야 하는 시점

1. 데이터 크기 기준

단일 테이블 크기

• 10GB 이상: 단일 테이블이 10GB를 넘어가면 파티셔닝 고려
• 100GB 이상: 반드시 파티셔닝 필요
• 1TB 이상: 대규모 파티셔닝 필수

전체 데이터베이스 크기

• 100GB 이상: 전체 DB 크기가 100GB를 넘으면 파티셔닝 검토
• 1TB 이상: 반드시 파티셔닝 구현 필요

2. 성능 기준

쿼리 응답 시간

• 단순 조회: 1초 이상 지속적으로 발생
• 복잡한 조인: 5초 이상 지속적으로 발생
• 집계 쿼리: 10초 이상 지속적으로 발생

동시 사용자 수

• 1,000명 이상: 동시 접속자가 1,000명을 넘으면 고려
• 10,000명 이상: 반드시 파티셔닝 필요

3. 처리량 기준

TPS (Transaction Per Second)

• 1,000 TPS 이상: 초당 트랜잭션이 1,000개를 넘으면 고려
• 10,000 TPS 이상: 반드시 파티셔닝 필요

QPS (Query Per Second)

• 5,000 QPS 이상: 초당 쿼리가 5,000개를 넘으면 고려
• 50,000 QPS 이상: 반드시 파티셔닝 필요

4. 하드웨어 한계 기준

메모리 사용률

• 80% 이상: 메모리 사용률이 80%를 넘어가면 고려
• 90% 이상: 반드시 파티셔닝 필요

디스크 I/O

• 디스크 사용률 80% 이상: 디스크 I/O가 병목이 되면 고려
• 디스크 대기시간 증가: 평균 대기시간이 급격히 증가하면 고려

5. 비즈니스 성장 기준

데이터 증가율

• 월 10GB 이상: 월 데이터 증가량이 10GB를 넘으면 고려
• 연 1TB 이상: 연간 데이터 증가량이 1TB를 넘으면 반드시 필요

사용자 증가율

• 월 50% 이상: 사용자가 급격히 증가하면 고려
• 연 10배 이상: 연간 10배 이상 성장하면 반드시 필요

실제 판단 기준

즉시 파티셔닝이 필요한 경우

✅ 단일 테이블 100GB 이상
✅ 전체 DB 1TB 이상  
✅ 동시 사용자 10,000명 이상
✅ TPS 10,000 이상
✅ 쿼리 응답시간 5초 이상 지속
✅ 메모리 사용률 90% 이상

파티셔닝을 고려해볼 시점

🤔 단일 테이블 10GB 이상
🤔 전체 DB 100GB 이상
🤔 동시 사용자 1,000명 이상
�� TPS 1,000 이상
🤔 쿼리 응답시간 1초 이상 지속
🤔 메모리 사용률 80% 이상

파티셔닝보다 다른 최적화를 먼저 시도할 경우

⏳ 단일 테이블 1GB 미만
⏳ 전체 DB 10GB 미만
⏳ 동시 사용자 100명 미만
⏳ TPS 100 미만
⏳ 쿼리 응답시간 100ms 이하
⏳ 메모리 사용률 60% 미만

파티셔닝 도입 전 고려사항

먼저 시도해볼 것들

1. 인덱스 최적화: 적절한 인덱스 추가
2. 쿼리 최적화: 비효율적인 쿼리 개선
3. 하드웨어 업그레이드: CPU, 메모리, SSD 확장
4. 읽기 복제: 읽기 전용 복제본 추가
5. 캐싱: Redis 등 캐시 도입

파티셔닝의 복잡성

• 개발 복잡도 증가: 애플리케이션 로직 복잡화
• 운영 복잡도 증가: 모니터링, 백업, 복구 복잡화
• 일관성 문제: 분산 환경에서의 데이터 일관성
• 트랜잭션 제한: 분산 트랜잭션의 한계

결론

파티셔닝은 마지막 수단으로 고려해야 합니다. 일반적으로

• 데이터 크기: 100GB 이상
• 성능: 쿼리 응답시간 1초 이상 지속
• 처리량: TPS 1,000 이상
• 사용자: 동시 접속자 1,000명 이상

이 중 2개 이상의 조건이 만족되면 파티셔닝을 진지하게 고려해볼 필요가 있다.