기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon DocumentDB(MongoDB 호환)란 무엇인가
Amazon DocumentDB(MongoDB와 호환됨)는 빠르고 안정적이며 완전 관리형 데이터베이스 서비스입니다. Amazon DocumentDB를 사용하면 클라우드에서 MongoDB 호환 데이터베이스를 쉽게 설치, 운영 및 규모를 조정할 수 있습니다. Amazon DocumentDB를 사용하면 MongoDB에서 사용하는 것과 동일한 애플리케이션 코드를 실행하고 동일한 드라이버와 도구를 사용할 수 있습니다.
Amazon DocumentDB를 사용하기 전에 [작동 방식](how-it-works.md)에 설명된 개념과 기능을 검토해야 합니다. 그 이후에는 [시작 안내서](get-started-guide.md)의 단계를 완료합니다.
**Topics**
+ [개요](#overview)
+ [클러스터](#what-is-db-clusters)
+ [인스턴스](#what-is-db-instances)
+ [리전 및 가용 영역](#what-is-regions-and-azs)
+ [가격 책정](#docdb-pricing)
+ [모니터링](#what-is-monitoring)
+ [인터페이스](#what-is-interfaces)
+ [다음 단계](#what-is-next)
+ [작동 방식](how-it-works.md)
+ [문서 데이터베이스란?](what-is-document-db.md)
## Amazon DocumentDB 개요
다음은 Amazon DocumentDB의 일부 고급 기능입니다.
+ Amazon DocumentDB는 인스턴스 기반 클러스터와 탄력적 클러스터라는 두 가지 유형의 클러스터를 지원합니다. 탄력적 클러스터는 초당 수백만 읽기/쓰기 및 페타바이트의 스토리지 용량을 갖춘 워크로드를 지원합니다. 탄력적 클러스터에 대한 자세한 내용은 [Amazon DocumentDB 탄력적 클러스터 사용](docdb-using-elastic-clusters.md)을 참조하세요. 아래 내용은 Amazon DocumentDB 인스턴스 기반 클러스터를 참조합니다.
+ Amazon DocumentDB는 데이터베이스 스토리지가 증가함에 따라 스토리지 볼륨의 크기를 자동으로 증가시킵니다. 스토리지 볼륨은 10GB, 최대 128TiB까지 증가합니다. 향후 증가를 처리하기 위해 클러스터에 추가 스토리지를 프로비저닝할 필요가 없습니다.
+ Amazon DocumentDB를 사용하면 최대 15개의 복제본 인스턴스를 생성하여 읽기 처리량을 높여 높은 볼륨의 애플리케이션 요청을 지원할 수 있습니다. Amazon DocumentDB 복제본은 동일한 기본 스토리지를 공유하므로 비용이 절감되고 복제본 노드에서 쓰기를 수행할 필요가 없습니다. 이 기능을 사용하면 읽기 요청을 처리할 수 있는 처리 능력이 향상되고 복제본 지연 시간이 최대 한 자릿수 밀리초로 단축됩니다. 스토리지 볼륨 크기에 관계없이 몇 분 안에 복제본을 추가할 수 있습니다. 또한 Amazon DocumentDB는 리더 엔드포인트를 제공하므로 애플리케이션이 복제본이 추가 및 제거될 때 추적할 필요 없이 연결할 수 있습니다.
+ Amazon DocumentDB를 사용하면 각 인스턴스의 계산 및 메모리 리소스를 위 또는 아래로 확장할 수 있습니다. 컴퓨팅 조정 작업은 일반적으로 몇 분이면 완료됩니다.
+ Amazon DocumentDB는 Amazon Virtual Private Cloud(Amazon VPC)에서 실행되므로 데이터베이스를 자체 가상 네트워크에서 격리할 수 있습니다. 또한 클러스터에 대한 네트워크 액세스를 제어하도록 방화벽 설정을 구성할 수 있습니다.
+ Amazon DocumentDB는 지속적으로 클러스터 상태를 모니터링합니다. 인스턴스 장애 발생 시 Amazon DocumentDB는 인스턴스 및 관련 프로세스를 자동으로 재시작합니다. Amazon DocumentDB는 데이터베이스 다시 실행 로그의 충돌 복구 재생이 필요하지 않으므로 재시작 시간이 크게 단축됩니다. 또한 Amazon DocumentDB는 데이터베이스 프로세스에서 데이터베이스 캐시를 분리하여 인스턴스를 다시 시작해도 캐시가 계속 유지되도록 합니다.
+ 인스턴스 장애 시에서는 Amazon DocumentDB는 다른 가용 영역에서 작성하는 최대 15개의 Amazon DocumentDB 복제본 중 하나로 장애 조치를 자동화합니다. 복제본이 프로비저닝되지 않은 상태에서 오류가 발생하면 Amazon DocumentDB는 자동으로 새 Amazon DocumentDB 인스턴스를 작성하려고 합니다.
+ Amazon DocumentDB의 백업 기능은 클러스터의 시점 복구를 가능하게 합니다. 이 기능을 통해 클러스터를 보존 기간 중 어느 시점(초)으로나 복원할 수 있습니다(마지막 5분까지 가능). 자동 백업 보존 기간은 최대 35일까지 구성할 수 있습니다. 자동 백업은 99.999999999% 의 내구성을 제공하도록 설계된 Amazon Simple Simple S3 Service(Amazon Simple S3)에 저장됩니다. Amazon DocumentDB 백업은 자동, 증분 및 지속적이며 클러스터 성능에 영향을 주지 않습니다.
+ Amazon DocumentDB를 사용하면 AWS Key Management Service ()를 통해 생성하고 제어하는 키를 사용하여 데이터베이스를 암호화할 수 있습니다AWS KMS. Amazon DocumentDB 암호화와 함께 실행되는 데이터베이스 클러스터에서는 기본 저장소에 저장된 정지 상태의 데이터가 암호화됩니다. 동일한 클러스터에 있는 자동화된 백업, 스냅샷 및 복제본도 암호화됩니다.
+ Amazon DocumentDB는 연방정 위험 및 인증 관리 프로그램(FedRAMP)에 따라 권한이 부여됩니다. 여기에는 AWS GovCloud(미국) 리전에 대한 FedRAMP High 권한 부여와 AWS 미국 동부/서부 리전에 대한 FedRAMP Moderate 권한이 있습니다. AWS 및 규정 준수 노력에 대한 자세한 내용은 [AWS 규정 준수 프로그램 제공 범위 내 서비스를 참조하세요](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/).
AWS 서비스를 처음 사용하는 경우 다음 리소스를 사용하여 자세히 알아보세요.
+ AWS 는 컴퓨팅, 데이터베이스, 스토리지, 분석 및 기타 기능을 위한 서비스를 제공합니다. 모든 AWS 서비스에 대한 개요는 [Amazon Web Services를 사용한 클라우드 컴퓨팅을 참조하세요](https://aws.amazon.com/what-is-aws/).
+ AWS 는 여러 데이터베이스 서비스를 제공합니다. 환경에 가장 적합한 서비스에 대한 지침은 [AWS의 데이터베이스](https://aws.amazon.com/products/databases/)를 참조하십시오.
## 클러스터
*클러스터*는 0\$116개의 인스턴스와 해당 인스턴스의 데이터를 관리하는 클러스터 스토리지 볼륨으로 구성됩니다. 모든 쓰기는 기본 인스턴스를 통해 수행됩니다. 모든 인스턴스(기본 및 복제본)는 읽기를 지원합니다. 클러스터의 데이터는 클러스터 볼륨에 저장되며 복사본은 세 개의 다른 가용 영역에 있습니다.
![\[가용 영역 1에 기본 인스턴스가 포함된 Amazon DocumentDB 클러스터, 영역 2와 3에 있는 복사본의 클러스터 볼륨에 쓰기입니다.\]](http://docs.aws.amazon.com/ko_kr/documentdb/latest/developerguide/images/how-it-works-01c.png)
Amazon DocumentDB 5.0 인스턴스 기반 클러스터는 데이터베이스 클러스터에 대해 Amazon DocumentDB 표준 및 Amazon DocumentDB I/O 최적화라는 두 가지 스토리지 구성을 지원합니다. 자세한 내용은 [Amazon DocumentDB 클러스터 스토리지 구성](db-cluster-storage-configs.md)을 참조하세요.
## 인스턴스
Amazon DocumentDB 인스턴스는 클라우드에 있는 격리된 데이터베이스 환경입니다. 인스턴스에는 사용자가 만든 여러 개의 데이터베이스가 포함될 수 있습니다. AWS Management Console 또는를 사용하여 인스턴스를 생성하고 수정할 수 있습니다 AWS CLI.
인스턴스의 계산 및 메모리 용량은 *인스턴스 클래스*에 따라 결정됩니다. 사용자의 요구 사항에 가장 잘 맞는 인스턴스를 선택할 수 있습니다. 시간이 지나면서 요구 사항이 바뀌면 다른 인스턴스 클래스를 선택할 수 있습니다. 인스턴스 클래스 사양은 [인스턴스 클래스 사양](db-instance-classes.md#db-instance-class-specs)을 참조하십시오.
Amazon DocumentDB 인스턴스는 Amazon VPC 환경에서만 실행됩니다. Amazon VPC를 사용하면 가상 네트워킹 환경을 제어할 수 있습니다. 자신의 IP 주소 범위를 선택하고 서브넷을 생성하며 라우팅 및 액세스 제어 목록(ACL)을 구성할 수 있습니다.
Amazon DocumentDB 인스턴스를 작성하려면 먼저 인스턴스를 포함할 클러스터를 작성해야 합니다.
모든 리전에서 모든 인스턴스 클래스가 지원되지는 않습니다. 다음 표에는 각 리전에서 지원하는 인스턴스 클래스가 나와 있습니다.
**참고**
각 인스턴스 클래스에서 Amazon DocumentDB가 지원하는 인스턴스 유형의 전체 목록은 [인스턴스 클래스 사양](db-instance-classes.md#db-instance-class-specs) 섹션을 참조하세요.
**리전별 지원되는 인스턴스 클래스**
| | 인스턴스 클래스 | 리전 | R8G | R6GD | R6G | R5 | R4 | T4G | T3 | 서버리스 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 미국 동부(오하이오) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 |
| 미국 동부(버지니아 북부) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 |
| 미국 서부(오리건) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 |
| 아프리카(케이프타운) | | | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 남아메리카(상파울루) | | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 아시아 태평양(홍콩) | | | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 아시아 태평양(하이데라바드) | | | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 아시아 태평양(말레이시아) | | | 지원됨 | | | 지원됨 | 지원됨 | |
| 아시아 태평양(뭄바이) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 아시아 태평양(오사카) | | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | |
| 아시아 태평양(서울) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 아시아 태평양(시드니) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 아시아 태평양(자카르타) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | |
| 아시아 태평양(멜버른) | | | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | |
| 아시아 태평양(싱가포르) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 아시아 태평양(태국) | | | 지원됨 | | | 지원됨 | 지원됨 | |
| 아시아 태평양(도쿄) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 캐나다(중부) | | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 유럽(프랑크푸르트) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 유럽(취리히) | | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | |
| 유럽(아일랜드) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 | 지원됨 |
| 유럽(런던) | | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 유럽(밀라노) | | | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 유럽(파리) | | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 유럽(스페인) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 유럽(스톡홀름) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | |
| 멕시코(중부) | | | 지원됨 | | | 지원됨 | 지원됨 | |
| 중동(UAE) | | | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 중국(베이징) | | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 중국(닝샤) | | | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| 이스라엘(텔아비브) | | | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| AWS GovCloud(미국 서부) | 지원됨 | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
| AWS GovCloud(미국 동부) | | 지원됨 | 지원됨 | 지원됨 | | 지원됨 | 지원됨 | 지원됨 |
## 리전 및 가용 영역
리전 및 가용 영역은 클러스터 및 인스턴스의 물리적 위치를 정의합니다.
### 리전
AWS 클라우드 컴퓨팅 리소스는 전 세계 여러 지역(예: 북미, 유럽 또는 아시아)의 고가용성 데이터 센터 시설에 있습니다. 각 데이터 센터 위치를 *리전*이라고 합니다.
각 AWS 리전은 다른 AWS 리전과 완전히 격리되도록 설계되었습니다. 각 리전 내에는 가용 영역이 여러 개 있습니다. 서로 다른 가용 영역에서 노드를 시작하면 가능한 최고 수준의 내결함성을 갖출 수 있습니다. 다음 다이어그램은 AWS 리전 및 가용 영역의 작동 방식을 개괄적으로 보여줍니다.
![\[AWS 리전 및 가용 영역에 대한 Amazon DocumentDB 상위 수준 보기입니다.\]](http://docs.aws.amazon.com/ko_kr/documentdb/latest/developerguide/images/docdb-regions-and-azs.png)
### 가용 영역
각 AWS 리전에는 *가용 영역이라는 고유한 위치가 여러 개 포함되어 있습니다*. 각 가용 영역은 다른 가용 영역의 장애로부터 격리되고 같은 리전의 다른 가용 영역에 경제적이고 지연 시간이 낮은 네트워크 연결을 제공하도록 엔지니어링됩니다. 여러 가용 영역에서 특정 클러스터에 대한 인스턴스를 시작하면 가용 영역에 드물게라도 장애가 발생할 경우 애플리케이션을 보호할 수 있습니다.
Amazon DocumentDB 아키텍처는 스토리지와 컴퓨팅을 분리합니다. 스토리지 계층의 경우 Amazon DocumentDB는 3개의 AWS 가용 영역에 걸쳐 6개의 데이터 사본을 복제합니다. 예를 들어, 두 개의 가용 영역만 지원하는 영역에서 Amazon DocumentDB 클러스터를 시작하는 경우 데이터 스토리지는 세 개의 가용 영역에 걸쳐 6가지 방식으로 복제되지만 컴퓨팅 인스턴스는 두 개의 가용 영역에서만 사용할 수 있습니다.
다음 표에는 지정된에서 클러스터의 컴퓨팅 인스턴스를 프로비저닝하는 AWS 리전 데 사용할 수 있는 가용 영역 수가 나열되어 있습니다.
| 리전 이름 | 리전 | 가용 영역(컴퓨팅) |
| --- | --- | --- |
| 미국 동부(오하이오) | `us-east-2` | 3 |
| 미국 동부(버지니아 북부) | `us-east-1` | 6 |
| 미국 서부(오리건) | `us-west-2` | 4 |
| 아프리카(케이프타운) | `af-south-1` | 3 |
| 남아메리카(상파울루) | `sa-east-1` | 3 |
| 아시아 태평양(홍콩) | `ap-east-1` | 3 |
| 아시아 태평양(하이데라바드) | `ap-south-2` | 3 |
| 아시아 태평양(말레이시아) | `ap-southeast-5` | 3 |
| 아시아 태평양(뭄바이) | `ap-south-1` | 3 |
| 아시아 태평양(오사카) | `ap-northeast-3` | 3 |
| 아시아 태평양(서울) | `ap-northeast-2` | 4 |
| 아시아 태평양(싱가포르) | `ap-southeast-1` | 3 |
| 아시아 태평양(시드니) | `ap-southeast-2` | 3 |
| 아시아 태평양(자카르타) | `ap-southeast-3` | 3 |
| 아시아 태평양(멜버른) | `ap-southeast-4` | 3 |
| 아시아 태평양(태국) | `ap-southeast-7` | 3 |
| 아시아 태평양(도쿄) | `ap-northeast-1` | 3 |
| 캐나다(중부) | `ca-central-1` | 3 |
| 중국(베이징) 리전 | `cn-north-1` | 3 |
| 중국(닝샤) | `cn-northwest-1` | 3 |
| 유럽(프랑크푸르트) | `eu-central-1` | 3 |
| 유럽(취리히) | `eu-central-2` | 3 |
| 유럽(아일랜드) | `eu-west-1` | 3 |
| 유럽(런던) | `eu-west-2` | 3 |
| 유럽(밀라노) | `eu-south-1` | 3 |
| 유럽(파리) | `eu-west-3` | 3 |
| 유럽(스페인) | `eu-south-2` | 3 |
| 유럽(스톡홀름) | `eu-north-1` | 3 |
| 멕시코(중부) | `mx-central-1` | 3 |
| 중동(UAE) | `me-central-1` | 3 |
| 이스라엘(텔아비브) | `il-central-1` | 3 |
| AWS GovCloud(미국 서부) | `us-gov-west-1` | 3 |
| AWS GovCloud(미국 동부) | `us-gov-east-1` | 3 |
## Amazon DocumentDB 요금
Amazon DocumentDB 클러스터는 다음 구성 요소를 기준으로 청구됩니다.
+ **인스턴스 시간(시간당)**—인스턴스의 인스턴스 클래스(예: `db.r5.xlarge`)를 기준으로 합니다. 요금은 시간 단위로 고시되지만, 청구서는 초 단위로 계산되고 시간을 10진수 형식으로 표시합니다. Amazon DocumentDB 사용량은 최소 10분을 기준으로 1초 단위로 청구됩니다. 자세한 내용은 [인스턴스 클래스 관리](db-instance-classes.md) 단원을 참조하십시오.
+ **I/O 요청(매월 100만 건당 요청)** — 청구 주기 내에 수행하는 총 스토리지 I/O 요청 수.
+ **백업 저장소(배월 단위 GiB)** - 백업 저장소는 자동화된 데이터베이스 백업 및 사용 중인 데이터베이스 스냅샷과 관련된 저장소입니다. 백업 보존 기간을 연장하거나 추가 데이터베이스 스냅샷을 찍으면 데이터베이스가 사용하는 백업 스토리지가 증가합니다. 백업 스토리지는 GB-월 단위로 측정되며 초당으로 적용되지 않습니다. 자세한 내용은 [Amazon DocumentDB에서 백업 및 복원](backup_restore.md) 단원을 참조하십시오.
+ **데이터 전송(GB당) **- 인터넷 또는 기타 AWS 리전에서 인스턴스 안팎으로 데이터를 전송합니다.
자세한 내용은 [Amazon DocumentDB 요금](https://aws.amazon.com/documentdb/pricing/)을 참조하십시오.
### 무료 평가판
1개월 무료 평가판을 사용하여 Amazon DocumentDB를 무료로 사용해 볼 수 있습니다. 자세한 내용은 [Amazon DocumentDB 요금](https://aws.amazon.com/documentdb/pricing/)의 무료 평가판을 참조하거나 [Amazon DocumentDB 무료 평가판 FAQ](https://aws.amazon.com/documentdb/free-trial/)를 참조하십시오.
## 모니터링
인스턴스의 성능과 상태를 추적할 수 있는 여러 가지 방법이 있습니다. 무료 Amazon CloudWatch 서비스를 사용하여 인스턴스의 성능과 상태를 모니터링할 수 있습니다. 성능 차트는 Amazon DocumentDB 콘솔에서 찾을 수 있습니다. 인스턴스, 스냅샷, 파라미터 그룹 또는 보안 그룹에서 변경 사항이 발생할 때 알려줄 Amazon DocumentDB 이벤트에 가입할 수 있습니다.
자세한 내용은 다음을 참조하세요.
+ [CloudWatch를 사용하여 Amazon DocumentDB 모니터링](cloud_watch.md)
+ [AWS CloudTrail로 Amazon DocumentDB API 호출 로깅](logging-with-cloudtrail.md)
## 인터페이스
AWS Management Console 및를 포함하여 Amazon DocumentDB와 상호 작용하는 방법에는 여러 가지가 있습니다 AWS CLI.
### AWS Management Console
AWS Management Console 는 간단한 웹 기반 사용자 인터페이스입니다. 콘솔에서 프로그래밍 없이 클러스터 및 인스턴스를 관리할 수 있습니다. Amazon DocumentDB 콘솔에 액세스하려면에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) Amazon DocumentDB 콘솔을 엽니다.
### AWS CLI
AWS Command Line Interface (AWS CLI)를 사용하여 Amazon DocumentDB 클러스터 및 인스턴스를 관리할 수 있습니다. 최소한의 구성으로 원하는 터미널 프로그램에서 Amazon DocumentDB 콘솔에서 제공하는 모든 기능을 사용할 수 있습니다.
+ 를 설치하려면 명령줄 인터페이스 설치를 AWS CLI참조하세요. [AWS](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
+ Amazon DocumentDB AWS CLI 용 사용을 시작하려면 [AWS Amazon DocumentDB용 명령줄 인터페이스 참조](https://docs.aws.amazon.com/cli/latest/reference/docdb/index.html)를 참조하세요.
### MongoDB 드라이버
Amazon DocumentDB 클러스터에서 애플리케이션을 개발하고 작성하는 경우, MongoDB 드라이버를 Amazon DocumentDB와 함께 사용할 수도 있습니다. 자세한 내용은 [TLS가 활성화된 상태에서 연결](connect_programmatically.md#connect_programmatically-tls_enabled) 또는 [TLS가 비활성화된 상태에서 연결](connect_programmatically.md#connect_programmatically-tls_disabled)의 MongoDB 쉘 탭을 참조하세요.
## 다음 단계
앞 섹션에서는 Amazon DocumentDB가 제공하는 기본 인프라 구성 요소에 대해 소개했습니다. 다음으로 무엇을 해야 할까요? 환경에 따라 시작하려면 다음 주제 중 하나를 참조하십시오.
+ 를 사용하여 클러스터와 인스턴스를 생성하여 Amazon DocumentDB를 시작합니다 CloudFormation [를 사용한 Amazon DocumentDB 빠른 시작 CloudFormation](quick_start_cfn.md).
+ [시작 안내서](get-started-guide.md)의 지침에 따라 클러스터 및 인스턴스를 생성하여 Amazon DocumentDB를 시작하십시오.
+ [Amazon DocumentDB 엘라스틱 클러스터 시작하기](elastic-get-started.md)의 지침에 따라 탄력적 클러스터를 생성하여 Amazon DocumentDB를 시작하십시오.
+ [Amazon DocumentDB로 마이그레이션](docdb-migration.md)의 지침을 사용하여 MongoDB 구현을 Amazon DocumentDB로 마이그레이션하기
# Amazon DocumentDB: 작동 방식
Amazon DocumentDB(MongoDB와 호환됨)는 완전 관리형의 MongoDB와 호환됨 데이터베이스 서비스입니다. Amazon DocumentDB를 사용하면 MongoDB에서 사용하는 것과 동일한 애플리케이션 코드를 실행하고 동일한 드라이버와 도구를 사용할 수 있습니다. Amazon DocumentDB는 MongoDB 3.6, 4.0, 5.0 및 8.0과 호환됩니다.
**Topics**
+ [Amazon DocumentDB 엔드포인트](#how-it-works.endpoints)
+ [TLS 지원](#how-it-works.ssl)
+ [Amazon DocumentDB 스토리지](#how-it-works.storage)
+ [Amazon DocumentDB 복제](#how-it-works.replication)
+ [Amazon DocumentDB 신뢰성](#how-it-works.reliability)
+ [읽기 기본 설정 옵션](#durability-consistency-isolation)
+ [TTL 삭제](#how-it-works.ttl-deletes)
+ [청구 가능 리소스](#billing)
Amazon DocumentDB를 사용할 때는 *클러스터*를 생성하는 것부터 시작합니다. 클러스터는 0개 이상의 데이터베이스 인스턴스 및 이 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성됩니다. Amazon DocumentDB *클러스터 볼륨*은 여러 가용 영역에 걸쳐 있는 가상 데이터베이스 스토리지 볼륨입니다. 각 가용 영역마다 클러스터 데이터 복사본이 있습니다.
Amazon DocumentDB 클러스터는 다음 두 가지 구성 요소로 구성됩니다.
+ **클러스터 볼륨**—클라우드 네이티브 스토리지 서비스를 사용하여 3개의 가용 영역에 걸쳐 6가지 방식으로 데이터를 복제하여 내구성이 뛰어나고 가용성이 뛰어난 스토리지를 제공합니다. Amazon DocumentDB 클러스터는 하나의 클러스터 볼륨을 가지고 있으며, 최대 128TiB의 데이터를 저장할 수 있습니다.
+ **인스턴스**—데이터베이스에 대한 처리 능력을 제공하고, 데이터를 클러스터 스토리지 볼륨에 쓰고, 데이터를 읽어냅니다. Amazon DocumentDB 클러스터에는 0\$116개의 인스턴스가 있을 수 있습니다.
인스턴스는 두 가지 역할 중 하나를 수행합니다.
+ **기본 인스턴스**—읽기 및 쓰기 작업을 지원하고 클러스터 볼륨에 대한 모든 데이터 수정을 수행합니다. 각 Amazon DocumentDB 클러스터에는 기본 인스턴스가 하나씩 있습니다.
+ **복제본 인스턴스** - 읽기 작업만 지원합니다. Amazon DocumentDB 클러스터는 기본 인스턴스 외에 최대 15개의 복제본을 가질 수 있습니다. 복제본이 여러 개 있으면 읽기 워크로드를 분산시킬 수 있습니다. 또한 복제본을 별도의 가용 영역에 두어 클러스터 가용성을 높일 수 있습니다.
다음 다이어그램은 Amazon DocumentDB 클러스터의 클러스터 볼륨, 기본 인스턴스 및 복제본 간의 관계를 보여줍니다:
![\[클러스터, 리더 및 인스턴스 엔드포인트를 포함하는 Amazon DocumentDB 엔드포인트입니다.\]](http://docs.aws.amazon.com/ko_kr/documentdb/latest/developerguide/images/docdb-endpoint-types.png)
클러스터 인스턴스의 인스턴스 클래스가 같을 필요는 없으며 이 인스턴스를 원하는 대로 프로비저닝하고 종료할 수 있습니다. 이 아키텍처를 사용하여 클러스터 컴퓨팅 파워를 스토리지와 별개로 확장할 수 있습니다.
애플리케이션이 기본 인스턴스에 데이터를 쓸 때 기본 인스턴스는 클러스터 볼륨에 내구성 있는 쓰기를 실행합니다. 그런 다음 각 활성 복제본에 해당 쓰기 상태(데이터 제외)를 복제합니다. Amazon DocumentDB 복제본은 쓰기 처리에 관여하지 않으므로 Amazon DocumentDB 복제본은 읽기 확장에 유리합니다. Amazon DocumentDB 복제본에서의 읽기 작업은 최종적으로 복제본 지연 시간을 최소화하면서 일관되게 이루어지는데, 이는 기본 인스턴스가 데이터를 쓴 후 보통 100밀리초 미만입니다. 복제본에서 읽기는 기본 인스턴스에 쓰여진 순서대로 읽힙니다. 복제본 지연 시간은 데이터 변경 비율에 따라 달라지며 쓰기 작업 기간 집중적으로 일어나는 기간에는 복제본 지연 시간이 늘어날 수 있습니다. 자세한 내용은 [Amazon DocumentDB 지표](cloud_watch.md#cloud_watch-metrics_list)의 `ReplicationLag` 지표를 참조하십시오.
## Amazon DocumentDB 엔드포인트
Amazon DocumentDB는 다양한 사용 사례를 제공하기 위해 여러 연결 옵션을 제공합니다. Amazon DocumentDB 클러스터의 인스턴스에 연결하려면 인스턴스의 엔드포인트를 지정합니다. *엔드포인트*란 콜론으로 구분된 호스트 주소와 포트 번호입니다.
리더 엔드포인트 또는 인스턴스 엔드포인트에 연결하는 특정 사용 사례가 없는 경우 클러스터 엔드포인트를 사용하고 복제본 세트 모드([Amazon DocumentDB에 복제본 세트로 연결](connect-to-replica-set.md) 참조)에서 클러스터에 연결하는 것이 좋습니다. 요청을 복제본으로 라우팅하려면 애플리케이션의 읽기 일관성 요구 사항을 충족하면서 읽기 확장성을 최대화하는 드라이버 읽기 기본 설정을 선택합니다. `secondaryPreferred` 읽기 기본 설정은 복제본 읽기를 활성화하고, 더 많은 작업을 수행할 수 있도록 기본 인스턴스를 비웁니다.
Amazon DocumentDB 클러스터에서 사용할 수 있는 엔드포인트는 다음과 같습니다.
### 클러스터 엔드포인트
*클러스터 엔드포인트*는 클러스터의 현재 기본 인스턴스에 연결됩니다. 읽기 및 쓰기 작업에 클러스터 엔드포인트를 사용할 수 있습니다. Amazon DocumentDB 클러스터에는 클러스터 엔드포인트가 하나만 있습니다.
클러스터 엔드포인트는 클러스터에 대한 읽기 및 쓰기 연결에 장애 조치 지원을 제공합니다. 클러스터의 현재 기본 인스턴스가 실패하고 클러스터에 적어도 하나의 활성 읽기 전용 복제본이 있으면 클러스터 엔드포인트가 연결 요청을 새 기본 인스턴스에 자동으로 리디렉션합니다. Amazon DocumentDB 클러스터에 연결할 때는 클러스터 엔트포인트를 사용하여 복제본 설정 모드로 클러스터에 연결하는 것이 좋습니다([Amazon DocumentDB에 복제본 세트로 연결](connect-to-replica-set.md) 참조).
다음은 Amazon DocumentDB 클러스터 엔드포인트의 예제입니다.
```
sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017
```
다음은 이 클러스터 엔드포인트를 사용하는 연결 문자열 예제입니다.
```
mongodb://username:password@sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017
```
클러스터 엔드포인트 찾기에 대한 자세한 내용은 [클러스터 엔드포인트 찾기](db-cluster-endpoints-find.md) 단원을 참조하십시오.
### 리더 엔드포인트
*리더 엔드포인트*는 클러스터에 있는 사용 가능한 모든 복제본 간에 읽기 전용 연결을 로드 밸런싱합니다. `replicaSet` 모드를 통해 연결하는 경우 클러스터 리더 엔드포인트가 클러스터 엔드포인트로 작동합니다. 즉, 연결 문자열에서 복제본 세트 파라미터는 `&replicaSet=rs0`입니다. 이 경우 기본에서 쓰기 작업을 수행할 수 있습니다. 그러나 `directConnection=true`를 지정하는 클러스터에 연결하는 경우 리더 엔드포인트에 대한 연결을 통해 쓰기 작업을 수행하려고 하면 오류가 발생합니다. Amazon DocumentDB 클러스터에는 정확히 하나의 리더 엔트포인트가 있습니다.
클러스터에 기본 인스턴스 하나만 있는 경우 리더 엔드포인트가 기본 인스턴스에 연결합니다. 복제본 인스턴스를 Amazon DocumentDB 클러스터에 추가할 때, 리더 엔드포인트는 복제본이 활성화된 후 새 복제본에 대한 읽기 전용 연결을 엽니다.
다음은 Amazon DocumentDB 클러스터에 대한 리더 엔드포인트의 예제입니다.
```
sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com:27017
```
다음은 리더 엔드포인트를 사용하는 연결 문자열 예제입니다.
```
mongodb://username:password@sample-cluster.cluster-ro-123456789012.us-east-1.docdb.amazonaws.com:27017
```
리더 엔드포인트는 읽기 요청이 아닌 읽기 전용 연결을 로드 밸런싱합니다. 일부 리더 엔드포인트 연결이 다른 연결보다 매우 많이 사용되는 경우 읽기 요청이 클러스터의 인스턴스 간에 균등하게 밸런싱되지 않을 수 있습니다. 클러스터 엔드포인트에 복제본 세트로 연결하고 secondaryPreferred 읽기 기본 설정 옵션을 사용하여 요청을 분산하는 것이 좋습니다.
클러스터 엔드포인트 찾기에 대한 자세한 내용은 [클러스터 엔드포인트 찾기](db-cluster-endpoints-find.md) 단원을 참조하십시오.
### 인스턴스 엔드포인트
*인스턴스 엔드포인트*는 클러스터에 있는 특정 인스턴스에 연결됩니다. 읽기 및 쓰기 작업에 현재 기본 인스턴스의 인스턴스 엔드포인트를 사용할 수 있습니다.니다. 하지만 읽기 전용 복제본의 인스턴스 엔드포인트에 대한 쓰기 작업을 수행하려는 시도로 인해 오류가 발생합니다. Amazon DocumentDB 클러스터에는 활성 인스턴스당 하나의 인스턴스 엔드포인트가 있습니다.
클러스터 엔드포인트 또는 리더 엔드포인트가 부적합한 시나리오에서는 인스턴스 엔드포인트가 특정 인스턴스에 대한 연결을 직접 제어합니다. 예제 사용 사례에서는 주기적인 읽기 전용 분석 워크로드를 프로비저닝합니다. 일반 복제본 인스턴스보다 큰 인스턴스를 프로비저닝하고, 인스턴스 엔드포인트를 사용하여 더 큰 새 인스턴스에 직접 연결하며, 분석 쿼리를 실행한 후 인스턴스를 종료할 수 있습니다. 인스턴스 엔드포인트를 사용하면 분석 트래픽이 다른 클러스터 인스턴스에 영향을 주지 않습니다.
다음은 Amazon DocumentDB 클러스터의 단일 인스턴스에 대한 인스턴스 엔드포인트의 예입니다.
```
sample-instance.123456789012.us-east-1.docdb.amazonaws.com:27017
```
다음은 이 인스턴스 엔드포인트를 사용하는 연결 문자열 예제입니다.
```
mongodb://username:password@sample-instance.123456789012.us-east-1.docdb.amazonaws.com:27017
```
**참고**
장애 조치 이벤트로 인해 기본 또는 복제본으로서 인스턴스의 역할이 변경될 수 있습니다. 애플리케이션에서 특정 인스턴스 엔드포인트가 기본 인스턴스라고 가정해서는 안 됩니다. 프로덕션 애플리케이션의 경우 인스턴스 엔드포인트에 연결하지 않는 것이 좋습니다. 대신 클러스터 엔드포인트를 사용하고 복제본 세트 모드([Amazon DocumentDB에 복제본 세트로 연결](connect-to-replica-set.md) 참조)에서 클러스터에 연결하는 것이 좋습니다. 인스턴스 장애 조치 우선 순위의 고급 제어에 대한 자세한 내용은 [Amazon DocumentDB 클러스터 내결함성에 대한 이해](db-cluster-fault-tolerance.md) 단원을 참조하십시오.
클러스터 엔드포인트 찾기에 대한 자세한 내용은 [인스턴스의 엔드포인트 찾기](db-instance-endpoint-find.md) 단원을 참조하십시오.
### 복제본 세트 모드
복제본 세트 이름 `rs0`을 지정하여 복제본 세트 모드에서 Amazon DocumentDB 클러스터 엔드포인트에 연결할 수 있습니다. 복제본 세트 모드에서 연결하면 Read Concern(읽기 문제), Write Concern(쓰기 문제) 및 Read Preference(읽기 기본 설정) 옵션을 지정할 수 있습니다. 자세한 내용은 [읽기 정합성](#durability-consistency-isolation.read-consistency) 단원을 참조하십시오.
다음은 복제본 세트 모드에서 연결하는 예제 연결 문자열입니다.
```
mongodb://username:password@sample-cluster.cluster-123456789012.us-east-1.docdb.amazonaws.com:27017/?replicaSet=rs0
```
복제본 세트 모드로 연결하면 Amazon DocumentDB 클러스터가 복제본 세트로 드라이버와 클라이언트에 나타납니다. Amazon DocumentDB 클러스터에서 추가 및 제거된 인스턴스는 복제본 집합 구성에 자동으로 반영됩니다.
각 Amazon DocumentDB 클러스터는 기본 이름이 `rs0`인 단일 복제본 세트로 구성됩니다. 복제본 세트 이름은 수정할 수 없습니다.
일반적인 용도에서는 복제본 세트 모드에서 클러스터 엔드포인트에 연결하는 것이 좋은 방법입니다.
**참고**
Amazon DocumentDB 클러스터의 모든 인스턴스는 동일한 TCP 포트에서 연결을 수신합니다.
## TLS 지원
전송 계층 보안(TLS)을 사용하여 Amazon DocumentDB에 연결하는 방법에 대한 자세한 내용은 [전송 중 데이터 암호화](security.encryption.ssl.md)을 참조하십시오.
## Amazon DocumentDB 스토리지
Amazon DocumentDB 데이터는 솔리드 스테이트 드라이브(SSD)를 사용하는 단일 가상 볼륨인 *클러스터 볼륨*에 저장됩니다. 클러스터 볼륨은 데이터 복사본 6개로 구성되며, 데이터 복사본은 단일 AWS 리전에서 여러 가용 영역에 걸쳐 자동으로 복제됩니다. 이 복제를 통해 데이터의 내구성을 높이고 데이터 손실 가능성을 줄일 수 있습니다. 또한 다른 가용 영역에 데이터 복사본이 이미 있어 장애 조치가 이루어지는 동안 클러스터 가용성이 높아집니다. 이러한 복사본은 계속해서 Amazon DocumentDB 클러스터의 인스턴스에 데이터 요청을 제공할 수 있습니다.
### 데이터 스토리지 요금이 청구되는 방법
Amazon DocumentDB는 데이터의 양이 증가함에 따라 클러스터 볼륨의 크기가 자동으로 증가합니다. Amazon DocumentDB 클러스터 볼륨은 최대 128TiB까지 증가할 수 있지만, 사용자는 Amazon DocumentDB 클러스터 볼륨에서 사용하는 공간에 대해서만 비용이 청구됩니다. Amazon DocumentDB 4.0부터는 컬렉션이나 인덱스를 삭제하는 등의 방법으로 데이터가 제거되면 비슷한 양만큼 할당된 전체 공간이 감소합니다. 따라서 더 이상 필요하지 않은 컬렉션, 인덱스 및 데이터베이스를 삭제하여 스토리지 요금을 절감할 수 있습니다. 위 목록에 있는 Amazon DocumentDB 버전 3.6에서는 데이터를 제거할 때 복원된 공간을 클러스터 볼륨이 다시 사용할 수 있지만 볼륨 자체의 크기는 줄어들지 않습니다. 따라서 버전 3.6에서는 여유 공간이 재사용되더라도 컬렉션 또는 인덱스를 삭제할 때 스토리지가 변경되지 않을 수 있습니다.
**참고**
Amazon DocumentDB 3.6의 스토리지 비용은 스토리지 "하이 워터 마크"(Amazon DocumentDB 클러스터에 할당된 최대 양)를 기반으로 합니다. 대량의 임시 정보를 생성하거나 불필요한 오래된 데이터를 제거하기 전에 대량의 새 데이터를 로드하는 ETL 관행을 피함으로써 비용을 관리할 수 있습니다. Amazon DocumentDB 클러스터에서 데이터를 제거하면 많은 양의 공간이 할당되지만 사용되지 않는 경우 하이 워터 마크를 재설정하려면 논리적 데이터 덤프를 수행하고 `mongodump` 또는 `mongorestore`와 같은 도구를 사용하여 새 클러스터로 복원해야 합니다. 스냅샷을 생성하고 복원하면 기본 스토리지의 물리적 레이아웃이 복원된 스냅샷에서 동일하게 유지되기 때문에 할당된 스토리지가 감소하지 않습니다.
**참고**
`mongodump`와 `mongorestore` 같은 유틸리티를 사용하면 스토리지 볼륨에 읽고 쓰는 데이터의 크기에 따라 I/O 요금이 발생합니다.
Amazon DocumentDB 데이터 스토리지 및 I/O 요금에 대한 자세한 내용은 [Amazon DocumentDB(MongoDB와 호환 가능)](https://aws.amazon.com/documentdb/pricing) 요금 및 [요금 FAQ](https://aws.amazon.com/documentdb/faqs/#Pricing)를 참조하십시오.
## Amazon DocumentDB 복제
Amazon DocumentDB 클러스터에서 각 복제본 인스턴스는 독립적 엔트포인트를 보여줍니다. 이 복제본 엔드포인트는 클러스터 볼륨의 데이터에 대한 읽기 전용 액세스를 제공하며 복제된 여러 인스턴스에서 데이터의 읽기 워크로드를 확장하도록 해줍니다. 또한 Amazon DocumentDB 클러스터의 데이터 읽기 성능을 개선하고 데이터 가용성을 높이는 데도 도움이 됩니다. Amazon DocumentDB 복제본은 장애 조치 대상이기도 하며 Amazon DocumentDB 클러스터의 기본 인스턴스에 장애가 발생할 경우 신속하게 승격됩니다.
## Amazon DocumentDB 신뢰성
Amazon DocumentDB는 안정성, 내구성 및 내결함성을 고려하여 설계되었습니다. (가용성을 높이려면 Amazon DocumentDB 클러스터가 서로 다른 가용 영역에 여러 개의 복제본 인스턴스가 있도록 구성해야 합니다.) Amazon DocumentDB에는 신뢰할 수 있는 데이터베이스 솔루션으로 만들어 주는 몇 가지 자동 기능이 포함되어 있습니다.
### 스토리지 자동 복구
Amazon DocumentDB는 데이터의 여러 복사본을 3개의 가용 영역에 유지하므로 스토리지 장애로 인해 데이터가 손실될 가능성을 크게 줄입니다. Amazon DocumentDB는 클러스터 볼륨에서 장애를 자동으로 감지합니다. 클러스터 볼륨의 세그먼트에 장애가 발생하면 Amazon DocumentDB는 즉시 세그먼트를 복구합니다. 이때 클러스터 볼륨을 구성하는 나머지 볼륨의 데이터를 사용하여 복구된 세그먼트의 데이터도 이용 가능합니다. 따라서 Amazon DocumentDB는 데이터 손실을 방지하고 인스턴스 장애를 복구하기 위해 시점 복원을 수행할 필요성을 줄입니다.
### 유지 가능한 캐시 워밍
Amazon DocumentDB는 페이지 캐시가 데이터베이스와 독립적으로 생존할 수 있도록 데이터베이스와 별도의 프로세스로 자신의 페이지 캐시를 관리합니다. 데이터베이스 장애가 발생한 경우에는 페이지 캐시가 메모리에 남습니다. 이렇게 하면 데이터베이스를 다시 시작할 때 버퍼 풀이 가장 최근의 상태로 워밍업됩니다.
### 충돌 복구
Amazon DocumentDB는 거의 순간적으로 충돌을 복구하고 애플리케이션 데이터를 계속해서 제공하도록 설계되었습니다. Amazon DocumentDB는 병렬 스레드에서 비동기식으로 충돌 복구를 수행하므로, 충돌 후 거의 즉시 데이터베이스가 열리고 사용할 수 있습니다.
### 리소스 거버넌스
Amazon DocumentDB는 상태 확인과 같은 서비스의 중요한 프로세스를 실행하는 데 필요한 리소스를 보호합니다. 이를 위해 인스턴스에 높은 메모리 압력이 발생하는 경우 Amazon DocumentDB는 요청을 제한합니다. 따라서 일부 작업은 메모리 사용량이 줄어들 때까지 대기열에 들어갈 수 있습니다. 메모리 부족 현상이 계속되면 대기 중인 작업 시간이 초과될 수 있습니다. 다음의 `LowMemThrottleQueueDepth`, `LowMemThrottleMaxQueueDepth`, `LowMemNumOperationsThrottled`, `LowMemNumOperationsTimedOut` CloudWatch 측정치를 사용하여 메모리 부족으로 인한 서비스 제한 작업 여부를 모니터링할 수 있습니다. 자세한 내용은 CloudWatch를 사용하는 Amazon DocumentDB 모니터링을 참조하세요. LowMem CloudWatch 지표로 인해 인스턴스의 메모리 부족 현상이 지속되면 인스턴스를 확장하여 워크로드에 사용할 추가 메모리를 제공하는 것이 좋습니다.
## 읽기 기본 설정 옵션
Amazon DocumentDB는 클라우드 네이티브 공유 스토리지 서비스를 사용하여 세 개의 가용 영역에 걸쳐 데이터를 6회 복제하여 높은 수준의 내구성을 제공합니다. Amazon DocumentDB는 내구성을 확보하기 위해 데이터를 여러 인스턴스에 복제하지 않습니다. 인스턴스가 1개이건 15개이건 클러스터 데이터의 내구성이 유지됩니다.
**Topics**
+ [쓰기 내구성](#durability-consistency-isolation.write-durability)
+ [읽기 격리](#durability-consistency-isolation.read-isolation)
+ [읽기 정합성](#durability-consistency-isolation.read-consistency)
+ [높은 가용성](#durability-consistency-isolation.high-availability)
+ [읽기 확장](#durability-consistency-isolation.scaling-reads)
### 쓰기 내구성
Amazon DocumentDB는 고유한, 배포된, 내결함성, 자가 복구 스토리지 시스템을 사용합니다. 이 시스템은 3개의 AWS 가용 영역에 6개의 데이터 복사본(V=6)을 복제하여 고가용성과 내구성을 제공합니다. Amazon DocumentDB는 데이터를 작성할 때 클라이언트에게 쓰기를 승인하기 전에 모든 쓰기가 다수의 노드에 지속적으로 기록되도록 보장합니다. 3노드 MongoDB 복제본 세트를 실행하는 경우 쓰기 문제 `{w:3, j:true}`을 사용하면 Amazon DocumentDB와 비교할 때 최상의 구성을 얻을 수 있습니다.
Amazon DocumentDB 클러스터에 대한 쓰기는 클러스터의 라이터 인스턴스에서 처리해야 합니다. 리더에 쓰기를 시도하면 오류가 발생합니다. Amazon DocumentDB 기본 인스턴스에서 승인된 쓰기는 내구성이 강하며 롤백할 수 없습니다. Amazon DocumentDB는 기본적으로 내구성이 뛰어나며 내구성이 없는 쓰기 옵션을 지원하지 않습니다. 사용자가 내구성 수준(즉, 쓰기 문제)을 수정할 수 없습니다. Amazon DocumentDB는 w=아무거나를 무시하며 사실상 w: 3 및 j: true입니다. 줄일 수는 없습니다.
Amazon DocumentDB 아키텍처에서 스토리지와 컴퓨팅이 분리되어 있기 때문에 단일 인스턴스를 가진 클러스터는 내구성이 매우 높습니다. 내구성은 스토리지 계층에서 처리됩니다. 따라서 단일 인스턴스와 3개의 인스턴스가 있는 하나의 Amazon DocumentDB 클러스터는 동일한 수준의 내구성을 달성합니다. 데이터의 뛰어난 내구성을 유지하면서 클러스터를 특정 사용 사례로 구성할 수 있습니다.
Amazon DocumentDB 클러스터에 대한 쓰기는 단일 문서 내에서 원자성을 갖습니다.
Amazon DocumentDB는 `wtimeout` 옵션을 지원하지 않으며 값이 지정된 경우 오류를 반환하지 않습니다. 기본 Amazon DocumentDB 인스턴스에 대한 쓰기는 무기한 차단되지 않도록 보장됩니다.
### 읽기 격리
Amazon DocumentDB 인스턴스에서 읽은 데이터는 쿼리가 시작되기 전에만 지속되는 데이터를 반환합니다. 읽기는 쿼리 실행이 시작된 후 수정한 데이터를 반환하지 않으며 어떠한 경우에도 더티 읽기는 불가능합니다.
### 읽기 정합성
Amazon DocumentDB 클러스터에서 읽은 데이터는 내구성이 뛰어나며 롤백되지 않습니다. 요청 또는 연결에 대한 읽기 환경설정을 지정하여 Amazon DocumentDB 읽기에 대한 읽기 일관성을 수정할 수 있습니다. Amazon DocumentDB는 내구성이 떨어지는 읽기 옵션을 지원하지 않습니다.
Amazon DocumentDB 클러스터의 기본 인스턴스로부터의 읽기는 정상적인 동작 조건에서 강력하게 일관되고 쓰기 후 읽기 일관성을 갖습니다. 쓰기와 그 다음 읽기 사이에서 장애 조치 이벤트가 발생할 경우 시스템이 일시적으로 강력히 일관되지 않은 읽기를 반환할 수 있습니다. 읽기 전용 복제본에서 모든 읽기는 최종적으로 일관되며 같은 순서로 데이터를 반환할 뿐 아니라 복제 지연 시간이 종종 100ms 미만입니다.
#### Amazon DocumentDB 읽기 기본 설정
Amazon DocumentDB는 복제본 설정 모드에서 클러스터 엔드포인트에서 데이터를 읽을 때에만 읽기 환경설정 옵션을 설정할 수 있도록 지원합니다. 읽기 환경설정 옵션을 설정하면 MongoDB 클라이언트 또는 드라이버가 읽기 요청을 Amazon DocumentDB 클러스터의 인스턴스로 라우트하는 방법에 영향을 미칩니다. 특정 쿼리에 대해 또는 MongoDB 드라이버의 일반 옵션으로 읽기 기본 설정 옵션을 설정할 수 있습니다. 읽기 기본 설정 옵션을 설정하는 방법은 클라이언트 또는 드라이버 설명서를 참조하십시오.
클라이언트 또는 드라이버가 복제본 설정 모드에서 Amazon DocumentDB 클러스터 엔드포인트에 연결하지 않으면 읽기 환경설정을 지정한 결과가 정의되지 않습니다.
Amazon DocumentDB는 *태그 세트*를 읽기 환경설정으로 설정하는 것을 지원하지 않습니다.
**지원되는 읽기 기본 설정 옵션**
+ **`primary`**—`primary` 읽기 기본 설정을 지정하면 모든 읽기가 클러스터의 기본 인스턴스로 라우팅되도록 할 수 있습니다. 기본 인스턴스를 사용할 수 없으면 읽기 작업이 실패합니다. `primary` 읽기 기본 설정은 쓰기 후 읽기 일관성을 생성하며, 고가용성과 읽기 확장성보다 쓰기 후 읽기 일관성이 우선시되는 사용 사례에 적합합니다.
다음 예제에서는 `primary` 읽기 기본 설정을 지정합니다.
```
db.example.find().readPref('primary')
```
+ **`primaryPreferred`**—일반 작동 시 기본 인스턴스에 대한 `primaryPreferred` 읽기 기본 설정 경로를 지정합니다. 기본 장애 조치가 있을 경우 클라이언트가 요청을 복제본으로 라우팅합니다. `primaryPreferred` 읽기 기본 설정은 일반적인 작업 중 쓰기 후 읽기 일관성을 생성하고, 장애 조치 이벤트 중 최종적 일관된 읽기를 생성합니다. `primaryPreferred` 읽기 기본 설정은 읽기 확장성보다 쓰기 후 읽기 일관성이 우선시되지만 고가용성도 필요한 사용 사례에 적합합니다.
다음 예제에서는 `primaryPreferred` 읽기 기본 설정을 지정합니다.
```
db.example.find().readPref('primaryPreferred')
```
+ **`secondary`**— `secondary` 읽기 기본 설정을 지정하면 읽기가 기본 인스턴스가 아닌 복제본으로만 라우팅됩니다. 클러스터에 복제본 인스턴스가 없으면 읽기 요청이 실패합니다. `secondary` 읽기 기본 설정은 최종적 일관된 읽기를 생성하며 고가용성과 쓰기 후 읽기 일관성보다 기본 인스턴스 쓰기 처리량이 우선시되는 사용 사례에 적합합니다.
다음 예제에서는 `secondary` 읽기 기본 설정을 지정합니다.
```
db.example.find().readPref('secondary')
```
+ **`secondaryPreferred`**—`secondaryPreferred` 읽기 환경설정을 지정하면 읽기는 하나 이상의 복제본이 활성화될 때 읽기 복제본으로 라우팅됩니다. 클러스터에 활성 복제본 인스턴스가 없으면 읽기 요청이 기본 인스턴스로 라우팅됩니다. `secondaryPreferred` 읽기 기본 설정은 읽기 전용 복제본에서 읽기를 처리할 때 최종적 일관된 읽기를 생성합니다. 장애 조치 이벤트를 제외하고 기본 인스턴스에서 읽기를 처리할 때 쓰기 후 읽기 일관성이 생깁니다. `secondaryPreferred` 읽기 기본 설정은 쓰기 후 읽기 일관성보다 읽기 확장성 및 고가용성이 우선시되는 사용 사례에 적합합니다.
다음 예제에서는 `secondaryPreferred` 읽기 기본 설정을 지정합니다.
```
db.example.find().readPref('secondaryPreferred')
```
+ **`nearest`**—클라이언트와 Amazon DocumentDB 클러스터의 모든 인스턴스 간에 측정된 지연 시간만을 기준으로 `nearest` 읽기 기본 설정 경로를 지정합니다. `nearest` 읽기 기본 설정은 읽기 전용 복제본에서 읽기를 처리할 때 최종적 일관된 읽기를 생성합니다. 장애 조치 이벤트를 제외하고 기본 인스턴스에서 읽기를 처리할 때 쓰기 후 읽기 일관성이 생깁니다. `nearest` 읽기 기본 설정은 쓰기 후 읽기 일관성 및 읽기 확장성보다 가장 낮은 읽기 지연 시간 및 고가용성 달성이 우선시되는 사용 사례에 적합합니다.
다음 예제에서는 `nearest` 읽기 기본 설정을 지정합니다.
```
db.example.find().readPref('nearest')
```
### 높은 가용성
Amazon DocumentDB는 복제본을 기본 인스턴스의 장애 조치 대상으로 사용하여 가용성이 높은 클러스터 구성을 지원합니다. 기본 인스턴스가 실패하면 Amazon DocumentDB 복제본이 새 기본 인스턴스로 승격되며, 기본 인스턴스에 대한 읽기 및 쓰기 요청이 예외로 실패하는 짧은 중단이 발생합니다.
Amazon DocumentDB 클러스터에 복제본이 없는 경우, 기본 인스턴스는 실패 중에 다시 작성됩니다. 그러나 Amazon DocumentDB 복제본을 승격하는 것은 기본 인스턴스를 다시 만드는 것보다 훨씬 빠릅니다. 따라서 장애 조치 대상으로 하나 이상의 Amazon DocumentDB 복제본을 작성하는 것이 좋습니다.
장애 조치 대상으로 사용할 복제본은 기본 인스턴스와 동일한 인스턴스 클래스에 속해야 하며 기본 인스턴스와는 다른 가용 영역에 프로비저닝되어야 합니다. 장애 조치 대상으로 사용할 복제본을 제어할 수 있습니다.니다. 고가용성을 위해 Amazon DocumentDB를 구성하는 모범 사례는 [Amazon DocumentDB 클러스터 내결함성에 대한 이해](db-cluster-fault-tolerance.md)을 참조하십시오.
### 읽기 확장
Amazon DocumentDB 복제본은 읽기 규모 조정에 적합합니다. 클러스터 볼륨에서 이루어지는 읽기 작업 전용으로 사용됩니다. 즉 복제본이 쓰기는 처리하지 않습니다. 데이터 복제는 클러스터 볼륨 내에서 일어나며 인스턴스 간에는 일어나지 않습니다. 따라서 각 복제본의 리소스는 쿼리 처리에만 사용되지 데이터의 복제 및 쓰기에 사용되지 않습니다.
애플리케이션에 읽기 용량이 더 필요하면 클러스터에 신속하게 복제본을 추가할 수 있습니다(보통 10분 미만). 읽기 용량 요구 사항이 줄어들면 불필요한 복제본을 제거할 수 있습니다. Amazon DocumentDB 복제본에서는 필요한 읽기 용량에 대해서만 비용을 지불합니다.
Amazon DocumentDB는 읽기 환경설정 옵션을 사용하여 클라이언트 측 읽기 스케일링을 지원합니다. 자세한 내용은 [Amazon DocumentDB 읽기 기본 설정](#durability-consistency-isolation.read-preferences)을 참조하세요.
## TTL 삭제
백그라운드 프로세스를 통해 생성된 TTL 인덱스 영역에서의 삭제는 특정 기간 내에 삭제된다고 보장할 수 없으며 가능한 한 빠른 시간 내에 수행됩니다. 인스턴스 크기, 인스턴스 리소스 사용률, 문서 크기 및 전체 처리량과 같은 요소가 TTL 삭제 소요 시간에 영향을 줄 수 있습니다.
TTL 모니터가 문서를 삭제하면 삭제할 때마다 IO 비용이 발생하므로 청구 금액이 증가합니다. 처리량 및 TTL 삭제율이 증가하면 IO 사용량 증가로 인해 청구 금액이 증가할 것으로 예상됩니다.
기존 컬렉션에 TTL 인덱스를 생성할 때는 인덱스를 생성하기 전에 만료된 문서를 모두 삭제해야 합니다. 현재 TTL 구현은 컬렉션에서 소량의 문서를 삭제하는 데 최적화되어 있는데, 이는 컬렉션에서 처음부터 TTL을 활성화한 경우 일반적으로 발생하며, 한 번에 많은 문서를 삭제해야 하는 경우 IOPS가 필요 이상으로 높아질 수 있습니다.
문서를 삭제하기 위해 TTL 인덱스를 작성하지 않으려면, 대신 시간을 기준으로 문서를 컬렉션으로 분할하고, 문서가 더 이상 필요하지 않을 때 해당 컬렉션을 삭제할 수 있습니다. 예를 들어, 일주일에 한 개의 컬렉션을 만들어 IO 비용을 들이지 않고도 삭제할 수 있습니다. 이 방법은 TTL 인덱스를 사용하는 것보다 훨씬 더 비용 효율적일 수 있습니다.
## 청구 가능 리소스
### 청구 가능한 Amazon DocumentDB 리소스 식별
Amazon DocumentDB는 완전 관리형 데이터베이스 서비스로서 인스턴스, 스토리지, I/O, 백업 및 데이터 전송 비용을 청구합니다. 자세한 내용은 [Amazon DocumentDB(MongoDB와 호환됨) 요금](https://aws.amazon.com/documentdb/pricing/)을 참조하십시오.
계정에서 청구 가능한 리소스를 검색하고 리소스를 잠재적으로 삭제하려면 AWS Management Console 또는를 사용할 수 있습니다 AWS CLI.
#### 사용 AWS Management Console
를 사용하면 지정된에 프로비저닝한 Amazon DocumentDB 클러스터, 인스턴스 및 스냅샷을 검색할 AWS Management Console수 있습니다 AWS 리전.
**클러스터, 인스턴스 및 스냅샷을 검색하려면**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/docdb](https://console.aws.amazon.com/docdb) Amazon DocumentDB 콘솔을 엽니다.
1. 기본 리전이 아닌 리전에서 청구 가능한 리소스를 검색하려면 화면 오른쪽 상단에서 검색할 AWS 리전 를 선택합니다.
![\[리전 선택기의 북버지니아 리전입니다.\]](http://docs.aws.amazon.com/ko_kr/documentdb/latest/developerguide/images/db-cluster-console-region.png)
1. 탐색 창에서 검색하려는 청구 대상 리소스의 유형을 선택합니다. **클러스터**, **인스턴스** 또는 **스냅샷**.
![\[탐색 창의 클러스터, 인스턴스 및 스냅샷입니다.\]](http://docs.aws.amazon.com/ko_kr/documentdb/latest/developerguide/images/db-navigation-pane-clusters-instances-snapshots.png)
1. 해당 리전에 프로비저닝된 모든 클러스터, 인스턴스 또는 스냅샷이 오른쪽 창에 나열됩니다. 클러스터, 인스턴스 및 스냅샷에 요금이 청구됩니다.
#### 사용 AWS CLI
를 사용하면 지정된에 프로비저닝한 Amazon DocumentDB 클러스터, 인스턴스 및 스냅샷을 검색할 AWS CLI수 있습니다 AWS 리전.
**클러스터 및 인스턴스를 검색하려면**
다음 코드는 지정된 리전의 모든 클러스터 및 인스턴스를 나열합니다. 기본 리전에서 클러스터 및 인스턴스를 검색하려면 `--region` 파라미터를 생략할 수 있습니다.
**Example**
Linux, macOS, Unix의 경우:
```
aws docdb describe-db-clusters \
--region us-east-1 \
--query 'DBClusters[?Engine==`docdb`]' | \
grep -e "DBClusterIdentifier" -e "DBInstanceIdentifier"
```
Windows의 경우:
```
aws docdb describe-db-clusters ^
--region us-east-1 ^
--query 'DBClusters[?Engine==`docdb`]' | ^
grep -e "DBClusterIdentifier" -e "DBInstanceIdentifier"
```
이 작업의 출력은 다음과 같이 표시됩니다.
```
"DBClusterIdentifier": "docdb-2019-01-09-23-55-38",
"DBInstanceIdentifier": "docdb-2019-01-09-23-55-38",
"DBInstanceIdentifier": "docdb-2019-01-09-23-55-382",
"DBClusterIdentifier": "sample-cluster",
"DBClusterIdentifier": "sample-cluster2",
```
**스냅샷을 검색하려면**
다음 코드는 지정된 리전의 모든 스냅샷을 나열합니다. 기본 리전에서 스냅샷을 검색하려면 `--region` 파라미터를 생략할 수 있습니다.
Linux, macOS, Unix의 경우:
```
aws docdb describe-db-cluster-snapshots \
--region us-east-1 \
--query 'DBClusterSnapshots[?Engine==`docdb`].[DBClusterSnapshotIdentifier,SnapshotType]'
```
Windows의 경우:
```
aws docdb describe-db-cluster-snapshots ^
--region us-east-1 ^
--query 'DBClusterSnapshots[?Engine==`docdb`].[DBClusterSnapshotIdentifier,SnapshotType]'
```
이 작업의 출력은 다음과 같이 표시됩니다.
```
[
[
"rds:docdb-2019-01-09-23-55-38-2019-02-13-00-06",
"automated"
],
[
"test-snap",
"manual"
]
]
```
`manual` 스냅샷만 삭제하면 됩니다. `Automated` 스냅샷은 클러스터를 삭제할 때 함께 삭제됩니다.
### 불필요한 청구 대상 리소스 삭제
클러스터를 삭제하려면 먼저 해당 클러스터의 인스턴스를 모두 삭제해야 합니다.
+ 인스턴스를 삭제하려면 [Amazon DocumentDB 인스턴스 삭제](db-instance-delete.md) 단원을 참조하십시오.
**중요**
클러스터에서 인스턴스를 삭제하더라도 해당 클러스터와 연결된 스토리지 및 백업에 대해서는 계속 요금이 발생합니다. 모든 요금을 중단하려면 클러스터와 수동 스냅샷도 삭제해야 합니다.
+ 클러스터를 삭제하려면 [Amazon DocumentDB 클러스터 삭제](db-cluster-delete.md) 단원을 참조하십시오.
+ 수동 스냅샷 삭제는 [클러스터 스냅샷 삭제](backup_restore-delete_cluster_snapshot.md) 단원을 참조하십시오.
# 문서 데이터베이스란?
일부 개발자는 정규화된 행과 열의 측면에서 데이터 모델을 생각하지 않습니다. 일반적으로, 애플리케이션 계층 내에서 데이터가 JSON 문서로서 나타나게 되는데, 그 이유는 개발자들이 자신의 데이터 모델을 문서로 생각하는 것이 보다 직관적이기 때문입니다.
애플리케이션 코드에서 사용하는 것과 동일한 문서 모델 형식을 이용함으로써 데이터베이스에서 데이터를 지속해서 사용할 수 있으므로 문서 데이터베이스의 대중성은 높아져 왔습니다. 문서 데이터베이스는 유연하고 신속한 개발을 위해 강력하고 직관적인 API를 제공합니다.
**Topics**
+ [사용 사례](document-database-use-cases.md)
+ [문서 이해](document-database-documents-understanding.md)
+ [문서 작업](document-database-working-with-documents.md)
# 문서 데이터베이스 사용 사례
사용 사례는 문서 데이터베이스 또는 데이터를 관리하기 위한 일부 다른 유형의 데이터베이스가 필요한지 여부를 결정합니다. 문서 데이터베이스는 빠르고 반복적인 개발을 위해 유연한 스키마가 필요한 워크로드에 유용합니다. 다음은 문서 데이터베이스가 중요한 이점을 제공하는 일부 사용 사례의 예입니다.
**Topics**
+ [사용자 프로필](#document-databases-use-cases.user-profiles)
+ [실시간 빅 데이터](#document-databases-use-cases.big-data)
+ [콘텐츠 관리](#document-databases-use-cases.content-management)
## 사용자 프로필
문서 데이터베이스에는 유연한 스키마가 있으므로 속성과 데이터 값이 다른 문서를 저장할 수 있습니다. 문서 데이터베이스는 서로 다른 사용자가 다양한 유형의 정보를 제공하는 온라인 프로필에 대한 실용적인 솔루션입니다. 문서 데이터베이스에서는 각 사용자에 고유한 속성만 저장할 수 있어 각 사용자의 프로필을 효율적으로 저장할 수 있습니다.
사용자가 프로필에서 정보를 추가하거나 제거하도록 선택했다고 가정합니다. 이 경우 해당 문서를 최근에 추가된 속성과 데이터가 포함되거나 새로 생략된 속성과 데이터가 생략된 업데이트된 버전으로 쉽게 바꿀 수 있습니다. 문서 데이터베이스는 이 수준의 특성 및 유동성을 쉽게 관리합니다.
## 실시간 빅 데이터
과거에는 운영 데이터베이스와 분석 데이터베이스가 각각 운영 환경과 업무/보고 환경 등 서로 다른 환경에서 유지 관리되어 운영 데이터에서 정보를 추출하는 데 어려움이 있었습니다. 실시간으로 운영 정보를 추출할 수 있다는 것은 경쟁이 치열한 비즈니스 환경에서 중요합니다. 문서 데이터베이스를 사용하면 비즈니스에서는 모든 소스에서 운영 데이터를 저장하고 관리할 수 있으며 동시에 분석을 위해 데이터를 선택한 BI 엔진에 전달할 수 있습니다. 두 개의 환경이 필요하지 않습니다.
## 콘텐츠 관리
콘텐츠를 효과적으로 관리하려면 다양한 소스에서 콘텐츠를 수집 및 집계한 다음 고객에게 제공할 수 있어야 합니다. 문서 데이터베이스는 유연한 스키마로 인해 모든 유형의 데이터 수집과 저장에 적합합니다. 이 데이터베이스를 사용하여 이미지, 설명, 비디오 등 사용자 생성 콘텐츠를 비롯한 새 유형의 콘텐츠를 생성하고 통합할 수 있습니다.
# 문서 이해
문서 데이터베이스는 관계형 데이터베이스에서처럼 각각 고유하고 고정된 구조를 가진 여러 테이블의 데이터를 정규화하는 대신 반정형 데이터를 문서로 저장하는 데 사용됩니다. 문서 데이터베이스에 저장된 문서는 중첩된 키-값 페어를 사용하여 문서의 구조 또는 스키마를 제공합니다. 그러나, 동일한 문서 데이터베이스에 다른 유형의 문서를 저장할 수 있으므로 다른 형식의 유사한 데이터를 처리하기 위한 요구 사항을 충족할 수 있습니다. 예를 들어, 각 문서는 자체적으로 설명되므로 [문서 데이터베이스의 예제 문서](#document-database-documents) 주제에 설명된 온라인 상점을 위한 JSON 인코딩 문서를 동일한 문서 데이터베이스에 저장할 수 있습니다.
**Topics**
+ [SQL 대 비관계형 용어](#document-database-sql-vs-nosql-terms)
+ [단순 문서](#document-database-documents-simple)
+ [내장 문서](#document-database-documents-embeded)
+ [문서 데이터베이스의 예제 문서](#document-database-documents)
+ [문서 데이터베이스에서 정규화 이해](#document-database-normalization)
## SQL 대 비관계형 용어
다음 표에서는 문서 데이터베이스(MongoDB)에서 사용하는 용어를 SQL 데이터베이스에서 사용하는 용어와 비교합니다.
| SQL | MongoDB |
| --- | --- |
| 표 | 수집 |
| 열 | 문서 |
| 열 | Field |
| 프라이머리 키 | ObjectId |
| 인덱스 | 인덱스 |
| 보기 | 보기 |
| 중첩된 테이블 또는 객체 | 포함 문서 |
| 배열 | 배열 |
## 단순 문서
문서 데이터베이스의 모든 문서는 자체적으로 설명되어 있습니다. 이 설명서에서는 다른 인코딩 수단을 사용할 수 있는 경우에도 JSON과 유사한 형식의 문서를 사용합니다.
단순 문서에는 문서 내에서 모두 동일한 수준인 하나 이상의 필드가 있습니다. 다음 예에서 `SSN`, `LName`, `FName`, `DOB`, `Street`, `City`, `State-Province`, `PostalCode` 및 `Country` 필드는 문서 내에서 모두 형제 요소입니다.
```
{
"SSN": "123-45-6789",
"LName": "Rivera",
"FName": "Martha",
"DOB": "1992-11-16",
"Street": "125 Main St.",
"City": "Anytown",
"State-Province": "WA",
"PostalCode": "98117",
"Country": "USA"
}
```
단순 문서에서 정보를 구성할 때 각 필드는 개별적으로 관리됩니다. 개인의 주소를 가져오려면 `Street`, `City`, `State-Province`, `PostalCode` 및 `Country`를 개별 데이터 항목으로 가져와야 합니다.
## 내장 문서
복잡한 문서는 문서 내에 내장 문서를 생성하여 데이터를 구성합니다. 내장 문서는 데이터 그룹화 및 개별 데이터 항목 중 제공된 사례에서 더 효율적인 방식으로 관리하는 데 도움이 됩니다. 이전 예제를 사용하면 기본 문서에 `Address` 문서를 포함할 수 있습니다. 이렇게 하면 다음과 같은 문서 구조가 발생합니다.
```
{
"SSN": "123-45-6789",
"LName": "Rivera",
"FName": "Martha",
"DOB": "1992-11-16",
"Address":
{
"Street": "125 Main St.",
"City": "Anytown",
"State-Province": "WA",
"PostalCode": "98117",
"Country": "USA"
}
}
```
이제 개별 필드(`"SSN":`), 내장 문서(`"Address":`) 또는 내장 문서의 멤버(`"Address":{"Street":}`)로 문서의 데이터에 액세스할 수 있습니다.
## 문서 데이터베이스의 예제 문서
이전에 설명한 대로 문서 데이터베이스의 각 문서는 자체적으로 설명되므로 문서 데이터베이스 내의 문서 구조는 서로 다를 수 있습니다. 다음의 두 문서(책 및 정기 간행물용)는 구조적으로 서로 다릅니다. 하지만 두 문서 모두 동일한 문서 데이터베이스에 있을 수 있습니다.
다음은 샘플 책 문서입니다.
```
{
"_id" : "9876543210123",
"Type": "book",
"ISBN": "987-6-543-21012-3",
"Author":
{
"LName":"Roe",
"MI": "T",
"FName": "Richard"
},
"Title": "Understanding Document Databases"
}
```
다음은 두 개의 기사가 있는 샘플 정기 간행물 문서입니다.
```
{
"_id" : "0123456789012",
"Publication": "Programming Today",
"Issue":
{
"Volume": "14",
"Number": "09"
},
"Articles" : [
{
"Title": "Is a Document Database Your Best Solution?",
"Author":
{
"LName": "Major",
"FName": "Mary"
}
},
{
"Title": "Databases for Online Solutions",
"Author":
{
"LName": "Stiles",
"FName": "John"
}
}
],
"Type": "periodical"
}
```
이 두 문서의 구조를 비교합니다. 관계형 데이터베이스에서는 별도의 "정기 간행물" 및 "책" 테이블이나 "출판", "발행", "기사", "MI" 등 사용하지 않은 필드가 `null` 값인 단일 테이블이 필요합니다. 문서 데이터베이스는 각 문서가 자체 구조를 정의하는 반구조화이므로 이러한 두 문서는 `null` 필드가 없는 동일한 문서 데이터베이스에서 동시에 존재할 수 있습니다. 문서 데이터베이스는 희소 데이터를 처리하는 데 적합합니다.
문서 데이터베이스를 대상으로 개발하면 빠르고 반복적으로 개발할 수 있습니다. 이는 전체 모음에 대한 스키마를 변경하지 않고 문서의 데이터 구조를 동적으로 변경할 수 있기 때문입니다. 문서 데이터베이스는 신속한 개발 및 동적으로 변화하는 환경에 매우 적합합니다.
## 문서 데이터베이스에서 정규화 이해
문서 데이터베이스는 정규화되지 않습니다. 한 문서에서 발견된 데이터가 다른 문서에서 반복될 수 있습니다. 게다가 문서 간에 일부 데이터 차이가 있을 수 있습니다. 예를 들어, 온라인 상점에서 구매하고 구매에 대한 모든 세부 정보가 단일 문서에 저장되는 시나리오를 고려하십시오. 문서는 다음 JSON 문서와 같을 수 있습니다.
```
{
"DateTime": "2018-08-15T12:13:10Z",
"LName" : "Santos",
"FName" : "Paul",
"Cart" : [
{
"ItemId" : "9876543210123",
"Description" : "Understanding Document Databases",
"Price" : "29.95"
},
{
"ItemId" : "0123456789012",
"Description" : "Programming Today",
"Issue": {
"Volume": "14",
"Number": "09"
},
"Price" : "8.95"
},
{
"ItemId": "234567890-K",
"Description": "Gel Pen (black)",
"Price": "2.49"
}
],
"PaymentMethod" :
{
"Issuer" : "MasterCard",
"Number" : "1234-5678-9012-3456"
},
"ShopperId" : "1234567890"
}
```
이러한 모든 정보는 거래 모음에서 문서로 저장됩니다. 나중에 품목 하나를 구매하지 않은 것을 알게 되었습니다. 따라서 다시 동일한 상점에 로그인하여 다시 구매했습니다. 이러한 구매도 거래 모음에서 다른 문서로 저장됩니다.
```
{
"DateTime": "2018-08-15T14:49:00Z",
"LName" : "Santos",
"FName" : "Paul",
"Cart" : [
{
"ItemId" : "2109876543210",
"Description" : "Document Databases for Fun and Profit",
"Price" : "45.95"
}
],
"PaymentMethod" :
{
"Issuer" : "Visa",
"Number" : "0987-6543-2109-8765"
},
"ShopperId" : "1234567890"
}
```
이 두 문서, 즉 이름과 구매자 ID(같은 신용카드를 사용한 경우에는 신용카드 정보)가 중복된다는 점에 주목하세요. 그러나 스토리지가 저렴하고, 각 문서가 조인할 필요가 없는 단순 키-값 쿼리를 사용하여 빠르게 검색할 수 있는 단일 거래를 완전히 기록하기 때문에 괜찮습니다.
또한 신용 카드 정보라는 두 문서 간에도 명백한 차이가 있습니다. 각각의 구매에 대해 다른 신용카드를 사용한 것 같으므로 이러한 분명한 차이는 유일합니다. 각 문서는 문서화된 거래에 대해 정확합니다.
# 문서 작업
문서 데이터베이스로서 Amazon DocumentDB는 JSON 데이터를 쉽게 저장, 쿼리 및 인덱싱할 수 있습니다. Amazon DocumentDB에서 컬렉션은 모든 문서에 적용되는 단일 스키마가 없다는 점을 제외하면 관계형 데이터베이스의 테이블과 유사합니다. 모음을 통해 유사한 문서를 그룹화하여 모두 동일한 데이터베이스에 유지할 수 있으며, 구조가 동일하지 않아도 됩니다.
이전 단원의 예제 문서를 사용할 경우 `reading_material` 및 `office_supplies`에 대한 모음이 있을 수 있습니다. 소프트웨어에서는 문서가 속할 모음을 결정합니다.
다음 예제에서는 MongoDB API를 사용하여 문서를 추가, 쿼리, 업데이트 및 삭제하는 방법을 보여줍니다.
**Topics**
+ [문서 추가](#document-database-adding-documents)
+ [문서 쿼리](#document-database-queries)
+ [문서 업데이트](#document-database-updating)
+ [문서 삭제](#document-database-deleting)
## 문서 추가
Amazon DocumentDB에서는 컬렉션에 문서를 처음 추가할 때 데이터베이스가 생성됩니다. 이 예제에서는 클러스터에 연결할 때 기본 데이터베이스인 `test` 데이터베이스에 `example`이라는 컬렉션을 만듭니다. 첫 번째 문서가 삽입될 때 컬렉션이 암시적으로 만들어지기 때문에 컬렉션 이름에 대한 오류 검사가 수행되지 않습니다. 따라서 컬렉션 이름에 오타(예: `example` 대신 `eexample`)가 생성되고 의도한 컬렉션이 아닌 `eexample` 컬렉션에 문서가 추가됩니다. 오류 확인은 애플리케이션을 통해 처리되어야 합니다.
다음 예제에서는 MongoDB API를 사용하여 문서를 추가합니다.
**Topics**
+ [단일 문서 추가](#document-database-adding-documents-single)
+ [여러 문서 추가](#document-database-adding-documents-multiple)
### 단일 문서 추가
모음에 단일 문서를 추가하려면 모음에 추가할 문서에 `insertOne( {} )` 작업을 사용합니다.
```
db.example.insertOne(
{
"Item": "Ruler",
"Colors": ["Red","Green","Blue","Clear","Yellow"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 40
},
"UnitPrice": 0.89
}
)
```
이 작업의 출력은 다음과 같습니다(JSON 형식).
```
{
"acknowledged" : true,
"insertedId" : ObjectId("5bedafbcf65ff161707de24f")
}
```
### 여러 문서 추가
모음에 여러 문서를 추가하려면 모음에 추가할 문서 목록에 `insertMany( [{},...,{}] )` 작업을 사용합니다. 이 특정 목록의 문서에 다른 스키마가 있는 경우에도 모두 동일한 모음에 추가할 수 있습니다.
```
db.example.insertMany(
[
{
"Item": "Pen",
"Colors": ["Red","Green","Blue","Black"],
"Inventory": {
"OnHand": 244,
"MinOnHand": 72
}
},
{
"Item": "Poster Paint",
"Colors": ["Red","Green","Blue","Black","White"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50
}
},
{
"Item": "Spray Paint",
"Colors": ["Black","Red","Green","Blue"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50,
"OrderQnty": 36
}
}
]
)
```
이 작업의 출력은 다음과 같습니다(JSON 형식).
```
{
"acknowledged" : true,
"insertedIds" : [
ObjectId("5bedb07941ca8d9198f5934c"),
ObjectId("5bedb07941ca8d9198f5934d"),
ObjectId("5bedb07941ca8d9198f5934e")
]
}
```
## 문서 쿼리
이따금 판매하는 물품을 고객이 보고 구매할 수 있도록 온라인 상점의 재고를 조회해야 할 수도 있습니다. 컬렉션을 쿼리하는 것은 컬렉션의 모든 문서에 대한 것이든 특정 기준을 충족하는 문서에만 대한 것이든 관계없이 상대적으로 간단합니다.
문서를 쿼리하려면 `find()` 작업을 사용합니다. `find()` 명령에는 반환할 문서 선택 시 사용할 기준을 정의하는 단일 문서 파라미터가 있습니다. `find()`의 출력은 줄 바꿈이 없이 한 줄로 된 텍스트 형식의 문서입니다. 쉽게 읽기 위해 출력 문서의 형식을 지정하려면 `find().pretty()`를 사용하십시오. 이 주제의 모든 예제는 `.pretty()`를 사용하여 출력 형식을 지정합니다.
앞선 두 가지 연습 `insertOne()` 및 `insertMany()`에서 `example` 컬렉션에 삽입한 4개의 문서를 사용합니다.
**Topics**
+ [컬렉션의 모든 문서 검색](#document-database-queries-all-documents)
+ [피드 값과 일치하는 문서 검색](#document-database-queries-match-criteria)
+ [내장 문서와 일치하는 문서 검색](#document-database-queries-entire-embedded-document)
+ [내장 문서의 필드 값과 일치하는 문서 검색](#document-database-queries-embeded-document-field)
+ [배열이 일치하는 문서 검색](#document-database-queries-array-match)
+ [배열의 값과 일치하는 문서 검색](#document-database-queries-array-value-match)
+ [연산자를 사용하여 문서 검색](#document-database-query-operators)
### 컬렉션의 모든 문서 검색
모음의 모든 문서를 검색하려면 빈 쿼리 문서로 `find()` 작업을 사용하십시오.
다음 쿼리는 `example` 모음의 모든 문서를 반환합니다.
```
db.example.find( {} ).pretty()
```
### 피드 값과 일치하는 문서 검색
필드 및 값과 일치하는 모든 문서를 검색하려면 일치하는 필드 및 값을 식별하는 쿼리 문서로 `find()` 작업을 사용합니다.
이전 문서를 사용하면 이 쿼리는 "Item" 필드가 "Pen"과 동일한 모든 문서를 반환합니다.
```
db.example.find( { "Item": "Pen" } ).pretty()
```
### 내장 문서와 일치하는 문서 검색
내장 문서와 일치하는 모든 문서를 찾으려면 내장 문서 이름과 내장 문서의 모든 필드 및 값을 지정하는 쿼리 문서와 함께 `find()` 작업을 사용합니다.
내장 문서를 일치시킬 때 문서의 내장 문서는 쿼리에 있는 것과 동일한 이름을 가져야 합니다. 또한, 내장 문서의 필드 및 값은 쿼리와 일치해야 합니다.
다음 쿼리는 "Poster Paint" 문서만 반환합니다. "Pen"에는 "`OnHand`" 및 "`MinOnHand`"에 대한 다른 값이 있으며, "Spray Paint"에는 쿼리 문서보다 필드 하나(`OrderQnty`)가 더 있기 때문입니다.
```
db.example.find({"Inventory": {
"OnHand": 47,
"MinOnHand": 50 } } ).pretty()
```
### 내장 문서의 필드 값과 일치하는 문서 검색
내장 문서와 일치하는 모든 문서를 찾으려면 내장 문서 이름과 내장 문서의 모든 필드 및 값을 지정하는 쿼리 문서와 함께 `find()` 작업을 사용합니다.
이전 문서에서 다음 쿼리는 "점 표기법"을 사용하여 내장 문서와 관심 있는 필드를 지정합니다. 다른 필드가 내장 문서에 표시될 수 있는지 여부와 무관하게 이와 일치하는 모든 문서가 반환됩니다. "Poster Paint" 및 "Spray Paint"가 지정된 필드 및 값과 일치하므로 쿼리가 "Poster Paint" 및 "Spray Paint"를 반환합니다.
```
db.example.find({"Inventory.OnHand": 47, "Inventory.MinOnHand": 50 }).pretty()
```
### 배열이 일치하는 문서 검색
배열이 일치하는 모든 문서를 찾으려면 관심 있는 배열 이름과 해당 배열의 모든 값을 포함하여 `find()` 작업을 사용합니다. 쿼리가 배열 값이 동일하면서 쿼리와 동일한 순서인 해당 이름을 가진 배열을 포함한 모든 문서를 반환합니다.
"Poster Paint"에는 추가 색상(White)이 있고 "Spray Paint"에는 색상이 다른 순서로 있으므로 다음 쿼리는 "Pen"만을 반환합니다.
```
db.example.find( { "Colors": ["Red","Green","Blue","Black"] } ).pretty()
```
### 배열의 값과 일치하는 문서 검색
특정 배열 값을 보유한 모든 문서를 찾으려면 관심 있는 배열 이름과 값을 포함하여 `find()` 작업을 사용합니다.
```
db.example.find( { "Colors": "Red" } ).pretty()
```
각각 `Colors`라는 배열과 배열 내에 "`Red`" 값이 있으므로 이전 작업은 세 문서 모두를 반환합니다. "`White`" 값을 지정한 경우 쿼리는 "Poster Paint"만 반환합니다.
### 연산자를 사용하여 문서 검색
다음 쿼리는 "`Inventory.OnHand`" 값이 50 미만인 모든 문서를 반환합니다.
```
db.example.find(
{ "Inventory.OnHand": { $lt: 50 } } )
```
지원되는 쿼리 연산자 목록은 [쿼리 및 프로젝션 연산자](mongo-apis.md#mongo-apis-query) 섹션을 참조하십시오.
## 문서 업데이트
일반적으로 문서는 정적이 아니며 애플리케이션 워크플로의 일부로 업데이트됩니다. 다음은 문서를 업데이트할 수 있는 몇 가지 방법을 보여주는 예입니다.
기존 문서를 업데이트하려면 `update()` 작업을 사용합니다. `update()` 작업에는 두 개의 문서 파라미터가 있습니다. 첫 번째 문서는 업데이트할 문서를 식별합니다. 두 번째 문서는 업데이트를 지정합니다.
기존 필드를 업데이트할 때 (해당 필드가 단순 필드이든, 배열이든, 포함된 문서이든) 필드 이름과 해당 값을 지정합니다. 작업 종료 시 이전 문서의 필드가 새 필드와 값으로 교체된 것과 같습니다.
**Topics**
+ [기존 필드의 값 업데이트](#document-database-updating-existing-fields)
+ [새 필드 추가](#document-database-updating-adding-field)
+ [내장 문서 교체](#document-database-replacing-embedded-document)
+ [내장 문서에 새 필드 삽입](#document-database-updating-adding-field-embedded)
+ [문서에서 필드 제거](#document-database-remove-field)
+ [여러 문서에서 필드 제거](#document-database-remove-field-all)
### 기존 필드의 값 업데이트
다음 업데이트 작업에 대해 추가한 4개의 문서를 사용합니다.
```
{
"Item": "Ruler",
"Colors": ["Red","Green","Blue","Clear","Yellow"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 40
},
"UnitPrice": 0.89
},
{
"Item": "Pen",
"Colors": ["Red","Green","Blue","Black"],
"Inventory": {
"OnHand": 244,
"MinOnHand": 72
}
},
{
"Item": "Poster Paint",
"Colors": ["Red","Green","Blue","Black","White"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50
}
},
{
"Item": "Spray Paint",
"Colors": ["Black","Red","Green","Blue"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50,
"OrderQnty": 36
}
}
```
**단순 필드 업데이트**
단순 필드를 업데이트하려면 `$set`와 함께 `update()`를 사용하여 필드 이름과 새 값을 지정합니다. 다음 예제에서는 `Item`을 "Pen"에서 "Gel Pen"으로 바꿉니다.
```
db.example.update(
{ "Item" : "Pen" },
{ $set: { "Item": "Gel Pen" } }
)
```
이 작업의 결과는 다음과 같습니다.
```
{
"Item": "Gel Pen",
"Colors": ["Red","Green","Blue","Black"],
"Inventory": {
"OnHand": 244,
"MinOnHand": 72
}
}
```
**배열 업데이트**
다음 예제에서는 색상 목록에서 `Orange`를 포함하고 `White`를 제외한 새 배열로 기존 배열을 교체합니다. 새 색상 목록은 `update()` 작업에서 지정된 순서입니다.
```
db.example.update(
{ "Item" : "Poster Paint" },
{ $set: { "Colors": ["Red","Green","Blue","Orange","Black"] } }
)
```
이 작업의 결과는 다음과 같습니다.
```
{
"Item": "Poster Paint",
"Colors": ["Red","Green","Blue","Orange","Black"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50
}
}
```
### 새 필드 추가
하나 이상의 새 필드를 추가하여 문서를 수정하려면 삽입할 문서 및 `$set` 연산자를 사용하여 삽입할 새 필드와 값을 식별하는 쿼리 문서에 `update()` 작업을 사용합니다.
다음 예제에서는 Spray Paint 문서에 `UnitPrice` 필드와 `3.99` 값을 추가합니다. `3.99`라는 값은 숫자이지 문자열이 아닙니다.
```
db.example.update(
{ "Item": "Spray Paint" },
{ $set: { "UnitPrice": 3.99 } }
)
```
이 작업의 결과는 다음과 같습니다(JSON 형식).
```
{
"Item": "Spray Paint",
"Colors": ["Black","Red","Green","Blue"],
"Inventory": {
"OnHand": 47,
"MinOnHand": 50,
"OrderQnty": 36
},
"UnitPrice": 3.99
}
```
### 내장 문서 교체
내장 문서를 교체함으로써 문서를 수정하려면 내장 문서 및 `$set` 연산자를 사용한 새 필드와 값을 식별하는 문서에 `update()` 작업을 사용합니다.
다음과 같은 문서가 있다고 가정합니다.
```
db.example.insert({
"DocName": "Document 1",
"Date": {
"Year": 1987,
"Month": 4,
"Day": 18
}
})
```
**내장 문서 교체**
다음 예제에서는 현재 Date 문서를 새로운 문서로 교체합니다. 새 문서에는 `Month` 및 `Day` 필드만 있고, `Year` 필드는 제거되었습니다.
```
db.example.update(
{ "DocName" : "Document 1" },
{ $set: { "Date": { "Month": 4, "Day": 18 } } }
)
```
이 작업의 결과는 다음과 같습니다.
```
{
"DocName": "Document 1",
"Date": {
"Month": 4,
"Day": 18
}
}
```
### 내장 문서에 새 필드 삽입
**내장 문서에 필드를 추가하려면**
내장 문서에 하나 이상의 새 필드를 추가하여 문서를 수정하려면 내장 문서와 내장 문서 지정을 위한 "점 표기법" 및 `$set` 연산자를 사용하여 삽입할 새 필드와 값을 식별하는 문서에 `update()` 작업을 사용합니다.
다음과 같은 문서가 있을 때 다음 코드는 "점 표기법"을 사용하여 `Year` 및 `DoW` 필드를 내장 `Date` 문서에 삽입하고, `Words`를 상위 문서에 삽입합니다.
```
{
"DocName": "Document 1",
"Date": {
"Month": 4,
"Day": 18
}
}
```
```
db.example.update(
{ "DocName" : "Document 1" },
{ $set: { "Date.Year": 1987,
"Date.DoW": "Saturday",
"Words": 2482 } }
)
```
이 작업의 결과는 다음과 같습니다.
```
{
"DocName": "Document 1",
"Date": {
"Month": 4,
"Day": 18,
"Year": 1987,
"DoW": "Saturday"
},
"Words": 2482
}
```
### 문서에서 필드 제거
문서에서 필드를 제거하여 문서를 수정하려면 쿼리 문서에 필드를 제거할 문서를 식별하는 `update()` 작업을 사용하고, 제거할 필드를 지정하는 `$unset` 연산자를 사용합니다.
다음 예제에서는 이전 문서에서 `Words` 필드를 제거합니다.
```
db.example.update(
{ "DocName" : "Document 1" },
{ $unset: { Words:1 } }
)
```
이 작업의 결과는 다음과 같습니다.
```
{
"DocName": "Document 1",
"Date": {
"Month": 4,
"Day": 18,
"Year": 1987,
"DoW": "Saturday"
}
}
```
### 여러 문서에서 필드 제거
여러 문서에서 필드를 제거하여 문서를 수정하려면 `$unset` 연산자와 `multi` 옵션 세트를 `true`로 설정하여 `update()` 작업을 사용합니다.
다음 예제에서는 예제 컬렉션의 모든 문서에서 `Inventory` 필드를 제거합니다. 문서에 `Inventory` 필드가 없으면 해당 문서에 어떤 작업도 수행되지 않습니다. `multi: true`가 생략되면 기준을 충족하는 첫 번째 문서에만 작업이 수행됩니다.
```
db.example.update(
{},
{ $unset: { Inventory:1 } },
{ multi: true }
)
```
## 문서 삭제
데이터베이스에서 문서를 제거하려면 `remove()` 작업을 사용하여 제거할 문서를 지정합니다. 다음 코드는 `example` 모음에서 "Gel Pen"을 제거합니다.
```
db.example.remove( { "Item": "Gel Pen" } )
```
데이터베이스에서 모든 문서를 제거하려면 `remove()` 작업과 빈 쿼리를 사용합니다.
```
db.example.remove( { } )
```