기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
아마존 DocumentDB 모범 사례
Amazon DocumentDB(MongoDB 호환)를 사용하여 작업하는 모범 사례를 알아보십시오. 이 섹션은 새로운 모범 사례가 확인되는 대로 지속적으로 업데이트됩니다.
주제
기본 운영 지침
다음은 Amazon DocumentDB로 작업할 때 모든 사용자가 따라야 하는 기본 운영 지침입니다. Amazon DocumentDB 서비스 수준 계약에 다음 지침을 따르도록 명시되어 있습니다.
-
두 개의 가용 영역에 두 개 이상의 Amazon DocumentDB 인스턴스로 구성된 클러스터를 배포하십시오. AWS 프로덕션 워크로드의 경우 3개의 가용 영역에 3개 이상의 Amazon DocumentDB 인스턴스로 구성된 클러스터를 배포하는 것이 좋습니다.
-
명시된 서비스 제한 내에서 서비스를 사용하십시오. 자세한 내용은 아마존 DocumentDB 할당량 및 한도 단원을 참조하십시오.
-
메모리CPU, 연결 및 스토리지 사용량을 모니터링하십시오. 시스템 성능 및 가용성을 유지하는 데 도움이 되도록 사용 패턴이 변경되거나 배포 용량에 가까워지면 CloudWatch Amazon에서 알리도록 설정하십시오.
-
용량 한도에 도달할 경우 인스턴스를 확장합니다. 예상치 못한 애플리케이션 수요 증가를 수용할 수 있을 만큼 충분한 컴퓨팅 리소스 (예:CPU) 가 인스턴스에 프로비저닝되어야 합니다. RAM
-
복구 시점 목표에 맞춰 백업 보존 기간을 설정합니다.
-
클러스터의 장애 조치를 테스트하여 사용 사례 절차에 소요되는 시간을 파악하십시오. 자세한 내용은 Amazon DocumentDB 장애 조치 단원을 참조하십시오.
-
복제본 집합 모드(Amazon DocumentDB에 복제 세트로 연결 참조)에서 클러스터 엔드포인트(아마존 DocumentDB 엔드포인트 참조)를 사용하여 Amazon DocumentDB 클러스터에 연결함으로써 장애 조치가 애플리케이션에 미치는 영향을 최소화합니다.
-
애플리케이션의 읽기 일관성 요구 사항을 충족하면서 읽기 확장성을 최대화하는 드라이버 읽기 기본 설정을 선택합니다.
secondaryPreferred
읽기 기본 설정은 복제본 읽기를 활성화하고, 더 많은 작업을 수행할 수 있도록 기본 인스턴스를 비웁니다. 자세한 내용은 기본 설정 옵션 읽기 단원을 참조하십시오. -
네트워크 및 데이터베이스 오류가 발생하는 경우 복원력을 발휘하도록 애플리케이션을 설계합니다. 일시적인 오류와 지속적인 오류를 구별하기 위해 드라이버의 오류 메커니즘을 사용합니다. 적절한 경우 지수 백오프 메커니즘을 사용하여 일시적인 오류를 다시 시도합니다. 재시도 논리를 구현할 때 애플리케이션에서 데이터 일관성을 고려해야 합니다.
-
모든 프로덕션 클러스터 또는 중요한 데이터가 있는 클러스터에 대해 클러스터 삭제 보호를 활성화합니다. Amazon DocumentDB 클러스터를 삭제하기 전에 최종 스냅샷을 생성합니다. 를 사용하여 리소스를 배포하는 경우 종료 보호를 활성화하십시오 AWS CloudFormation. 자세한 내용은 종료 보호 및 삭제 보호 단원을 참조하십시오.
-
Amazon DocumentDB 클러스터를 생성할 때 --engine-version은 기본적으로 최신 주요 엔진 버전에 대해 기본적으로 설정되는 선택 사항 파라미터입니다. 현재 주요 엔진 버전은 4.0.0입니다. 새 주요 엔진 버전이 출시되면 –engine-version의 기본 엔진 버전은 이전 주요 엔진 버전을 반영하도록 업데이트됩니다. 따라서 프로덕션 워크로드, 특히 스크립팅, 자동화 또는 AWS CloudFormation 템플릿에 의존하는 워크로드의 경우 --engine-version을 의도한 메이저 버전으로 명시적으로 지정하는 것이 좋습니다.
인스턴스 크기 조정
Amazon DocumentDB에서 인스턴스 크기를 선택할 때 가장 중요한 요소 중 하나는 RAM 캐시의 양입니다. Amazon DocumentDB는 RAM 이 중 1/3을 자체 서비스에 예약합니다. 즉, 인스턴스의 3분의 2만 캐시에 사용할 수 있습니다. RAM 따라서 작업 세트 (예: 데이터 및 인덱스) 를 메모리에 RAM 충분히 담을 수 있는 인스턴스 유형을 선택하는 것이 Amazon DocumentDB 모범 사례입니다. 인스턴스 크기를 적절히 조정하면 전반적인 성능을 최적화하고 잠재적으로 I/O 비용을 최소화하는 데 도움이 됩니다. 타사 Amazon DocumentDB 크기 계산기
애플리케이션의 작업 집합이 메모리에 맞는지 확인하려면 로드 중인 클러스터의 각 인스턴스에 CloudWatch 대해 Amazon BufferCacheHitRatio
사용 현황을 모니터링하십시오.
이 BufferCacheHitRatio
CloudWatch 지표는 인스턴스의 메모리 캐시에서 제공되는 데이터 및 인덱스의 비율 (스토리지 볼륨 대비) 을 측정합니다. 일반적으로 작업 집합 메모리에서 데이터를 읽는 것이 저장소 볼륨에서 읽는 것보다 빠르고 비용 효율적이므로 BufferCacheHitRatio
의 값은 가능한 한 높아야 합니다. BufferCacheHitRatio
를 가능한 한 100%에 가깝게 유지하는 것이 바람직하지만 달성 가능한 최상의 가치는 애플리케이션의 액세스 패턴과 성능 요구 사항에 따라 달라집니다. 최대한 BufferCacheHitRatio
높은 수준을 유지하려면 인덱스와 작업 데이터 세트를 메모리에 담을 수 있을 만큼 클러스터의 인스턴스를 충분히 RAM 프로비저닝하는 것이 좋습니다.
인덱스가 메모리에 맞지 않으면 BufferCacheHitRatio
가 더 낮게 표시될 수 있습니다. 디스크에서 계속 읽으면 추가 I/O 비용이 발생하며 메모리에서 읽는 것보다 낫지 않습니다. BufferCacheHitRatio
비율이 예상보다 낮으면 클러스터의 인스턴스 크기를 확장하여 메모리의 작업 집합 데이터에 RAM 맞게 더 많이 제공하세요. 인스턴스 클래스를 확장하여 BufferCacheHitRatio
가 급격히 증가하면 애플리케이션의 작업 집합이 메모리에 맞은 것입니다. 규모 조정 작업 후 BufferCacheHitRatio
가 더 이상 대폭 증가하지 않을 때까지 계속 확장합니다. 인스턴스의 지표 모니터링에 대한 자세한 내용은 아마존 DocumentDB 메트릭 단원을 참조하십시오.
워크로드 및 지연 시간 요구 사항에 따라 애플리케이션이 정상 상태 사용 중에는 더 높은 BufferCacheHitRatio
값을 가질 수 있지만 전체 컬렉션을 스캔해야 하는 분석 쿼리가 인스턴스에서 실행되므로 주기적으로 BufferCacheHitRatio
딥을 수행할 수 있습니다. BufferCacheHitRatio
의 이러한 주기적 딥은 스토리지 볼륨에서 작업 집합 데이터를 버퍼 캐시로 다시 채워야 하는 후속 쿼리에 대해 더 높은 지연 시간으로 나타날 수 있습니다. 프로덕션에 워크로드를 배포하기 전에 성능 특성 및 BufferCacheHitRatio
를 이해하려면 먼저 대표적인 프로덕션 워크로드를 사용하여 사전 프로덕션 환경에서 워크로드를 테스트하는 것이 좋습니다.
BufferCacheHitRatio
는 인스턴스별 지표이므로 기본 인스턴스와 복제본 인스턴스 간에 읽기가 분산되는 방식에 따라 동일한 클러스터 내의 여러 인스턴스가 서로 다른 BufferCacheHitRatio
값을 가질 수 있습니다. 작업 워크로드가 분석 쿼리를 실행한 후 작업 집합 캐시를 다시 채울 때 발생하는 대기 시간 증가를 주기적으로 처리할 수 없는 경우 일반 작업 워크로드의 버퍼 캐시를 분석 질의의 버퍼 캐시와 분리해야 합니다. 운영 쿼리를 기본 인스턴스로, 분석 쿼리는 복제본 인스턴스로만 전송하여 BufferCacheHitRatio
를 완전히 격리할 수 있습니다. 또한 일정 비율의 일반 쿼리가 해당 복제본에서 실행되고 영향을 받을 수 있음을 이해하고 분석 쿼리를 특정 복제본 인스턴스로 전송하여 부분 격리를 수행할 수도 있습니다.
적합한 BufferCacheHitRatio
값은 사용 사례 및 애플리케이션 요구 사항에 따라 다릅니다. 이 지표에는 최고 또는 최소 값이 하나도 없습니다. 비용 및 성능 측면에서 일시적으로 낮은 BufferCacheHitRatio
의 절충이 허용되는지 여부만 결정할 수 있습니다.
인덱스 작업
인덱스 작성
Amazon DocumentDB로 데이터를 가져올 때, 대규모 데이터 세트를 가져오기 전에 인덱스를 생성해야 합니다. Amazon DocumentDB 인덱스 도구mongodump
디렉터리에서 인덱스를 추출하고, Amazon DocumentDB 클러스터에서 해당 인덱스를 생성할 수 있습니다. 마이그레이션에 대한 자세한 지침은 Amazon DocumentDB로 마이그레이션 단원을 참조하십시오.
인덱스 선택성
중복 값 수가 컬렉션에 있는 총 문서 수의 1% 미만인 필드로 인덱스 생성을 제한하는 것이 좋습니다. 예를 들어 컬렉션에 100,000개의 문서가 포함되어 있는 경우, 동일한 값이 1000회 이하로 나타나는 필드에만 인덱스를 생성하세요.
고유 값이 많은 인덱스를 선택하면(즉, 카디널리티가 높음) 필터 작업에서 적은 수의 문서를 반환하므로 인덱스 스캔 중에 우수한 성능을 얻을 수 있습니다. 높은 카디널리티 인덱스의 예는 같음 조건자가 최대 하나의 문서를 반환하도록 보장하는 고유 인덱스입니다. 낮은 카디널리티의 예로는 부울 필드에 대한 인덱스와 요일에 대한 인덱스가 있습니다. 성능 저하로 인해 낮은 카디널리티 인덱스는 데이터베이스의 쿼리 최적화 프로그램에 의해 선택될 가능성이 낮습니다. 동시에 낮은 카디널리티 인덱스는 디스크 스페이스 및 I/O와 같은 리소스를 계속 사용합니다. 일반적으로 일반적인 값 빈도가 전체 컬렉션 크기의 1% 이하인 필드의 인덱스를 대상으로 해야 합니다.
또한 일반적으로 필터로 사용되는 필드에만 인덱스를 생성하고, 사용하지 않는 인덱스를 정기적으로 찾는 것이 좋습니다. 자세한 내용은 인덱스 사용량을 분석하고 사용하지 않는 인덱스를 식별하려면 어떻게 해야 하나요? 단원을 참조하십시오.
인덱스가 데이터 쓰기에 미치는 영향
인덱스는 컬렉션의 모든 문서를 스캔할 필요가 없으므로 쿼리 성능을 향상할 수 있지만 이러한 개선 시에 다른 불리함이 따를 수 있습니다. 컬렉션의 각 인덱스에 대해 문서가 삽입, 업데이트 또는 삭제될 때마다 데이터베이스는 컬렉션을 업데이트하고 컬렉션의 각 인덱스에 필드를 기록해야 합니다. 예를 들어 컬렉션에 9개의 인덱스가 있는 경우 데이터베이스는 클라이언트에 작업을 승인하기 전에 10개의 쓰기를 수행해야 합니다. 따라서 인덱스가 추가될 때마다 쓰기 지연 시간, I/O가 추가되고 전체 활용도가 높은 스토리지가 증가합니다.
모든 작업 집합 메모리를 유지하려면 클러스터 인스턴스의 크기를 적절하게 조정해야 합니다. 이에 따라 스토리지 볼륨에서 인덱스 페이지를 지속적으로 읽을 필요가 없으므로 성능에 부정적인 영향을 미치고 I/O 비용이 증가합니다. 자세한 내용은 인스턴스 크기 조정 단원을 참조하십시오.
최상의 성능을 얻으려면 일반 쿼리의 성능을 향상하는 데 필요한 인덱스만 추가하여 컬렉션의 인덱스 수를 최소화합니다. 워크로드는 다양하지만 컬렉션당 인덱스 수를 5 이하로 유지하는 것이 좋습니다.
누락된 인덱스 식별
누락된 인덱스를 식별하고 제거하는 작업을 정기적으로 수행하는 것이 좋습니다. 자세한 내용은 누락된 인덱스는 어떻게 식별하나요? 단원을 참조하십시오.
미사용 인덱스 식별
사용되지 않는 인덱스를 식별하고 제거하는 작업을 정기적으로 수행하는 것이 좋습니다. 자세한 내용은 인덱스 사용량을 분석하고 사용하지 않는 인덱스를 식별하려면 어떻게 해야 하나요? 단원을 참조하십시오.
보안 모범 사례
보안 모범 사례를 위해 AWS Identity and Access Management (IAM) 계정을 사용하여 Amazon API DocumentDB 작업, 특히 Amazon DocumentDB 리소스를 생성, 수정 또는 삭제하는 작업에 대한 액세스를 제어해야 합니다. 이러한 리소스로는 클러스터, 보안 그룹 및 파라미터 그룹을 들 수 있습니다. 또한 클러스터 백업과 같은 일반적인 관리 작업을 수행하는 작업을 제어하는 데에도 사용해야 IAM 합니다. IAM역할을 생성할 때는 최소 권한 원칙을 사용하십시오.
-
역할 기반 액세스 제어와 함께 최소 권한을 적용합니다.
-
Amazon DocumentDB 리소스를 관리하는 각 사람에게 개별 IAM 계정을 할당하십시오. AWS 계정 루트 사용자를 사용하여 Amazon DocumentDB 리소스를 관리하지 마십시오. 자신을 포함한 모든 사람을 위한 IAM 사용자를 생성하십시오.
-
각 IAM 사용자에게 직무 수행에 필요한 최소한의 권한을 부여하십시오.
-
IAM그룹을 사용하면 여러 사용자의 권한을 효과적으로 관리할 수 있습니다. 에 대한 IAM 자세한 내용은 IAM사용 설명서를 참조하십시오. 모범 사례에 대한 자세한 내용은 IAM 모범 사례를 참조하십시오IAM.
-
IAM 자격 증명을 정기적으로 순환합니다.
-
Amazon DocumentDB의 AWS 시크릿을 자동으로 교체하도록 Secrets Manager를 구성하십시오. 자세한 내용은 Secrets Manager 사용 설명서의 AWS Secrets Manager 보안 암호 교체 및 Amazon DocumentDB용 암호 AWS 교체를 참조하십시오.
-
각 Amazon DocumentDB 사용자에게 각자의 임무를 수행하는 데 필요한 최소 권한 집합을 부여합니다. 자세한 내용은 역할 기반 액세스 제어를 사용한 데이터베이스 액세스 단원을 참조하십시오.
-
전송 계층 보안 (TLS) 을 사용하여 전송 중인 데이터를 암호화하고 저장된 데이터를 암호화하십시오. AWS KMS
비용 최적화
다음 모범 사례는 Amazon DocumentDB를 사용할 때 비용을 관리하고 최소화하는 데 도움이 될 수 있습니다. 요금 정보는 아마존 DocumentDB (MongoDB 호환) 요금 및 Amazon DocumentDB (MongoDB 호환) 요금 및 아마존 DocumentDB
-
해당 월 예상 청구액의 50% 및 75% 임계값으로 결제 알림을 생성합니다. 결제 알림 생성에 대한 자세한 내용은 결제 경보 생성을 참조하십시오.
-
Amazon DocumentDB의 아키텍처는 스토리지와 컴퓨팅을 분리하므로 단일 인스턴스 클러스터도 매우 내구성이 높습니다. 클러스터 스토리지 볼륨은 3개의 가용 영역에 걸쳐 6방향으로 데이터를 복제하므로, 클러스터에 있는 인스턴스 수와 상관없이 매우 높은 내구성을 제공합니다. 일반적인 프로덕션 클러스터에는 고가용성을 제공하기 위해 3개 이상의 인스턴스가 있습니다. 그러나 고가용성이 필요하지 않은 경우 단일 인스턴스 개발 클러스터를 사용하여 비용을 최적화할 수 있습니다.
-
개발 및 테스트 시나리오의 경우 더 이상 필요하지 않을 때 클러스터를 중지하고 개발이 다시 시작되면 클러스터를 시작합니다. 자세한 내용은 Amazon DocumentDB 클러스터 중지 및 시작 단원을 참조하십시오.
-
데이터를 쓰고TTL, 읽고, 삭제할 때 두 가지 변경 스트림 모두 I/O를 발생시킵니다. 이러한 기능을 활성화했지만 애플리케이션에서 사용하지 않는 경우 이 기능을 비활성화하면 비용이 절감될 수 있습니다.
지표를 통해 성능 문제 식별
리소스 부족이나 기타 일반적인 병목 현상으로 인해 발생하는 성능 문제를 식별하기 위해 Amazon DocumentDB 클러스터에서 사용 가능한 지표를 모니터링할 수 있습니다.
성능 지표 보기
다양한 기간 동안의 평균, 최대, 최소 측정값을 보려면 성능 지표를 정기적으로 모니터링합니다. 이렇게 하면 성능이 저하된 시점을 식별하는 데 도움이 됩니다. 또한 특정 지표 임계값에 대해 Amazon CloudWatch 경보를 설정하여 임계값에 도달하면 알림을 받을 수 있습니다.
성능 문제를 해결하기 위해서는 시스템의 기준 성능을 파악해야 합니다. 새 클러스터를 설정하고 일반 워크로드로 실행한 후 서로 다른 간격(예: 1시간, 24시간, 1주, 2주)으로 모든 성능 지표의 평균값, 최댓값 및 최솟값을 파악하십시오. 이렇게 하면 무엇이 정상인지를 알 수 있습니다. 이렇게 하면 작업의 최고 피크와 최저 피크 시간을 비교할 수 있습니다. 그런 다음 이 정보를 사용하여 성능이 표준 수준 이하로 떨어진 때를 식별할 수 있습니다.
OR를 사용하여 성능 지표를 볼 수 있습니다. AWS Management Console AWS CLI자세한 내용은 CloudWatch 데이터 보기 단원을 참조하십시오.
CloudWatch 알람 설정
경보를 설정하려면 Amazon CloudWatch 사용 설명서의 Amazon CloudWatch CloudWatch 경보 사용을 참조하십시오.
성능 지표 평가
인스턴스에는 여러 지표 범주가 있습니다. 허용되는 값을 결정하는 방법은 지표에 따라 다릅니다.
CPU
-
CPU사용률 — 사용된 컴퓨터 처리 용량의 백분율입니다.
메모리
-
여유 메모리 — 인스턴스에서 사용할 수 RAM 있는 메모리 양
-
스왑 사용량 - 인스턴스에서 스왑 스페이스를 얼마나 많이 사용했는지를 메가바이트 단위로 나타냅니다.
입력/출력 작업
-
읽기 IOPS, 쓰기 IOPS - 초당 평균 디스크 읽기 또는 쓰기 작업 수입니다.
-
읽기 지연 시간, 쓰기 지연 시간 – 읽기 또는 쓰기 작업의 평균 시간(밀리초)입니다.
-
읽기 처리량, 쓰기 처리량 – 초당 디스크에서 읽거나 디스크에 쓴 평균 크기(메가바이트)입니다.
-
디스크 대기열 길이 - 디스크에 쓰기 위해 또는 디스크에서 읽기 위해 대기 중인 I/O 작업의 수입니다.
네트워크 트래픽
-
네트워크 수신 처리량, 네트워크 전송 처리량 - 인스턴스에 대한 수신 또는 전송 네트워크 트래픽 속도(초당 메가바이트)입니다.
데이터베이스 연결
-
DB 연결 – 인스턴스에 연결된 클라이언트 세션의 수입니다.
일반적으로 성능 지표에 허용되는 값은 기준이 무엇인지 그리고 애플리케이션 무엇을 수행하는지에 따라 다릅니다. 기준과의 일관된 차이 또는 추세를 조사하십시오.
특정 지표 유형에 대한 권장 사항 및 조언은 다음과 같습니다.
-
높은 CPU 사용량 - 애플리케이션의 목표 (처리량 또는 동시 실행성 등) 에 부합하고 예상되는 경우 높은 사용량을 사용하는 것이 적절할 수 있습니다. CPU CPU사용량이 지속적으로 80% 를 넘으면 인스턴스 확장을 고려해 보십시오.
-
높은 RAM 사용량 —
FreeableMemory
측정치가 전체 인스턴스 메모리의 10% 미만으로 자주 떨어지는 경우 인스턴스 확장을 고려해 보십시오. DocumentDB 인스턴스의 메모리 사용량이 높을 때 어떤 일이 발생하는지에 대한 자세한 내용은 Amazon DocumentDB 리소스 거버넌스를 참조하십시오. -
스왑 사용량 - 이 메트릭은 0 또는 그 근처에 있어야 합니다. 스왑 사용량이 많은 경우 인스턴스 확장을 고려하십시오.
-
네트워크 트래픽 - 네트워크 트래픽의 경우 시스템 관리자에게 문의하여 해당 도메인 네트워크 및 인터넷 연결의 예상 처리량을 확인합니다. 처리량이 기대값보다 항상 낮으면 네트워크 트래픽을 검사합니다.
-
데이터베이스 연결 - 인스턴스 성능 저하 및 응답 시간 지연과 함께 사용자 연결 수가 많을 경우 데이터베이스 연결 제한을 고려해 봅니다. 인스턴스에 대한 최적의 사용자 연결 수는 해당 인스턴스 클래스와 수행하는 작업의 복잡성에 따라 다릅니다. 성능 지표와 관련하여 문제가 있을 경우 성능을 향상하기 위해 제일 먼저 할 수 있는 것은, 가장 많이 사용되고 가장 비용이 높은 쿼리를 튜닝하여 시스템 리소스에 대한 부하를 줄일 수 있는지 확인하는 것입니다.
쿼리를 조정했는데도 문제가 지속되면 Amazon DocumentDB 인스턴스 클래스를 발생한 문제와 관련된 리소스 CPU (RAM,, 디스크 공간, 네트워크 대역폭, I/O 용량) 가 더 많은 클래스로 업그레이드하는 것을 고려해 보십시오.
쿼리 튜닝
클러스터 성능을 향상하는 제일 좋은 방법 중 하나는 일반적으로 가장 많이 사용하는 쿼리와 리소스를 가장 많이 사용하는 쿼리를 튜닝하여 실행 비용을 낮추는 것입니다.
프로파일러(아마존 DocumentDB 작업을 프로파일링하는 중 참조)를 사용하여 클러스터에서 수행된 작업의 실행 시간 및 세부 정보를 기록할 수 있습니다. 프로파일러는 개별 쿼리 성능 및 전체 클러스터 성능을 개선하기 위해 클러스터에서 가장 느린 작업을 모니터링하는 경우에 유용합니다.
explain
명령을 사용하여 특정 쿼리에 대한 쿼리 계획을 분석하는 방법을 배울 수도 있습니다. 쿼리 성능을 높이기 위해 이 정보를 사용하여 쿼리나 기본 컬렉션을 수정할 수 있습니다(예: 인덱스 추가).
TTL및 시계열 워크로드
TTL인덱스 만료로 인한 문서 삭제는 최선의 방법입니다. 문서는 특정 기간 내에 삭제될 수 없습니다. 인스턴스 크기, 인스턴스 리소스 사용률, 문서 크기, 전체 처리량, 인덱스 수, 인덱스와 작업 집합의 메모리 용량 여부 등의 요인이 모두 프로세스에서 만료된 문서를 삭제하는 시기에 영향을 미칠 수 있습니다. TTL
TTL모니터가 문서를 삭제하면 삭제될 때마다 I/O 비용이 발생하여 요금이 증가합니다. 처리량과 TTL 삭제율이 증가하면 I/O 사용량 증가로 인해 더 높은 요금이 부과될 것으로 예상됩니다. 그러나 TTL 색인을 생성하여 문서를 삭제하지 않고 시간을 기준으로 문서를 컬렉션으로 분류하고 더 이상 필요하지 않을 때 해당 컬렉션을 삭제하면 IO 비용이 발생하지 않습니다. 이렇게 하면 TTL 인덱스를 사용하는 것보다 훨씬 더 비용 효율적일 수 있습니다.
시계열 워크로드의 경우, 롤링 컬렉션이 데이터를 삭제하는 더 좋은 방법이고 I/O 집약도를 줄일 수 있으므로 TTL 인덱스 대신 롤링 컬렉션을 만드는 것을 고려해 볼 수 있습니다. 컬렉션이 많거나 (특히 1TB를 초과하는 컬렉션) TTL 삭제 I/O 비용이 우려되는 경우 시간을 기준으로 문서를 컬렉션으로 분할하고 문서가 더 이상 필요하지 않을 때는 컬렉션을 삭제하는 것이 좋습니다. 데이터 수집 속도에 따라 하루에 한 번 또는 일주일에 한 번씩 모음을 만들 수 있습니다. 요구 사항은 애플리케이션에 따라 다르지만 몇 개의 큰 컬렉션보다는 더 작은 컬렉션을 사용하는 것이 좋습니다. 이러한 컬렉션을 삭제해도 I/O 비용이 발생하지 않으며 색인을 사용하는 것보다 더 빠르고 비용 효율적일 수 있습니다. TTL
마이그레이션
데이터를 Amazon DocumentDB로 마이그레이션할 때, 데이터를 마이그레이션하기 전에 먼저 Amazon DocumentDB에서 인덱스를 생성하는 것이 가장 좋습니다. 인덱스를 먼저 생성하면 전체 시간을 줄이고 마이그레이션 속도를 높일 수 있습니다. 이렇게 하려면 Amazon DocumentDB 인덱스 도구
또한 프로덕션 데이터베이스를 마이그레이션하기 전에 기능, 성능, 운영 및 비용을 고려하여 Amazon DocumentDB에서 애플리케이션을 완전히 테스트하는 것이 좋습니다.
클러스터 파라미터 그룹 사용
클러스터 파라미터 그룹 변경 내용을 프로덕션 클러스터에 적용하기 전에 테스트 클러스터에 적용해 보는 것이 좋습니다. 클러스터 백업에 대한 자세한 내용은 아마존 DocumentDB에서의 백업 및 복원 단원을 참조하십시오.
집계 파이프라인 쿼리
여러 단계로 집계 파이프라인 쿼리를 생성하고 쿼리에 있는 데이터의 하위 집합만 평가하는 경우 $match
단계를 첫 번째 단계 또는 파이프라인의 시작으로 사용합니다. $match
첫 번째를 사용하면 집계 파이프라인 쿼리의 후속 단계에서 처리해야 하는 문서 수가 줄어들어 쿼리 성능이 향상됩니다.
batchInsert
및 batchUpdate
높은 비율의 동시 batchInsert
및/또는 batchUpdate
작업을 수행하고 기본 인스턴스에서 FreeableMemory
(CloudWatch 지표) 양이 0이 되면 일괄 삽입 또는 업데이트 워크로드의 동시성을 줄이거나, 워크로드의 동시성을 줄일 수 없는 경우 인스턴스 크기를 늘려 양을 늘릴 수 있습니다. FreeableMemory