MongoDB (r1)

MongoDB의 핵심 데이터 모델은 문서(Document)와 컬렉션(Collection)으로 구성된다. 문서는 데이터의 기본 단위이며, 키-값 쌍으로 이루어진 유연한 구조를 가진다. 이는 관계형 데이터베이스의 행(레코드)에 대응되지만, 미리 정의된 스키마의 제약을 받지 않는다. 각 문서는 JSON과 유사한 BSON 형식으로 저장되며, 중첩된 배열이나 다른 문서를 포함할 수 있어 복잡한 계층적 데이터를 자연스럽게 표현할 수 있다.

문서들은 논리적으로 컬렉션에 그룹화된다. 컬렉션은 관계형 데이터베이스의 테이블과 유사한 개념이지만, 고정된 스키마를 강제하지 않는다는 점에서 근본적으로 다르다. 하나의 컬렉션 내에 서로 다른 구조를 가진 문서들이 공존할 수 있다. 이는 애플리케이션의 요구사항이 빠르게 변하거나, 다양한 형태의 데이터를 저장해야 할 때 큰 장점이 된다.

컬렉션은 데이터베이스 내에 생성되며, 데이터베이스는 여러 컬렉션을 포함하는 최상위 네임스페이스 역할을 한다. 각 문서는 컬렉션 내에서 고유한 식별자인 `_id` 필드를 가지며, 이 값은 문서 생성 시 자동으로 생성될 수 있다. 컬렉션에 대한 주요 연산은 문서의 삽입, 조회, 수정, 삭제이다.

문서와 컬렉션 모델의 주요 특징은 다음과 같이 요약할 수 있다.

이 모델은 반정형 데이터나 빠른 프로토타이핑, 애자일 개발 방식에 특히 적합하다. 그러나 데이터 구조에 대한 명확한 규약이 필요하거나, 강력한 참조 무결성이 필수적인 복잡한 트랜잭션 환경에서는 관계형 모델에 비해 단점이 될 수 있다.

BSON은 Binary JSON의 약자로, MongoDB가 데이터를 저장하고 네트워크를 통해 전송할 때 사용하는 이진 인코딩 형식이다. JSON과 유사한 구조를 가지지만, 이진 형식으로 표현되어 더 효율적이고, JSON에서 지원하지 않는 추가 데이터 타입을 포함한다.

BSON은 문자열, 정수, 부동소수점, 불리언, 배열, 객체 등 기본 JSON 타입 외에도 날짜(Date), 이진 데이터(BinData), ObjectId, 정규 표현식(Regex) 등의 특수 타입을 지원한다. 특히 MongoDB의 기본 문서 식별자인 `_id` 필드에 주로 사용되는 ObjectId는 BSON의 고유 타입이다. 이는 12바이트로 구성되어 타임스탬프, 머신 식별자, 프로세스 ID, 카운터를 포함하여 분산 환경에서 고유성을 보장한다[1].

BSON 문서의 최대 크기는 16메가바이트이다. 이 제한은 단일 문서가 너무 많은 메모리나 대역폭을 차지하지 않도록 보장한다. 더 큰 데이터를 저장해야 할 경우에는 GridFS 명세를 사용한다. BSON의 이진 특성은 데이터를 직렬화하고 파싱하는 속도가 텍스트 기반 JSON보다 일반적으로 빠르며, 필드 이름을 문자열로 반복 저장하기 때문에 저장 공간 측면에서는 비효율적일 수 있다. 그러나 이 설계는 쿼리 성능을 최적화하는 데 중점을 두고 있다.

MongoDB는 스키마리스 또는 스키마 유연성을 핵심 특징으로 하는 문서 지향 데이터베이스이다. 이는 관계형 데이터베이스 관리 시스템에서 요구되는 고정된 테이블 구조와 사전 정의된 스키마를 엄격히 준수할 필요가 없음을 의미한다. 동일한 컬렉션 내에 저장된 각 문서는 서로 다른 구조를 가질 수 있다. 예를 들어, '사용자' 컬렉션 내 하나의 문서는 '이름', '이메일', '나이' 필드를 가질 수 있는 반면, 다른 문서는 '이름', '로그인 횟수', '주소' 객체를 포함할 수 있다. 이 유연성은 애플리케이션의 데이터 모델이 빠르게 진화하거나 다양한 특성을 가진 데이터를 저장해야 할 때 큰 장점이 된다.

이러한 유연성은 개발 주기를 단축시키는 데 기여한다. 데이터 구조를 변경해야 할 때, 기존 데이터를 마이그레이션하거나 복잡한 ALTER TABLE 문을 실행할 필요 없이 애플리케이션 코드에서 새로운 필드를 문서에 직접 추가하면 된다. 이는 특히 애자일 개발 환경이나 프로토타이핑 단계에서 매우 유용하다. 또한, 다형성 데이터를 자연스럽게 표현할 수 있어, 하나의 컬렉션이 다양한 형태의 객체를 저장하는 데 적합하다.

그러나 스키마 유연성은 책임을 동반한다. 데이터 무결성 검증이 애플리케이션 계층으로 완전히 위임되기 때문에, 데이터 일관성을 보장하기 위해 더 많은 주의가 필요하다. 이를 보완하기 위해 MongoDB는 버전 3.2부터 JSON 스키마 유효성 검사 규칙을 도입했다. 개발자는 컬렉션 수준에서 선택적 검증 규칙을 정의하여 필드의 데이터 타입, 필수 필드 여부, 값의 범위 등을 제한할 수 있다. 이는 유연성과 데이터 무결성 사이에서 균형을 잡는 도구로 작동한다.

따라서 MongoDB의 스키마 유연성은 변화하는 요구사항에 빠르게 적응할 수 있는 능력을 제공하지만, 효과적으로 활용하기 위해서는 적절한 데이터 모델링 원칙과 필요에 따른 유효성 검사 규칙의 적용이 수반되어야 한다.

MongoDB 클러스터는 고가용성과 수평적 확장성을 제공하기 위해 여러 서버를 하나의 논리적 시스템으로 묶은 구조이다. 주요 구성 요소로는 몽고스(mongos), 구성 서버(config server), 그리고 샤드(shard)가 있다. 이들은 각각 특정한 역할을 담당하며, 함께 작동하여 대규모 데이터 세트와 높은 처리량 요구를 처리한다.

클러스터에서 데이터는 샤딩 키를 기준으로 여러 샤드에 분산되어 저장된다. 구성 서버는 이 데이터 분포 맵(청크 정보)을 유지 관리하며, 몽고스는 이 정보를 참조하여 쿼리가 어떤 샤드를 대상으로 해야 하는지 결정한다. 예를 들어, 사용자 ID를 샤딩 키로 사용하는 경우, 특정 사용자 ID에 대한 쿼리는 해당 데이터가 위치한 샤드로만 전달된다. 이 구조는 읽기 및 쓰기 작업의 부하를 분산시키고, 단일 서버의 용량 한계를 넘어 시스템의 전체적인 저장 용량과 처리 성능을 선형적으로 확장할 수 있게 한다.

샤딩은 수평적 확장을 가능하게 하는 핵심 기능으로, 단일 서버의 용량 한계를 초과하는 대규모 데이터셋과 높은 처리량 요구사항을 해결하기 위해 설계되었다. 이는 데이터를 여러 물리적 서버(샤드)에 분산하여 저장하고 처리하는 방식이다. 각 샤드는 전체 데이터의 일부를 담당하는 독립적인 데이터베이스 인스턴스로 구성되며, 샤드 클러스터는 라우터(mongos)와 설정 서버(config servers)라는 특수한 구성 요소를 통해 통합 관리된다.

샤딩의 구현은 샤드 키 선택에 크게 의존한다. 샤드 키는 문서를 특정 샤드에 할당하는 기준이 되는 컬렉션 내 하나 이상의 필드로 구성된다. 샤드 키의 선택은 성능과 데이터 분포에 결정적인 영향을 미치므로, 쿼리 패턴과 데이터 증가 특성을 신중히 고려해야 한다. MongoDB는 주로 범위 기반 샤딩과 해시 기반 샤딩이라는 두 가지 샤딩 전략을 제공한다. 범위 기반 샤딩은 샤드 키 값의 연속된 범위를 같은 샤드에 배치하여 범위 쿼리 성능을 최적화하지만, 데이터 불균형을 초래할 수 있다. 해시 기반 샤딩은 샤드 키 값에 해시 함수를 적용하여 데이터를 무작위로 분산시켜 균등한 분포를 보장하지만, 범위 쿼리 효율성이 떨어진다.

샤딩 클러스터의 운영에서 밸런서(balancer)는 중요한 역할을 수행한다. 이 백그라운드 프로세스는 샤드 간의 데이터 청크(데이터의 기본 분할 단위) 분포를 모니터링하고, 사전 정의된 임계값을 기준으로 청크를 자동으로 마이그레이션하여 클러스터 전체의 데이터 균형을 유지한다. 이를 통해 특정 샤드에 부하가 집중되는 핫스팟 현상을 방지하고 지속적인 성능을 보장한다.

샤딩은 복제 세트와 결합되어 사용되는 경우가 일반적이다. 즉, 각 샤드 자체가 데이터 중복성과 고가용성을 제공하는 복제 세트(Replica Set)로 구성된다. 이 아키텍처는 시스템의 확장성과 내결함성을 동시에 확보하는 강력한 기반을 제공한다.

복제 세트는 MongoDB에서 고가용성과 데이터 내구성을 제공하는 기본 메커니즘이다. 하나의 프라이머리 노드와 여러 개의 세컨더리 노드로 구성되며, 모든 데이터 변경 작업은 프라이머리 노드에서 처리된다. 프라이머리 노드는 변경 사항을 복제본 로그(oplog)에 기록하고, 세컨더리 노드는 이 oplog를 비동기적으로 복제하여 데이터를 동기화한다. 프라이머리 노드에 장애가 발생하면, 나머지 노드들은 자동으로 새로운 프라이머리 노드를 선출하는 선거 과정을 통해 서비스 중단을 최소화한다.

복제 세트의 구성은 일반적으로 홀수 개의 멤버(예: 3개 또는 5개)로 이루어지며, 데이터의 안정성을 위해 지리적으로 분산 배치할 수 있다. 특수한 역할을 가진 멤버 유형도 존재한다.

복제의 주요 이점은 고가용성, 데이터 내구성, 읽기 확장성이다. 애플리케이션은 읽기 작업을 세컨더리 노드로 분산시켜 성능을 향상시킬 수 있다. 또한 복제 세트는 롤링 유지보수를 지원하여, 한 번에 하나의 멤버를 재시작하거나 업그레이드하면서도 전체 서비스의 가용성을 유지할 수 있다.

MongoDB는 CRUD 연산을 지원하여 데이터의 생성, 조회, 갱신, 삭제 기능을 제공한다. 이러한 연산은 MongoDB 셸이나 다양한 프로그래밍 언어용 드라이버를 통해 수행된다. 핵심 연산 메서드는 다음과 같다.

조회 연산인 `find()` 메서드는 풍부한 쿼리 연산자와 함께 사용된다. `$eq`, `$gt`, `$lt` 같은 비교 연산자와 `$in`, `$and`, `$or` 같은 논리 연산자를 조합해 복잡한 질의를 구성할 수 있다. 갱신 연산에서는 `$set`, `$inc`, `$push` 같은 갱신 연산자를 사용하여 문서의 특정 필드만을 수정하는 것이 일반적이다.

모든 CRUD 메서드는 선택적 옵션 인자를 받는다. 예를 들어, `insertMany()`는 문서 배열의 삽입 순서를 보장할지 여부를 지정할 수 있고, `updateMany()`는 업데이트 조건과 일치하는 문서가 없을 때 새 문서를 삽입하도록 설정할 수 있다[3]. 이러한 연산들은 기본적으로 단일 문서 수준의 원자성을 보장한다.

집계 파이프라인은 MongoDB에서 다수의 문서를 처리하고 변환하여 집계된 결과를 계산하는 프레임워크이다. 파이프라인은 여러 단계로 구성되며, 각 단계는 문서 스트림을 입력받아 처리한 후 다음 단계로 결과를 전달한다. 이 방식은 복잡한 데이터 분석 작업을 효율적으로 수행할 수 있게 한다.

집계 파이프라인의 일반적인 단계에는 `$match`, `$group`, `$sort`, `$project`, `$lookup` 등이 있다. `$match` 단계는 특정 조건에 맞는 문서만 필터링하고, `$group` 단계는 지정된 키를 기준으로 문서를 그룹화하여 합계, 평균, 카운트 등의 연산을 수행한다. `$lookup` 단계는 다른 컬렉션과의 조인(join) 연산을 가능하게 하여 관계형 데이터베이스와 유사한 작업을 지원한다.

파이프라인의 성능을 최적화하기 위해 몇 가지 방법을 사용할 수 있다. 가능한 한 초기 단계에서 `$match`와 `$project`를 사용하여 처리해야 할 문서의 수와 크기를 줄이는 것이 효과적이다. 또한, 파이프라인 단계의 순서를 신중하게 설계해야 하며, 인덱스를 활용할 수 있는 단계를 앞쪽에 배치하는 것이 좋다.

집계 파이프라인은 JSON 형태의 유연한 구문을 사용하며, MapReduce 모델보다 직관적이고 성능이 우수한 경우가 많다. 이를 통해 실시간 분석, 보고서 생성, 데이터 요약 등 다양한 비즈니스 인텔리전스 작업을 데이터베이스 내에서 직접 처리할 수 있다.

MongoDB는 다양한 인덱스 유형을 지원하여 다양한 쿼리 패턴과 데이터 구조에 맞춰 성능을 최적화할 수 있다. 가장 기본적인 인덱스는 단일 필드 인덱스로, 하나의 필드에 대해 생성된다. 복합 인덱스는 두 개 이상의 필드를 조합하여 생성되며, 필드 순서가 쿼리 성능에 중요한 영향을 미친다. 다중 키 인덱스는 배열 필드에 자동으로 생성되어 배열 내 각 요소를 인덱싱한다.

전문 인덱스는 텍스트 검색을 지원하기 위해 문자열 필드에 생성된다. 공간 인덱스는 지리 공간 데이터를 효율적으로 쿼리하기 위해 사용되며, 2dsphere 인덱스가 대표적이다. 해시 인덱스는 필드 값의 해시를 사용하여 인덱스 항목을 생성하며, 샤드 키로 사용될 때 데이터 분산에 유리하다. TTL(Time To Live) 인덱스는 특정 시간이 지나면 문서를 자동으로 삭제하는 데 사용된다.

몇 가지 특수 인덱스 유형도 존재한다. 부분 인덱스는 지정된 필터 표현식을 만족하는 문서만 인덱싱하여 인덱스 크기를 줄인다. 희소 인덱스는 인덱스 필드가 존재하거나 null이 아닌 값만 가진 문서만 인덱싱한다. 고유 인덱스는 인덱스 키 값의 중복을 방지하여 데이터 무결성을 보장한다.

적절한 인덱스 유형을 선택하고 구성하는 것은 쿼리 성능과 저장소 효율성에 직접적인 영향을 미친다. 애플리케이션의 데이터 접근 패턴을 분석하여 필요한 인덱스를 설계해야 한다.

쿼리 성능을 최적화하는 핵심은 적절한 인덱스를 설계하고 활용하는 것이다. 인덱스는 특정 필드에 대한 정렬된 데이터 구조를 생성하여, 전체 컬렉션 스캔(collection scan)을 피하고 필요한 문서를 빠르게 찾을 수 있게 한다. 쿼리 실행 계획을 분석하는 explain() 메서드를 사용하여, 쿼리가 어떤 인덱스를 사용하는지, 인덱스를 효율적으로 활용하는지 확인할 수 있다. 인덱스는 읽기 성능을 크게 향상시키지만, 쓰기 작업 시 인덱스를 갱신해야 하는 오버헤드가 발생하므로, 자주 조회되는 필드와 쿼리 패턴을 분석하여 필요한 인덱스만 생성하는 것이 중요하다.

인덱스 설계 시 고려해야 할 요소는 다음과 같다.

쿼리 자체를 최적화하는 방법도 있다. 프로젝션(`projection`)을 사용하여 필요한 필드만 조회하면 네트워크 전송량과 메모리 사용량을 줄일 수 있다. `$limit`와 `$skip` 연산자를 사용할 때는 주의가 필요하며, 특히 큰 `skip` 값은 성능 저하를 일으킬 수 있다. 대신, 이전 조회 결과의 마지막 값을 기준으로 하는 범위 쿼리로 대체하는 것이 좋다. 또한, 배열 필드에 대한 과도한 연산이나 정규 표현식의 와일드카드(`^`로 시작하지 않는 패턴) 사용은 인덱스 사용을 방해하거나 전체 스캔을 유발할 수 있다.

하드웨어 및 운영 측면에서는 워킹 세트(자주 액세스되는 데이터와 인덱스)가 물리적 RAM에 적절히 맞도록 용량을 계획해야 한다. 디스크 I/O는 주요 병목 현상이 될 수 있으므로, SSD 사용을 고려한다. 복제본 세트의 읽기 작업을 세컨더리 멤버로 분산시키거나, 샤딩을 통해 데이터와 부하를 수평적으로 분할하여 성능과 확장성을 동시에 확보할 수 있다. 정기적인 모니터링을 통해 느린 쿼리를 식별하고, 인덱스 사용 통계를 확인하여 최적화 전략을 지속적으로 조정해야 한다.

MongoDB는 데이터베이스 접근을 제어하기 위해 역할 기반 접근 제어(RBAC) 모델을 사용한다. 이 모델은 사용자에게 하나 이상의 역할을 부여하고, 각 역할은 특정 리소스에 대한 특정 작업 권한 집합을 정의한다. 인증은 사용자의 신원을 확인하는 과정이며, SCRAM (Salted Challenge Response Authentication Mechanism)이 기본 메커니즘으로 사용된다. 또한 X.509 인증서나 LDAP (Lightweight Directory Access Protocol) 및 Kerberos와 같은 외부 인증 시스템과의 통합도 지원한다[5].

권한 부여는 인증된 사용자가 수행할 수 있는 작업을 결정한다. MongoDB는 미리 정의된 빌트인 역할(예: `read`, `readWrite`, `dbAdmin`, `clusterAdmin`)과 사용자 정의 역할을 제공한다. 각 역할은 특정 데이터베이스에 적용되며, 권한은 컬렉션 수준까지 세분화될 수 있다. 예를 들어, 한 사용자는 `appDB` 데이터베이스의 `orders` 컬렉션에 대해 `find`와 `insert` 권한만 가질 수 있다.

관리자는 `admin` 데이터베이지를 사용하여 사용자와 역할을 생성 및 관리한다. 보안 설정은 일반적으로 구성 파일(`mongod.conf`)에서 활성화되며, 네트워크 노출을 최소화하기 위해 바인드 IP와 방화벽 규칙을 함께 구성하는 것이 권장된다.

MongoDB는 데이터베이스 수준, 운영 체제 수준, 그리고 전송 과정에서의 암호화를 지원하여 데이터 보안을 강화한다.

데이터 암호화는 크게 미사용 데이터 암호화와 전송 중 데이터 암호화로 구분된다. 미사용 데이터 암호화는 WiredTiger 스토리지 엔진의 기본 암호화 기능을 통해 구현된다. 이는 투명한 데이터 암호화로, 애플리케이션 변경 없이 데이터 파일과 저널 파일을 자동으로 암호화한다. 키 관리는 통합 키 관리 서비스를 통해 수행되거나, 고객이 관리하는 키를 사용할 수 있다. 전송 중 데이터 암호화는 TLS/SSL 프로토콜을 사용하여 클라이언트와 서버 간, 그리고 클러스터 내부 구성 요소 간의 모든 네트워크 통신을 보호한다.

또한, MongoDB는 클라이언트 측 필드 수준 암호화를 제공한다. 이 기능은 애플리케이션 드라이버 단계에서 특정 필드의 데이터를 암호화하여 데이터베이스 서버에 전송한다. 이 방식은 데이터베이스 관리자나 시스템 관리자도 암호화된 필드의 평문 데이터에 접근할 수 없도록 하여, 매우 민감한 데이터를 보호하는 데 효과적이다. 암호화 정책과 키 관리는 애플리케이션 코드에서 제어된다.

MongoDB는 데이터의 안정성과 가용성을 보장하기 위해 다양한 백업 및 복구 방법을 제공한다. 주요 백업 방식으로는 논리적 백업과 물리적 백업이 있다. 논리적 백업은 `mongodump` 유틸리티를 사용하여 데이터베이스의 논리적 구조와 내용을 BSON 또는 JSON 형식의 덤프 파일로 내보내는 방식이다. 이 방법은 특정 컬렉션이나 데이터베이스를 선택적으로 백업할 수 있고, 버전 간 호환성이 비교적 좋다는 장점이 있다. 반면, 물리적 백업은 데이터 파일을 직접 복사하는 방식으로, 복제 세트의 보조 멤버나 샤드 클러스터의 특정 구성 요소에서 파일 시스템 스냅샷을 생성하여 수행한다. 이 방법은 대규모 데이터셋을 빠르게 백업할 수 있지만, 백업 시점의 데이터 일관성을 보장하기 위해 주의가 필요하다.

복구 작업은 백업 방식에 따라 적절한 도구를 선택하여 진행한다. `mongodump`로 생성된 백업은 `mongorestore` 유틸리티를 사용하여 복원한다. 이 도구는 덤프 파일을 읽어 대상 MongoDB 인스턴스에 데이터를 삽입한다. 파일 시스템 스냅샷을 이용한 물리적 백업의 경우, 해당 데이터 파일을 복사한 후 `mongod` 프로세스를 해당 경로에서 재시작하는 방식으로 복구한다. 클라우드 환경에서는 MongoDB Atlas와 같은 관리형 서비스가 자동화된 스냅샷 백업과 포인트-인-타임 복구 기능을 제공하여 운영 부담을 줄여준다.

효율적인 백업 전략을 수립할 때는 복구 시간 목표(RTO)와 복구 시점 목표(RPO)를 고려해야 한다. 일반적으로 다음과 같은 방법들을 조합하여 사용한다.

복구 절차를 검증하기 위해 정기적으로 복구 드릴을 수행하는 것이 좋다. 또한, 백업 파일의 무결성을 확인하고 안전한 오프사이트 저장소에 보관하는 것이 필수적이다. 샤딩이 구성된 클러스터 환경에서는 각 샤드별 백업과 구성 서버의 메타데이터 백업을 동기화해야 정상적인 복구가 가능하다.

MongoDB의 운영 상태를 확인하고 성능을 최적화하기 위해 다양한 공식 및 서드파티 모니터링 도구를 사용할 수 있다. 주요 지표로는 쿼리 성능, 연결 수, 메모리 및 디스크 사용량, 복제 지연 시간, 오플로그 크기 등이 포함된다.

MongoDB는 자체적인 클라우드 기반 모니터링 서비스인 Atlas를 제공하며, 여기에는 실시간 성능 차트, 사용자 정의 알림, 자동화된 성능 분석 기능이 포함되어 있다. 온프레미스 또는 다른 클라우드 환경에서는 `mongostat`과 `mongotop` 같은 명령줄 도구를 사용해 실시간 통계를 확인할 수 있다. 또한, `db.currentOp()` 및 `db.serverStatus()`와 같은 데이터베이스 명령을 통해 상세한 런타임 정보를 얻을 수 있다.

널리 사용되는 서드파티 모니터링 솔루션으로는 다음이 있다.

효과적인 모니터링을 위해서는 애플리케이션의 사용 패턴에 맞는 기준선을 설정하고, 느린 쿼리 로그를 정기적으로 검토하며, 용량 계획을 위한 추세를 분석하는 것이 중요하다.

MongoDB는 JSON과 유사한 BSON 문서 형식을 사용하는 문서 지향 데이터베이스이다. 이 구조는 특정한 사용 사례에서 뛰어난 적합성을 보인다.

첫째, 빠른 프로토타이핑과 빈번한 스키마 변경이 필요한 애플리케이션에 이상적이다. 스키마리스 또는 유연한 스키마 특성 덕분에 개발 초기 단계나 애자일 개발 환경에서 데이터 모델을 쉽게 반복하고 수정할 수 있다. 둘째, 반정형 또는 비정형 데이터를 처리해야 하는 경우에 강점을 발휘한다. 콘텐츠 관리 시스템, 사용자 프로필 저장소, 로그 데이터 수집, IoT 센서 데이터와 같이 필드 구성이 다양하거나 시간에 따라 진화하는 데이터를 저장하는 데 효율적이다. 또한, 수평 확장이 쉬운 샤딩 아키텍처를 통해 대규모 데이터 세트와 높은 쓰기 처리량을 요구하는 애플리케이션, 예를 들어 모바일 앱 백엔드, 실시간 분석 플랫폼, 카탈로그 관리 시스템 등을 구축하는 데 적합하다.

다음 표는 MongoDB가 특히 잘 맞는 몇 가지 구체적인 시나리오를 정리한 것이다.

마지막으로, 집계 파이프라인은 복잡한 데이터 변환과 분석을 가능하게 하여, 단일 데이터베이스 내에서 운영 워크로드와 일부 분석 워크로드를 모두 처리하는 운영 데이터 저장소 용도로도 사용된다. 이는 마이크로서비스 아키텍처에서 각 서비스의 독립적인 데이터 저장소로 채택되는 경우가 많다.

MongoDB는 스키마 유연성과 수평 확장성 덕분에 다양한 애플리케이션에 적합하지만, 모든 유형의 데이터 작업에 최적화되어 있지는 않다. 특히 복잡한 트랜잭션 처리나 엄격한 데이터 무결성이 요구되는 시나리오에서는 사용이 제한될 수 있다.

다음과 같은 경우 MongoDB의 사용이 부적합하거나 주의가 필요하다.

또한, MongoDB는 메모리 기반 작업을 선호하는 설계를 가지고 있다. 디스크 I/O가 매우 빈번하고 대용량의 순차적 쓰기 작업이 주를 이루는 시스템(예: 고전적 데이터 웨어하우스나 대량 로그 처리)에서는 전용 컬럼 기반 데이터베이스나 시계열 데이터베이스에 비해 성능이 떨어질 수 있다. 결국, 데이터 모델과 애플리케이션의 접근 패턴을 신중히 평가한 후 기술 선택을 해야 한다.