오라클을 오래 써본 개발자라면 대용량 데이터를 다룰 때 자연스럽게 파티션 테이블을 떠올리게 됩니다.
특히 날짜별 분리, 대량 삭제, 조회 성능 최적화, 관리 편의성 측면에서 파티션은 매우 강력한 개념입니다.
그렇다면 이런 오라클 파티션 테이블의 사상을 MongoDB에도 적용할 수 있을까요?
결론부터 말하면 가능합니다.
다만 오라클처럼 “파티션 테이블”이라는 동일한 기능을 그대로 쓰는 것이 아니라,
MongoDB에서는 샤딩(Sharding), 컬렉션 분리, TTL, 아카이빙, 인덱스 설계를 조합해서 비슷한 목적을 달성합니다.
1. 오라클 파티션 테이블이 해결하던 문제
오라클에서 파티션을 쓰는 이유는 보통 다음과 같습니다.
- 날짜 기준으로 데이터 분리
- 대용량 데이터 성능 개선
- 특정 구간만 빠르게 조회
- 오래된 데이터 삭제 간소화
- 운영 및 관리 효율 향상
예를 들어 주문 데이터가 수억 건 이상 쌓이면,
월 단위 파티션을 구성해서 최근 3개월만 빠르게 조회하거나
오래된 월 데이터를 한 번에 제거하는 방식으로 운영합니다.
2. MongoDB에서는 무엇으로 대응할까?
MongoDB에는 오라클의 파티션 테이블과 같은 개념이 직접적으로 존재하지 않습니다.
대신 아래처럼 대응해서 생각하면 됩니다.
오라클 파티션 개념과 MongoDB 대응 방식
- RANGE 파티션 → Range 기반 샤딩 또는 월별 컬렉션 분리
- HASH 파티션 → Hashed Sharding
- LIST 파티션 → Zone Sharding 또는 컬렉션 분리
- 파티션 삭제 → TTL Index, Archive 컬렉션, 컬렉션 Drop
- 파티션 프루닝 → 샤드 키 기반 라우팅
즉, MongoDB에서는 “파티션”이라는 단일 기능이 아니라
데이터 분산 방식 + 보관 전략 + 인덱스 전략의 조합으로 접근해야 합니다.
3. 날짜 기준 RANGE 파티션 사상을 옮기는 방법
오라클에서 가장 흔한 패턴은 날짜 기준 파티션입니다.
예를 들어 다음과 같은 구조입니다.
- sales_2026_01
- sales_2026_02
- sales_2026_03
이 사상을 MongoDB로 옮기는 방법은 크게 3가지입니다.
방법 1. 단일 컬렉션 + Range Sharding
가장 전형적인 방식입니다.
예를 들어 주문 컬렉션에서 다음 필드를 기준으로 샤드 키를 잡습니다.
- tenantId
- orderDate
이렇게 하면 특정 고객사의 특정 기간 조회가 많은 환경에서 매우 유리합니다.
예시 개념:
sh.shardCollection(
"app.orders",
{ tenantId: 1, orderDate: 1 }
)
장점
- 날짜 범위 조회에 유리
- 멀티테넌트 구조와 결합하기 좋음
- 오라클의 range partition 사고와 가장 유사함
주의점
- 날짜 단독 샤드 키는 쓰기 핫스팟이 발생할 수 있음
- 최근 데이터가 특정 샤드에 몰릴 수 있음
그래서 실무에서는 orderDate 단독보다
tenantId + orderDate 같은 복합 샤드 키를 더 많이 고려합니다.
방법 2. 단일 컬렉션 + Hashed Sharding
이 방식은 오라클의 HASH 파티션과 가장 비슷한 개념입니다.
예를 들어:
sh.shardCollection(
"app.events",
{ userId: "hashed" }
)
장점
- 쓰기 분산에 강함
- 핫스팟 완화에 효과적
- 대량 이벤트 저장에 적합
단점
- 날짜 범위 조회 최적화에는 불리함
- “최근 1주일”, “이번 달” 같은 검색은 추가 인덱스 전략이 필요함
즉, 이 방식은 조회보다 쓰기 분산이 더 중요할 때 적합합니다.
방법 3. 월별 컬렉션 분리
이 방식은 오라클 파티션 운영 개념을 가장 직관적으로 MongoDB에 옮기는 방법입니다.
예를 들어:
- events_2026_01
- events_2026_02
- events_2026_03
처럼 아예 컬렉션을 나눕니다.
장점
- 오래된 월 데이터 제거가 쉬움
- 월별 백업/이관이 쉬움
- 운영자가 파티션처럼 체감하기 좋음
단점
- 애플리케이션이 어떤 컬렉션을 조회할지 알아야 함
- 여러 달을 한 번에 조회할 때 코드가 복잡해짐
- 컬렉션 수가 많아지면 관리 부담이 생김
즉, 엔진 차원의 파티션이 아니라
애플리케이션 차원의 논리 파티셔닝이라고 보면 됩니다.
4. 오래된 파티션 삭제 사상을 MongoDB에 적용하는 방법
오라클에서는 DROP PARTITION 한 줄로 오래된 데이터를 정리할 수 있습니다.
MongoDB에서는 보통 다음 두 가지 방식으로 대체합니다.
4-1. TTL 인덱스 사용
로그, 세션, 방문 기록처럼 일정 기간 이후 자동 삭제가 가능한 데이터에 적합합니다.
예시:
db.events.createIndex(
{ createdAt: 1 },
{ expireAfterSeconds: 60 * 60 * 24 * 90 }
)
위 예시는 생성 후 90일이 지나면 자동 삭제됩니다.
적합한 경우
- 접속 로그
- 세션 데이터
- 이벤트 트래킹 데이터
- 임시 데이터
부적합한 경우
- 월 단위로 묶어서 보관/삭제해야 하는 회계 데이터
- 법적 보관 요건이 있는 데이터
4-2. Archive 컬렉션 분리
이 방식은 실무에서 자주 쓰입니다.
예를 들어:
- orders_hot
- orders_archive
처럼 최근 데이터와 과거 데이터를 분리합니다.
장점
- 최근 데이터 성능 유지 가능
- 오래된 데이터는 저비용 스토리지로 이동 가능
- 오라클의 “구 파티션 별도 관리”와 유사한 운영이 가능
이 방식은 특히
최근 데이터는 자주 조회하지만, 과거 데이터는 거의 조회하지 않는 서비스에서 효과적입니다.
5. LIST 파티션 사상은 MongoDB에서 어떻게 구현할까?
오라클에서는 국가, 지역, 서비스 타입, 고객군 기준으로 LIST 파티션을 구성하기도 합니다.
MongoDB에서는 이를 다음 방식으로 대응할 수 있습니다.
- 특정 필드를 샤드 키에 포함
- Zone Sharding 사용
- 테넌트별 컬렉션 분리
예를 들어:
- 한국 고객 데이터는 특정 샤드
- 일본 고객 데이터는 다른 샤드
처럼 논리적/물리적으로 분리할 수 있습니다.
이건 오라클 LIST 파티션의 “그룹별 분리” 개념과 꽤 비슷합니다.
6. 인덱스 전략은 더 중요해진다
오라클에서는 파티션 설계가 중심이었다면,
MongoDB에서는 샤드 키와 인덱스 설계가 훨씬 중요합니다.
핵심은 다음 질문입니다.
- 쿼리가 샤드 키를 타는가?
- 범위 조회에 맞는 인덱스가 있는가?
- 활성 데이터만 인덱싱할 수 있는가?
예를 들어 상태가 ACTIVE인 문서만 자주 조회한다면 partial index도 고려할 수 있습니다.
db.orders.createIndex(
{ tenantId: 1, orderDate: -1, status: 1 },
{ partialFilterExpression: { status: "ACTIVE" } }
)
이런 방식은 인덱스 크기를 줄이면서 조회 효율을 높일 수 있습니다.
7. 실무 적용 패턴 예시
7-1. 주문/거래 데이터
특징:
- 기간 조회 많음
- 고객사별 조회 많음
- 오래된 데이터는 가끔만 조회
추천:
- 단일 컬렉션
-
샤드 키:
tenantId + orderDate - 최근 데이터 중심 인덱스
- 오래된 데이터는 archive 분리
이 방식은 오라클 파티션 사고를 가장 자연스럽게 이전하는 패턴입니다.
7-2. 로그/이벤트 데이터
특징:
- 쓰기량 매우 많음
- 최근 데이터 위주 조회
- 일정 기간 뒤 삭제 가능
추천:
- hashed sharding
- TTL 인덱스
- 필요하면 time-series 컬렉션 검토
이 경우는 “파티션”보다
쓰기 분산 + 자동 만료가 핵심입니다.
7-3. 정산/회계 데이터
특징:
- 월 단위 경계가 중요
- 월별 보관/폐기 요구가 명확
- 기간 단위 관리가 중요
추천:
- 월별 컬렉션 분리
- 컬렉션별 동일 인덱스 정책
- 필요 시 최근 월 데이터만 샤딩
이 경우는 오라클 파티션 감각을 가장 직관적으로 구현할 수 있습니다.
8. 오라클 방식 그대로 가져오면 안 되는 이유
MongoDB에서 흔히 실패하는 포인트가 있습니다.
8-1. 날짜 단독 샤드 키
최근 데이터 쓰기가 한 샤드로 몰릴 수 있습니다.
8-2. 파티션처럼 알아서 빨라질 거라는 기대
MongoDB는 샤드 키를 잘 타야 성능 이점이 생깁니다.
8-3. DROP PARTITION 같은 관리 편의성 기대
MongoDB에서는 TTL, 아카이브, 컬렉션 분리로 다시 설계해야 합니다.
즉, 구조를 단순 모방하면 안 되고
왜 파티션을 썼는지 목적부터 분해해야 합니다.
9. 결론
오라클 파티션 테이블의 사상은 MongoDB에도 충분히 적용할 수 있습니다.
하지만 그대로 복제하는 것이 아니라, 목적에 맞게 재구성해야 합니다.
정리하면 다음과 같습니다.
- 성능 분산이 목적이면 → 샤딩
- 범위 조회 최적화가 목적이면 → Range Sharding
- 쓰기 분산이 목적이면 → Hashed Sharding
- 월 단위 운영이 목적이면 → 컬렉션 분리
- 보존 기간 관리가 목적이면 → TTL / Archive
- 그룹별 물리 분리가 목적이면 → Zone Sharding
즉, MongoDB에서 중요한 것은
“파티션 기능이 있느냐”가 아니라
데이터를 어떤 기준으로 분산하고, 어떻게 조회하고, 언제 정리할 것인가입니다.
마무리
오라클의 파티션 테이블은 매우 강력한 개념이지만,
MongoDB에서는 그 철학을 조금 다르게 풀어야 합니다.
핵심은 하나입니다.
파티션 자체를 옮기려 하지 말고, 파티션이 해결하던 문제를 MongoDB 방식으로 재설계하라.
이 관점으로 접근하면
Oracle에서 MongoDB로 넘어가더라도 훨씬 안정적인 데이터 모델을 만들 수 있습니다.
0 댓글