동일한 복제본 세트 에 있는 컬렉션은 리소스를 두고 경쟁할 때 성능 병목 현상이 발생할 수 있습니다. 데이터가 사용 가능한 메모리를 초과하여 증가하면 디스크 I/O가 증가하면 지연 시간 발생하고 시스템 리소스에 부하가 걸리므로 전체 애플리케이션 성능이 저하됩니다. 클러스터 내의 전용 샤드에서 컬렉션을 격리하면 애플리케이션 에 대한 단일 연결 점 유지하면서 이러한 리소스 제약 조건을 줄일 수 있습니다.
컬렉션 격리의 이점:
워크로드 분리 - 특정 샤드에 컬렉션을 할당하여 리소스 경합을 방지합니다.
하드웨어 최적화 - 특정 컬렉션 사항에 맞게 조정된 hardware로 비대칭 샤드 를 구성합니다.
독립적인 확장 - 워크로드 증가에 따라 컬렉션을 개별적으로 확장합니다.
복원력 향상 - 잠재적 장애를 격리하여 복구 시간을 줄입니다.
사용 시기 moveCollection
전용 샤드로 컬렉션을 이동하는 것은 컬렉션 요구 사항이 다음과 같이 다양한 경우에 특히 유용합니다.
요구 사항 | 설명 |
|---|---|
액세스 패턴 | 일부 컬렉션은 읽기 위주이고 다른 컬렉션은 쓰기 위주입니다. |
성능 | 특정 컬렉션에는 다른 컬렉션보다 더 많은 RAM, CPU 또는 디스크 처리량 필요합니다. |
확장성 요구 사항 | 성장 패턴이 빠르거나 예측할 수 없는 컬렉션에는 전용 hardware 필요합니다. |
특정 요구 사항을 충족하는 데 필요한 hardware 있는 샤드에 컬렉션을 할당하면 운영 단순성을 유지하면서 성능이 최적화됩니다.
샤딩되지 않은 컬렉션을 이동해야 하는 경우
MongoDB 8.0부터 이동식 컬렉션 을 사용하면 클러스터 내의 모든 샤드에 샤딩되지 않은 컬렉션을 전략적으로 배치할 수 있습니다. 이전에는 샤딩되지 않은 컬렉션이 데이터베이스 의 프라이머리 샤드 로 제한되어 리소스 병목 현상이 발생했습니다. 컬렉션 이동 하면 워크로드를 중단하지 않고 샤딩되지 않은 컬렉션을 재배치할 수 있으므로 수평 확장 간소화됩니다.
모든 컬렉션 샤딩된 할 필요는 없지만, 샤딩된 클러스터 배포하면 샤딩되지 않은 컬렉션의 경우에도 수평 확장 이점을 얻을 수 있습니다. 이 접근 방식은 모든 데이터 액세스 대한 단일 연결 점 유지하여 애플리케이션 아키텍처를 간소화합니다.
다음 시나리오는 샤드 간에 샤딩되지 않은 컬렉션을 이동하면 얻을 수 있는 이점이 있습니다.
워크로드 격리
여러 컬렉션이 동일한 클러스터 내에서 서로 다른 워크로드를 제공 경우, 샤딩되지 않은 컬렉션을 서로 다른 샤드로 이동하면 리소스 경합을 방지하는 데 도움이 됩니다. 이러한 분리는 한 워크로드의 성능이 다른 워크로드의 성능에 부정적인 영향을 미치는 문제를 제거합니다.
멀티 테넌트 아키텍처
다양한 테넌트에 대한 컬렉션을 호스팅하는 환경에서 MongoDB의 명령을 사용하면 다운타임 없이 샤드 간에 컬렉션을 원활하게 배포할 수 있습니다. 이러한 유연성은 각 테넌트의 특정 요구 사항에 따라 리소스 할당을 최적화합니다.moveCollection
지리적 데이터 배포
조직은 데이터 주권 규정을 준수하기 위해 특정 지리적 리전에 사용자 데이터를 저장 해야 할 수 있습니다. moveCollection을 사용하면 샤딩되지 않은 컬렉션을 다른 리전의 샤드에 배치하고 규제 요구 사항이 발전함에 따라 재배치할 수 있습니다.
비용 최적화
MongoDB 8.0 이전에는 데이터베이스 내의 모든 샤딩되지 않은 컬렉션이 프라이머리 샤드 로 제한되었습니다. 이러한 제한으로 인해 더 크고 더 비싼 인스턴스 계층으로 업그레이드해야 하는 경우가 많습니다. MongoDB 8.0 은 이 제약 조건을 제거하여 클러스터 의 사용 가능한 모든 샤드에서 샤딩되지 않은 컬렉션을 이동할 수 있도록 합니다.
비대칭 샤드 hardware 간에 샤딩되지 않은 컬렉션을 이동하면 리소스 최적화에 상당한 이점을 제공하므로 요구 사항에 맞는 hardware 에 특정 컬렉션을 배치할 수 있습니다. 컬렉션을 적절한 hardware 리소스에 매칭하면 실제 수요에 따라 다양한 워크로드를 독립적으로 확장하다 할 수 있습니다. 이 타겟팅된 접근 방식은 전체 클러스터 에서 리소스를 과도하게 프로비저닝하는 데 비용 피하면서 성능을 향상시킵니다.
컬렉션 밀도 감소
MongoDB 에는 인스턴스 당 컬렉션 수에 대한 엄격한 제한이 없지만 노드 너무 많은 컬렉션과 인덱스를 관리하면 성능이 저하됩니다. 이러한 제한에 대해 자세히 학습하려면 MongoDB Atlas 컬렉션 및 인덱스 제한을 참조하세요.
샤딩되지 않은 컬렉션을 서로 다른 샤드에 분산하면 애플리케이션에 대한 통합 액세스 점 유지하면서 단일 노드 의 컬렉션 밀도를 줄일 수 있습니다.
전략적인 코로케이션
컬렉션 간 트랜잭션 또는 조인 작업($lookup)과 같은 분산된 작업을 최소화하려면 동일한 샤드에 샤딩되지 않은 컬렉션을 함께 배치하는 것이 좋습니다. 관련 작업을 단일 샤드 로 제한하면 네트워크 오버헤드 없어지고, 지연 시간 줄어들고, 전반적인 성능이 향상됩니다. 이 접근 방식은 동일한 트랜잭션 에서 자주 결합되거나 함께 액세스되는 컬렉션에 특히 효과적입니다.
명령 구문
sh.moveCollection("database.collection", "shardName")
다음 예시 컬렉션의 균등한 배포를 위해 4개의 샤딩되지 않은 컬렉션 두 샤드 간에 이동합니다.
db.adminCommand({moveCollection:"E", toShard: "shard1"})
사용을 피해야 하는 경우 moveCollection
moveCollection 은(는) 상당한 유연성을 제공하지만 최적의 솔루션이 아닐 수 있는 몇 가지 특정 시나리오가 있습니다.
대규모 컬렉션
컬렉션 단일 샤드 에 비해 너무 큰 경우에는 moveCollection 을(를) 사용하지 마세요. 컬렉션 크기가 3 TB에 가까워지면 컬렉션 샤딩 것이 좋습니다.
Atlas Search 인덱스가 있는 컬렉션
특정 컬렉션 Atlas Search 사용하는 경우 moveCollection 는 리샤딩 을 사용하여 다른 샤드에 컬렉션 다시 작성한다는 점에 유의하세요. 컬렉션 이동한 후에는 해당 Atlas Search 인덱스 수동으로 다시 작성해야 합니다. 인덱스가 완전히 재구축될 때까지는 이 특정 컬렉션 에 대해 Atlas Search 기능을 사용할 수 없지만, 나머지 애플리케이션 정상적으로 작동합니다.
moveCollection를 사용하기 전에 애플리케이션 요구 사항에 대해 이러한 제한 사항을 평가하여 적절한 솔루션인지 확인하세요.