Share via

Azure 잘 설계된 프레임워크 검토 – NoSQL용 Azure Cosmos DB

  • 아티클

이 문서에서는 NoSQL용 Azure Cosmos DB에 대한 모범 사례를 설명합니다. 이러한 모범 사례는 효율적이고, 안정적이고, 안전하며, 비용에 최적화되고, 운영상 우수한 Azure Cosmos DB에 솔루션을 배포할 수 있도록 보장합니다. 이 지침은 잘 설계된 프레임워크에서 아키텍처 우수성의 다섯 가지 핵심 요소에 중점을 둡니다.

이 검토 가이드에서는 Azure Cosmos DB에 대한 실무 지식이 있으며 해당 기능에 정통한 것으로 가정합니다. 자세한 내용은 NoSQL용 Azure Cosmos DB를 참조하세요.

필수 조건

잘 설계된 프레임워크 핵심 요소를 이해하면 고품질의 안정적이고 효율적인 클라우드 아키텍처를 생성하는 데 도움이 될 수 있습니다. 먼저 Azure Well-Architected Framework 검토 평가를 사용하여 워크로드를 검토하는 것이 좋습니다.

더 많은 컨텍스트를 보려면 디자인에서 이 가이드의 고려 사항을 반영하는 다양한 참조 아키텍처를 검토합니다. 이러한 아키텍처에는 다음이 포함되지만 이에 국한되지는 않습니다.

안정성

모든 클라우드 서비스와 마찬가지로 서비스 및 워크로드 쪽에서 오류가 발생할 수 있습니다. 모든 잠재적 오류를 방지하는 것은 불가능하지만 단일 실패 구성 요소가 전체 워크로드에 미칠 수 있는 영향을 최소화하는 것이 더 나은 목표입니다. 이 섹션에는 일회성 실패의 결과를 최소화하기 위한 고려 사항 및 권장 사항이 포함되어 있습니다.

디자인 검사 목록

권장 사항

추천 장점
가용성 영역에 Azure Cosmos DB 계정을 배포합니다(사용 가능한 경우). 가용성 영역은 고유한 전원, 네트워킹 및 냉각을 제공하여 하드웨어 오류를 복제본(replica) 하위 집합으로 격리합니다. Azure Cosmos DB에는 가용성 영역 기능이 사용되지 않는 경우 단일 임의 가용성 영역에 걸쳐 있는 여러 복제본(replica) 있습니다. 가용성 영역 기능을 사용하는 경우 복제본(replica) 여러 가용성 영역에 걸쳐 있습니다.
두 개 이상의 지역에 걸쳐 Azure Cosmos DB 계정을 구성합니다. 여러 지역에 걸쳐 있으면 격리된 지역 중단이 있는 경우 계정을 완전히 사용할 수 없게 됩니다.
계정에 대해 서비스 관리 장애 조치(failover)를 사용하도록 설정합니다. 서비스 관리 장애 조치(failover)를 사용하면 Azure Cosmos DB가 가용성을 유지하기 위해 다중 지역 계정의 쓰기 지역을 변경할 수 있습니다. 이 변경은 사용자 상호 작용 없이 발생합니다. 서비스 관리 장애 조치(failover)의 장단기를 이해하고 필요한 경우 강제 장애 조치(failover)를 계획합니다. 자세한 내용은 고가용성 애플리케이션 빌드를 참조 하세요.
서비스 관리 장애 조치(failover)를 일시적으로 사용하지 않도록 설정하여 장애 조치(failover)를 수동으로 테스트하여 가용성의 유효성을 검사합니다. 서비스 관리 장애 조치(failover)를 일시적으로 사용하지 않도록 설정하면 스크립트 또는 Azure Portal을 사용하여 수동 장애 조치(failover)가 시작된 애플리케이션의 엔드투엔드 고가용성의 유효성을 검사할 수 있습니다. 나중에 서비스 관리 장애 조치(failover)를 다시 활성화할 수 있습니다.

Azure Policy 정의

보안

보안은 편의를 위해 쉽게 간과할 수 있는 모든 아키텍처의 중요한 부분입니다. 첫 번째 리소스 또는 개념 증명을 만들기 전에 다양한 보안 모범 사례를 미리 고려하여 최종 워크로드의 보안을 강화합니다. 이 섹션에는 최종 워크로드에 대한 보안 취약성 수를 줄이기 위한 고려 사항 및 권장 사항이 포함되어 있습니다.

디자인 검사 목록

권장 사항

추천 장점
최소한 데이터 보호 및 ID 관리 보안 기준을 구현합니다. ID 관리 및 데이터 보호를 포함한 보안 기준을 살펴봅니다. Azure Cosmos DB 계정을 보호하는 권장 사항을 구현합니다.
퍼블릭 엔드포인트를 사용하지 않도록 설정하고 가능하면 프라이빗 엔드포인트를 사용합니다. 계정에 노출 영역 공격에 사용할 수 있는 불필요하거나 사용되지 않는 공용 엔드포인트를 그대로 두지 않습니다.
역할 기반 액세스 제어를 사용하여 제어 평면 액세스를 특정 ID 및 그룹으로 제한하고 잘 정의된 할당 범위 내에서 제한합니다. 역할 기반 액세스 제어를 사용하여 계정에 의도하지 않은 액세스를 방지합니다. Azure Cosmos DB에 액세스하는 사용자 또는 애플리케이션에 적절한 역할 및 권한을 할당합니다.
계정에 대한 액세스를 제한하는 가상 네트워크 엔드포인트 및 규칙을 만듭니다. 가상 네트워크 서비스 엔드포인트 및 방화벽 규칙을 구현하여 Azure Cosmos DB 계정에 대한 액세스를 제한합니다. NSG(네트워크 보안 그룹)를 사용하여 Azure Cosmos DB 리소스에 대한 인바운드 및 아웃바운드 트래픽을 제어합니다. 신뢰할 수 있는 네트워크에 대한 액세스를 제한하고 적절한 네트워크 보안 조치를 적용하면 무단 액세스로부터 데이터를 보호할 수 있습니다.
데이터에 안전하게 액세스하려면 최상의 소프트웨어 개발 방법을 따르세요. 보안 코딩 사례를 따르고 Azure Cosmos DB와 상호 작용하는 애플리케이션을 개발할 때 보안 코드 검토를 수행합니다. 삽입 공격, XSS(교차 사이트 스크립팅) 또는 안전하지 않은 IDOR(직접 개체 참조)와 같은 일반적인 보안 취약성으로부터 보호합니다. 보안 위험을 방지하기 위해 일반적인 HTTP 상태 코드에 대한 입력 유효성 검사, 매개 변수가 있는 쿼리 및 적절한 오류 처리를 구현합니다.
컨트롤 플레인 로그에서 위반을 모니터링합니다. 모니터링을 사용하면 액세스 패턴 및 감사 로그를 추적하여 데이터베이스가 안전하고 관련 데이터 보호 규정을 준수하도록 기본. 또한 데이터 평면 메트릭을 모니터링하면 보안 위반을 나타낼 수 있는 익숙하지 않은 패턴을 식별하는 데 도움이 될 수 있습니다. 자세한 내용은 Azure 데이터베이스에 대한 보안 검사 목록을 참조하세요.
Azure Cosmos DB용 Microsoft Defender 사용 Microsoft Defender는 NoSQL용 Azure Cosmos DB 계정에서 데이터베이스를 악용하려는 시도를 감지합니다. Defender는 잠재적인 SQL 삽입, 의심스러운 액세스 패턴 및 기타 잠재적 악용을 검색합니다.

Azure Policy 정의

비용 최적화

워크로드의 특성 및 솔루션 구현은 Azure에서 실행되는 최종 비용에 영향을 줄 수 있습니다. 워크로드를 디자인할 때 분할 전략, 일관성 수준, 복제본(replica)tion 및 쓰기 유형과 같은 기본 드라이버를 고려합니다. 워크로드 크기를 조정하는 경우 데이터의 읽기/쓰기 특성, 평균 항목 크기, 정규화 및 TTL을 고려합니다. 이 섹션에는 워크로드 비용을 간소화하기 위한 고려 사항 및 권장 사항이 포함되어 있습니다.

  • 작업에서 일반적으로 수행되는 작업 및 쿼리를 고려하는 인덱싱 정책을 디자인합니다.
  • 카드 높고 변경되지 않는 값이 있는 파티션 키 또는 파티션 키 집합을 결정합니다. 기존 지침 및 모범 사례를 사용하여 적절한 파티션 키를 선택할 수 있습니다. 또한 파티션 키를 결정할 때 인덱싱 정책을 고려합니다.
  • 워크로드에 적합한 처리량 할당 스키마를 선택합니다. 데이터베이스 또는 컨테이너 수준에서 분산된 표준 및 자동 크기 조정 처리량의 이점을 검토합니다. 또한 적절한 경우 서버리스를 고려합니다. 처리량 할당 체계를 선택하는 컨텍스트에서 워크로드의 트래픽 패턴을 검토합니다.
  • 일관성 수준은 워크로드와 관련된 것으로 간주합니다. 또한 클라이언트 세션이 기본 일관성 수준을 변경해야 하는지 고려합니다.
  • 워크로드에 대해 예상되는 전체 데이터 스토리지를 계산합니다. 항목 및 인덱스의 크기는 모두 데이터 스토리지 비용에 영향을 줍니다. 복제본(replica) 및 백업이 스토리지 비용에 미치는 영향을 계산합니다.
  • 더 이상 사용되지 않거나 필요하지 않은 이전 항목을 자동으로 제거하는 전략을 만듭니다. 필요한 경우 이러한 항목을 제거하기 전에 저렴한 스토리지 솔루션으로 내보냅니다.
  • 파티션 간 조회를 최소화하는 가장 일반적인 쿼리를 평가합니다. 이 정보를 사용하여 파티션 키를 선택하거나 인덱싱 정책을 사용자 지정하는 프로세스를 알릴 수 있습니다.

권장 사항

추천 장점
RU/s 사용률 및 패턴을 모니터링합니다. 메트릭을 사용하여 솔루션의 시작 부분에서 RU 소비를 모니터링합니다. 쿼리 및 기타 데이터 연구 기술을 사용하여 애플리케이션 코드에서 안티패턴을 찾습니다.
워크로드에 매핑할 인덱싱 정책을 사용자 지정합니다. 기본 인덱싱 정책은 항목의 모든 경로를 인덱싱하며, 이 정책은 RU 사용량 및 비용에 큰 영향을 미칠 수 있습니다. 일반적인 쿼리에 대해 인덱싱해야 하는 경로만 기반으로 설계된 인덱싱 정책을 사용합니다. 쓰기가 많은 워크로드의 경우 쿼리에 사용되지 않는 열의 자동 인덱싱을 사용하지 않도록 설정합니다.
워크로드에 적합한 파티션 키를 선택합니다. 파티션 키는 처리량 소비량 및 데이터 스토리지를 논리 파티션에 균등하게 분산해야 합니다. 또한 선택 영역은 바인딩되지 않은 파티션 간 쿼리 수를 최소화해야 합니다. 불균형 파티션은 처리량 비용과 일시적인 오류를 증가시킬 수 있으므로 불균형한 양의 트래픽을 수신하는 핫 파티션을 방지합니다. 가장 일반적인 검색 쿼리를 사용하여 단일 파티션 또는 제한된 파티션 간 쿼리만 실행할 가능성이 있는 잠재적 파티션 키를 확인합니다.
워크로드에 적합한 경우 데이터베이스 또는 컨테이너 수준에서 서버리스 또는 프로비전된 처리량, 수동 프로비저닝 또는 자동 크기 조정을 사용합니다. 프로비전된 처리량 유형을 비교하고 워크로드에 적합한 옵션을 선택합니다. 일반적으로 더 작고 개발/테스트 워크로드는 데이터베이스 수준에서 서버리스 처리량 또는 수동 공유 처리량의 이점을 누릴 수 있습니다. 중요 업무용 워크로드가 클수록 컨테이너 수준에서 할당된 프로비전된 처리량을 활용할 수 있습니다.
애플리케이션의 기본 일관성 수준을 구성합니다. 적절한 경우 클라이언트 세션에서 기본 일관성 수준을 다운그레이드합니다. 항상 표준 기본 일관성 수준을 변경하거나 클라이언트 세션에서 재정의할 필요는 없습니다. 더 강력한 일관성 수준에서 읽기와 관련된 더 높은 비용을 고려합니다.
개발/테스트 워크로드의 경우 Azure Cosmos DB 에뮬레이터를 사용합니다. Azure Cosmos DB 에뮬레이터는 개발/테스트 및 지속적인 통합을 위한 옵션으로 개발 팀의 이러한 일반적인 워크로드 비용을 절감할 수 있습니다. 에뮬레이터는 Docker 컨테이너 이미지로도 사용할 수 있습니다.
트랜잭션 일괄 처리 작업 사용 삽입을 위해 논리 파티션 키 내에서 트랜잭션 일괄 처리 작업을 활용하도록 파티션을 디자인합니다. 클라이언트 쪽 SDKS에서 일괄 처리 작업을 사용하여 단일 트랜잭션 요청에서 여러 문서를 삽입, 업데이트 또는 삭제할 수 있습니다. 이 단계는 개별 요청 수를 줄이고 결국 처리량 효율성을 높일 수 있습니다.
프로젝션을 사용하여 큰 쿼리 결과 집합의 처리량 비용을 줄입니다. 결과 집합에서 필요한 최소한의 필드만 프로젝터하도록 쿼리를 작성합니다. 필드에 대한 계산이 필요한 경우 해당 계산 서버 쪽과 클라이언트 쪽을 수행하는 처리량 비용을 평가합니다.
바인딩되지 않은 파티션 간 쿼리를 사용하지 않습니다. 쿼리를 평가하고 작성하여 가능하면 단일 논리 파티션 내에서 검색하는지 확인합니다. 쿼리 필터를 사용하여 쿼리 대상의 논리 파티션을 제어합니다. 쿼리가 논리 파티션을 검색해야 하는 경우 전체 검색 대신 논리 파티션의 하위 집합만 검색하도록 쿼리를 바인딩합니다.
TTL(Time to Live)을 구현하여 사용되지 않는 항목을 제거합니다. TTL을 사용하여 더 이상 필요하지 않은 데이터를 자동으로 삭제합니다. 만료되거나 사용되지 않는 데이터를 제거하여 스토리지 비용을 관리합니다. 필요한 경우 만료된 데이터를 저렴한 스토리지 솔루션으로 내보냅니다.
집계가 많은 분석 저장소를 고려합니다. Azure Cosmos DB 분석 저장소는 데이터를 별도의 열 저장소에 자동으로 동기화하여 대규모 집계, 보고 및 분석 쿼리를 최적화합니다.

Azure Policy 정의

운영 우수성

워크로드가 배포된 후 워크로드를 모니터링하여 의도한 대로 작동하는지 확인해야 합니다. 또한 워크로드 모니터링은 계획 단계에서 즉시 명확하지 않은 새로운 효율성을 실현하는 데 도움이 될 수 있습니다. 치명적인 시나리오에서 진단 데이터는 심각도가 높은 인시던트가 발생한 이유를 파악하는 열쇠입니다. 이 섹션에는 워크로드의 이벤트 및 특성을 모니터링하기 위한 고려 사항 및 권장 사항이 포함되어 있습니다.

디자인 검사 목록

  • 다양한 워크로드를 구분하고, 예외 시나리오에 플래그를 지정하고, 예외/오류의 패턴을 추적하고, 호스트 컴퓨터 성능을 추적하기 위한 로그 및 메트릭 모니터링 전략 초안을 작성합니다.
  • 가능하면 대량 작업을 사용하도록 대규모 워크로드를 디자인합니다.
  • 제한을 모니터링하고, 처리량 할당을 분석하고, 데이터의 크기를 추적하는 여러 경고를 정의합니다.
  • 지역 전체에서 솔루션의 가용성을 위한 모니터링 전략을 설계합니다.
  • NoSQL 계정 및 리소스에 대한 Azure Cosmos DB 배포를 자동화하기 위한 모범 사례를 만들고 적용합니다.
  • 파티션 및 인덱스 디자인을 기반으로 예상 메트릭 임계값을 계획합니다. 이러한 메트릭을 모니터링하여 계획된 임계값에 얼마나 가까운지 확인할 계획이 있는지 확인합니다.

권장 사항

추천 장점
애플리케이션 개발자가 최신 버전의 개발자 SDK를 사용하고 있는지 확인합니다. NoSQL SDK용 각 Azure Cosmos DB에는 최소 권장 버전이 있습니다. 자세한 내용은 .NET SDK 및 Java SDK를 참조하세요.
워크로드를 구분하기 위해 클라이언트 애플리케이션에서 식별자를 만듭니다. 사용자 에이전트 접미사와 같은 플래그를 고려하여 각 로그 항목 또는 메트릭이 연결되어야 하는 워크로드를 식별합니다.
개발자 SDK를 사용하여 추가 진단 캡처합니다. 각 SDK에 대한 진단 삽입 기술을 사용하여 기본 메트릭 및 로그와 함께 워크로드에 대한 추가 정보를 추가합니다. 자세한 내용은 .NET SDK 및 Java SDK를 참조하세요.
호스트 컴퓨터 리소스와 연결된 경고를 만듭니다. 커넥트성 및 가용성 문제는 클라이언트 쪽 호스트 컴퓨터 문제로 인해 발생할 수 있습니다. NoSQL SDK용 Azure Cosmos DB를 사용하여 클라이언트 애플리케이션을 사용하여 호스트 머신에서 CPU, 메모리 및 스토리지와 같은 리소스를 모니터링합니다.
대규모 작업에는 클라이언트 SDK의 대량 기능을 사용합니다. 높은 수준의 처리량이 필요한 시나리오는 SDK의 대량 기능을 사용하면 이점을 얻을 수 있습니다. 대량 기능은 자동으로 작업을 관리하고 일괄 처리하여 처리량을 최대화합니다.
처리량 제한에 대한 경고를 만듭니다. 경고를 사용하여 예상 임계값을 초과하는 처리량 제한을 추적합니다. 시간이 지남에 따라 Azure Cosmos DB와 관련하여 워크로드에 대해 자세히 알아보면서 경고를 검토하고 조정합니다. 정규화된 RU 소비 메트릭은 데이터베이스 또는 컨테이너에서 프로비전된 처리량의 사용률을 측정하는 메트릭입니다. 이 메트릭이 일관되게 100%인 경우 요청은 일시적인 오류를 반환할 수 있습니다.
메트릭을 사용하여 쿼리 성능을 추적합니다. 메트릭을 사용하여 시간에 따른 상위 쿼리의 성능을 추적합니다. 인덱싱 정책을 업데이트하거나 쿼리를 변경하여 효율성을 찾을 수 있는지 평가합니다. 쿼리 성능이 좋지 않으면 성능 문제를 해결하고 쿼리 모범 사례를 적용합니다. 자세한 내용은 쿼리 성능 팁을 참조 하세요.
템플릿을 사용하여 계정 리소스를 자동으로 배포합니다. Azure Resource Manager, Bicep 또는 Terraform 템플릿을 사용하여 계정 및 후속 리소스의 배포를 자동화하는 것이 좋습니다. 팀이 동일한 템플릿을 사용하여 다른 비프로덕션 환경에 배포하는지 확인합니다.
주요 메트릭을 추적하여 워크로드의 일반적인 문제를 식별합니다. 특정 메트릭을 사용하여 워크로드에서 일반적인 문제(제한되지 않음 포함)를 찾습니다. RU 사용률, 파티션별 RU 사용률, 형식별 제한 및 요청 볼륨 자세한 내용은 모니터 데이터 참조를 참조하세요.

Azure Policy 정의

성능 효율성

  • 애플리케이션의 성능 기준을 정의합니다. 처리해야 할 수 있는 동시 사용자 및 트랜잭션 수를 측정합니다. 평균 사용자 흐름, 일반적인 작업 및 사용량 급증과 같은 워크로드 특성을 고려합니다.
  • 가장 일반적이고 가장 복잡한 쿼리를 조사합니다. 여러 조회, 조인 또는 집계를 사용하는 쿼리를 식별합니다. 파티션 키 또는 인덱싱 정책에 대한 디자인 고려 사항에서 이러한 쿼리를 고려합니다.
  • 가장 일반적인 쿼리의 경우 페이지당 예상 결과 수를 결정합니다. 이 숫자는 프리페치된 결과에 대해 버퍼링된 항목 수를 공식화하는 데 도움이 됩니다.
  • 대상 사용자를 조사합니다. 가장 가까운 Azure 지역을 결정합니다.
  • 하나 이상의 순서 지정 필드를 사용하는 쿼리를 식별합니다. 또한 여러 필드에 영향을 주는 작업을 식별합니다. 이러한 필드를 인덱싱 정책 디자인에 명시적으로 포함합니다.
  • 해당 JSON 문서가 가능한 한 작도록 항목을 디자인합니다. 필요한 경우 여러 항목 간에 데이터를 분할하는 것을 고려합니다.
  • 자식 배열에 대한 쿼리를 식별하고 보다 효율적인 하위 쿼리의 후보인지 확인합니다.
  • 워크로드에 분석 저장소가 필요한지 확인합니다. 매우 복잡한 쿼리를 위해 Azure Synapse Link와 같은 분석 저장소 및 서비스를 고려합니다.
추천 장점
성능 기준에 따라 처리량을 구성합니다. 용량 계산기와 같은 도구를 사용하여 성능 기준에 필요한 처리량의 양을 결정합니다. 자동 크기 조정과 같은 기능을 사용하여 실제 워크로드와 보다 밀접하게 일치하도록 실제 처리량의 크기를 조정합니다. 나중에 실제 처리량 소비량을 모니터링하고 조정합니다.
적절한 경우 클라이언트 및 서버 쪽에서 최적화 기술을 사용합니다. 기본 제공 통합 캐시를 활용합니다. 각 페이지에 대해 프리페치(버퍼링)되어 반환되는 항목 수를 관리하도록 SDK를 구성합니다.
최종 사용자에게 가장 가까운 지역에 NoSQL용 Azure Cosmos DB를 배포합니다. 최종 사용자에게 가장 가까운 지역에 NoSQL용 Azure Cosmos DB를 최대한 많이 배포하여 대기 시간을 줄입니다. 읽기 복제본(replica) 활용하여 쓰기 구성 방법(단일 지역 또는 여러 지역)에 관계없이 성능이 뛰어난 읽기 성능을 제공합니다. 최종 사용자에게 더 가까운 지역을 선호하도록 (.NET/Java) SDK를 구성합니다.
직접 모드에 대한 SDK를 구성합니다. 직접 모드는 최상의 성능을 위한 기본 옵션입니다. 이 모드를 사용하면 클라이언트가 서비스의 파티션에 직접 TCP 연결을 열고 중간 게이트웨이 없이 직접 요청을 보낼 수 있습니다. 이 모드는 네트워크 홉 수가 적기 때문에 더 나은 성능을 제공합니다.
대량 작업에 대해 인덱싱을 사용하지 않도록 설정합니다. 삽입/바꾸기/upsert 작업이 많은 경우 인덱싱을 사용하지 않도록 설정하여 해당 SDK의 대량 지원을 사용하는 동안 작업의 속도를 향상시킵니다. 인덱싱은 나중에 즉시 다시 사용할 수 있습니다.
복잡한 작업에 사용되는 필드에 대한 복합 인덱스를 만듭니다. 복합 인덱스는 크기 순으로 여러 필드에 대한 작업의 효율성을 높일 수 있습니다. 대부분의 경우 여러 필드가 있는 문에 ORDER BY 복합 인덱스를 사용합니다.
SDK에 대한 호스트 클라이언트 머신을 최적화합니다. 가장 일반적인 경우 SDK(.NET/Java)를 사용하여 64비트 호스트 머신에서 최소 4코어 및 8GB 메모리를 사용합니다. 또한 호스트 컴퓨터에서 가속화된 네트워킹을 사용하도록 설정합니다.
대부분의 SDK에서 클래스에 CosmosClient 싱글톤 패턴을 사용합니다. 대부분의 SDK에서 클라이언트 클래스를 싱글톤으로 사용합니다. 클라이언트 클래스는 자체 수명 주기를 관리하며 삭제되지 않도록 설계되었습니다. 인스턴스를 지속적으로 만들고 삭제하면 성능이 저하될 수 있습니다.
항목 크기를 100KB 미만으로 유지합니다. 더 큰 항목은 일반적인 읽기 및 쓰기 작업에 더 많은 처리량을 소비합니다. 모든 필드를 프로젝션하는 더 큰 항목에 대한 쿼리는 상당한 처리량 비용을 가질 수도 있습니다.
하위 쿼리를 전략적으로 사용하여 큰 데이터 집합을 조인하는 쿼리를 최적화합니다. 여러 배열이 관련되고 필터링되지 않은 경우 자식 배열을 조인하는 쿼리의 복잡성이 증가할 수 있습니다. 예를 들어 각각 10개 이상의 항목으로 구성된 두 개 이상의 배열을 조인하는 쿼리는 1,000개 이상의 튜플로 확장할 수 있습니다. 항목 내에서 배열을 조인하기 전에 하위 쿼리를 사용하여 배열을 필터링하여 자체 조인 식을 최적화합니다. 파티션 간 쿼리의 경우 파티션 키에 필터를 포함하도록 쿼리를 최적화하여 쿼리 라우팅을 가능한 최소 파티션으로 최적화합니다.
가장 복잡한 쿼리에 분석 워크로드를 사용합니다. 대규모 컨테이너를 통해 자주 집계를 실행하거나 쿼리를 조인하는 경우 분석 저장소를 사용하도록 설정하고 Azure Synapse Analytics에서 쿼리를 수행하는 것이 좋습니다.

Azure Policy 정의

추가 리소스

NoSQL용 Azure Cosmos DB와 관련된 더 많은 리소스를 고려합니다.

Azure 아키텍처 센터 지침

클라우드 채택 프레임워크 지침

다음 단계

Bicep 템플릿을 사용하여 NoSQL용 Azure Cosmos DB 계정 배포