DynamoDB vs MongoDB

DynamoDB와 MongoDB 중 무엇을 써야 하나요?

예측 가능한 키 기반 액세스 패턴과 손이 가지 않는 확장을 갖춘, AWS 상의 완전 관리형 서버리스 키-값 및 문서 저장소를 원한다면 DynamoDB를 선택하십시오. 유연한 임의 쿼리, 풍부한 집계 파이프라인, 그리고 자체 호스팅하거나 주요 클라우드 어디서나 관리형으로 실행하는 옵션을 갖춘 문서 데이터베이스를 원한다면 MongoDB를 선택하십시오. 결정은 액세스 패턴이 합니다.

DynamoDB vs MongoDB 한눈에 보기

특성	DynamoDB	MongoDB
데이터 모델	NoSQL 키-값 및 문서, 테이블에 묶인 항목, 각 항목 최대 400 KB	문서 데이터베이스, 컬렉션에 묶인 최대 16 MB의 BSON(JSON 유사) 문서
쿼리 언어 / API	네이티브 API(`GetItem`, `Query`, `Scan`, `PutItem`, …)와 SQL 호환 쿼리 언어인 PartiQL	MongoDB Query API(MQL)와 다단계 변환, 조인(`$lookup`), 그룹화를 위한 집계 파이프라인
주요 액세스 패턴	파티션 키(및 선택적 정렬 키)에 대한 키 기반 조회, 알려진 액세스 패턴을 중심으로 사전 설계된 스키마	모든 필드에 대한 유연한 쿼리, 인덱스로 뒷받침되는 임의 필터와 집계
보조 인덱스	글로벌 보조 인덱스(자체 처리량, 임의 키)와 로컬 보조 인덱스(동일 파티션 키, 파티션당 10 GB 한도)	복합, 멀티키, 텍스트, 지리 공간, 와일드카드 인덱스를 포함한 모든 필드에 대한 보조 인덱스
일관성 모델	기본적으로 최종적 일관성 읽기, 요청별로 강력한 일관성 읽기 사용 가능(단일 AWS 리전 내)	조정 가능한 읽기/쓰기 관심사, 기본적으로 프라이머리에서의 읽기는 강력한 일관성
확장 모델	AWS가 관리하는 자동 파티셔닝, 서버 프로비저닝 없이 처리량과 스토리지 확장	클러스터 전반의 샤딩을 통한 수평 확장, 복제본 세트가 고가용성과 장애 조치 제공
트랜잭션	단일 AWS 리전으로 범위가 한정된, 여러 항목에 걸친 ACID 트랜잭션	다중 문서 ACID 트랜잭션(4.0부터), 샤드 간 트랜잭션 포함(4.2부터)
요금제	요청당 지불(온디맨드) 또는 프로비저닝된 용량, 스토리지 별도, 운영할 서버 없음	Atlas는 클러스터 기반(인스턴스 크기/시간)에 저비용 Flex 티어, 자체 호스팅 Community 에디션은 인프라 비용만 부담
관리형 / 서버리스 옵션	완전 서버리스 및 완전 관리형, AWS에서만 사용 가능	AWS, Google Cloud, Azure에서의 Atlas 관리형 서비스, 자체 호스팅도 가능. Atlas Serverless 인스턴스는 폐지되어 Flex 티어로 대체됨
최적 워크로드	일관된 저지연과 최소 운영이 필요한 예측 가능한 키 액세스의 대규모 앱	진화하는 스키마, 임의 쿼리와 풍부한 집계를 가진 앱, 또는 멀티 클라우드 / 온프레미스 이식성이 필요한 앱

DynamoDB가 더 나은 선택일 때

AWS 위에 있고 데이터베이스 운영을 전혀 하고 싶지 않은 경우. DynamoDB는 서버리스여서 패치할 인스턴스, 클러스터, 용량이 없습니다. 온디맨드 모드는 트래픽에 맞춰 자동으로 확장됩니다(용량 모드).
액세스 패턴이 알려져 있고 키 기반인 경우. 데이터를 읽는 방식을 중심으로 키를 설계할 수 있으면, DynamoDB는 사실상 어떤 규모에서도 일관된 저지연 조회를 제공합니다. 바로 이 지점에서 단일 테이블 설계가 빛을 발합니다.
요청당 지불 요금제를 원하는 경우. 온디맨드 용량에서는 수행한 읽기와 쓰기에 대해서만 지불하며, 유휴 클러스터 비용이 없습니다.
긴밀한 AWS 통합이 필요한 경우. IAM, Lambda, 스트림, 더 넓은 AWS 생태계와의 네이티브 연결이 접착 코드를 줄여 줍니다.

MongoDB가 더 나은 선택일 때

쿼리가 임의적이거나 탐색적인 경우. MongoDB는 모든 필드에 필터와 인덱스를 걸 수 있고, 모든 액세스 패턴을 사전 계획하지 않고도 컬렉션 간 조인을 포함한 풍부한 서버 측 집계를 실행할 수 있습니다.
클라우드 간 또는 온프레미스 이식성이 필요한 경우. MongoDB는 자체 호스팅하거나 AWS, Google Cloud, Azure 전반의 Atlas에서 실행됩니다. DynamoDB는 AWS 전용입니다.
문서가 크거나 깊게 중첩된 경우. MongoDB의 16 MB 문서 상한은 DynamoDB의 400 KB 항목 한도보다 훨씬 큽니다(DynamoDB 제약).
스키마가 빠르게 진화하는 경우. 유연한 문서와 일급 보조 인덱싱은 엄격한 사전 키 설계 없이도 빠르게 변화하는 모델에 적합합니다.

DynamoDB로 작업하기

DynamoDB를 선택했더라도, 일상적으로 테이블을 탐색하고 쿼리를 실행하고 항목을 편집할 빠른 방법이 여전히 필요합니다. DynoTable은 DynamoDB용 네이티브 데스크톱 GUI입니다. 항목을 탐색하고 인라인으로 편집하고, 키 조건과 필터를 구성하며, SQL 워크벤치와 AI 어시스턴트로 쿼리할 수 있습니다. MongoDB의 "무엇이든 쿼리하는" 사고방식에서 넘어온다면, SQL 워크벤치가 DynamoDB의 액세스 패턴 규칙 안에 머물면서 관계형 형태의 쿼리를 표현하도록 돕습니다.

문서를 벗어나지 않고 표현식을 만들고 싶다면, 무료 DynamoDB Expression Builder가 붙여넣을 준비가 된 SDK, CLI, PartiQL 출력과 함께 키 조건, 필터, 업데이트 표현식을 생성합니다. 그리고 키-값 저장소를 위한 모델링이 처음이라면, DynamoDB에서 데이터를 모델링하는 방법 가이드가 엔터티와 액세스 패턴을 키로 옮기는 과정을 단계별로 안내합니다.

FAQ

DynamoDB가 MongoDB보다 빠른가요?

어느 쪽도 무조건 더 빠르지는 않습니다. 워크로드와 데이터를 어떻게 모델링하는지에 달려 있습니다. DynamoDB는 키 기반 액세스에 대해 대규모에서 일관된 저지연 성능을 제공하도록 설계되었고, MongoDB는 인덱스된 쿼리와 임의 쿼리에 대해 매우 빠를 수 있습니다. 실제 지연 시간에는 엔진보다 올바른 데이터 모델이 더 중요합니다.

DynamoDB가 MongoDB를 대체할 수 있나요?

경우에 따라 가능합니다. 액세스 패턴이 예측 가능하고 키 기반이라면, DynamoDB가 MongoDB를 대체하고 대부분의 운영 부담을 제거할 수 있습니다. 여러 필드에 걸친 임의 쿼리나 서버 측 집계에 의존한다면, 마이그레이션은 먼저 데이터를 DynamoDB의 키를 중심으로 다시 모델링해야 한다는 뜻입니다. DynamoDB에서 데이터를 모델링하는 방법을 참고하십시오.

DynamoDB는 MongoDB를 기반으로 하나요?

아닙니다. 둘은 서로 다른 회사의 무관한 제품입니다. DynamoDB는 설계 계보가 Amazon의 내부 Dynamo 작업으로 거슬러 올라가는 AWS 관리형 데이터베이스이고, MongoDB는 오픈 소스에 뿌리를 둔 별개의 문서 데이터베이스입니다. 둘은 "NoSQL"이라는 이름을 공유하지만 코드베이스는 공유하지 않습니다.