MongoDB Search로 멀티 테넌시를 구현 애플리케이션 의 단일 인스턴스 여러 테넌트를 제공할 수 있습니다. 이 페이지에서는 테넌트 격리 유지하면서 안전하게 확장하다 수 있도록 데이터 및 MongoDB Search 인덱스를 구조화하기 위해 MongoDB Search에 특별히 적용 설계 권장 사항에 대해 설명합니다.
중요
이 지침 단일 VPC 내에 테넌트를 배치할 수 있다고 가정합니다. 엄격한 네트워크 격리 필요한 경우 각 테넌트에 대해 별도의 프로젝트를 유지 관리해야 합니다.
전략 선택
격리 요구 사항, 확장 목표, 쓰기-로드 요구 사항에 따라 전략을 선택하세요. 가장 일반적인 전략은 다음과 같습니다.
모든 테넌트를 위한 단일 컬렉션 - 이 전략은 대부분의 워크로드에 권장됩니다.
테넌트당 하나의 데이터베이스 - 이 전략은 높은 격리 제공하지만 인덱스 수가 증가합니다.
테넌트당 하나의 컬렉션 - 이 전략은 MongoDB Search 워크로드에는 권장되지 않습니다.
모든 테넌트를 위한 단일 컬렉션(권장)
모든 테넌트에 단일 컬렉션 전략을 적용하는 것이 좋습니다. 이 아키텍처에서는 모든 테넌트 데이터를 단일 데이터베이스 내의 단일 컬렉션 에 저장 . 각 문서 내에 tenant_id 필드 포함하여 테넌트를 구분할 수 있습니다. 이 필드 UUID 또는 테넌트 이름과 같은 테넌트의 고유 식별자일 수 있습니다.
이 중앙 집중식 접근 방식은 다음과 같은 이점을 제공합니다.
인덱스 수 감소
모든 테넌트 데이터가 하나의 컬렉션 에 저장되므로 모든 테넌트에 대한 문서를 제공하는 단일 인덱스 만 필요합니다. 클러스터 리소스 제한에 도달하지 않도록 방지할 수 있습니다. 예시 들어
tenant_id및 기타 공유 또는 테넌트별 필드를 단일 인덱스 에 포함할 수 있습니다.유지 관리 작업 간소화
모든 데이터를 저장하는 단일 컬렉션 만 사용하므로 여러 컬렉션을 유지 관리하거나 여러 데이터베이스에 걸쳐 리소스를 확장하다 필요가 없습니다. 또한 단일 데이터베이스 에서 단일 컬렉션 만 대상으로 지정하면 되므로 백업, 샤딩 및 복제 작업을 간소화할 수 있습니다.
쿼리 효율적으로 처리
$search.compound.filter절 내의 등호 연산자 사용하여 쿼리의tenant_id필드 필터하다 로 제공합니다.참고
쿼리 결과에는 일치하는 테넌트의 문서만 포함되므로 테넌트 간에 데이터가 유출되는 것을 방지할 수 있습니다.
함께 배치하는 테넌트가 유사한 액세스 패턴과 리소스 크기를 주식 경우 이 전략을 사용하면 Lucene 인덱스 필드 수도 적게 유지됩니다.
중요
모든 테넌트의 쓰기 (write) 로드가 높은 경우 모든 테넌트를 단일 컬렉션 에 배치하면 쓰기 (write) 경합이 발생할 수 있습니다. 이 시나리오에서는 쓰기 (write) 부하를 더 많은 기본 리소스에 분산할 수 있도록 쓰기 작업이 가장 많은 테넌트를 별도의 컬렉션으로 분할하는 것이 좋습니다.
고유한 리소스 또는 인덱싱 요구 사항이 있는 대규모 테넌트가 있는 경우 View:를 사용하세요.
별도로 인덱스합니다. 뷰에 MongoDB Search 인덱스 생성합니다.
이를 통해 다른 사람이 사용하는 공유 인덱스 영향을 주지 않고 대규모 테넌트에 대한 인덱스 정의를 사용자 지정할 수 있습니다. 다른 모든 테넌트는 단일 인덱스 사용할 수 있습니다.
인덱스 수가 많으면 기본 클러스터 에 상당한 부하가 발생하고 워크로드 중단될 수 있습니다. 단일 클러스터 의 검색 인덱스에 대한 엄격한 제한은 2,500입니다. 그러나 클러스터 지원 수 있는 인덱스 수는 클러스터 계층 및 워크로드 에 따라 다릅니다.
M10와 같은 소규모 클러스터 계층에서는 훨씬 적은 수의 인덱스로 인해 성능 저하 또는 메모리 부족 오류가 발생할 수 있습니다. 적은 수의 인덱스로 시작하여 확장하다 에 따라 클러스터의 리소스 사용량을 모니터 .
현재 테넌트당 하나의 컬렉션 전략을 적용 경우, 많은 수의 인덱스로 인한 리소스 경합으로 인해 복제 지연 OOM 오류가 증가하는 것을 방지하기 위해 기본 계층 확장 것이 좋습니다. 또한 모든 테넌트를 위한 단일 컬렉션 전략으로 마이그레이션하는 것이 좋습니다.
쓰기 횟수가 많은 테넌트 처리
특정 테넌트에 쓰기 (write) 로드가 많은 경우 공유 컬렉션 에서 경합이 발생할 수 있습니다. I/O 로드를 분산하기 위해 가장 볼륨이 큰 테넌트만 별도의 컬렉션으로 이동하는 것이 좋습니다.
고유 요구 사항 처리(뷰)
테넌트에 고유한 인덱싱 필요하거나 테넌트가 다른 테넌트보다 훨씬 큰 경우 MongoDB View:를 사용하세요.
테넌트당 데이터베이스 1개
테넌트별 데이터베이스 설정 에서 각 테넌트는 자체 데이터베이스 포함합니다. 이 설정 테넌트 데이터를 격리하지만 클러스터 의 인덱스 수도 증가합니다. 모든 테넌트를 지원하는 데이터베이스가 2개를 초과하는500 경우, 클러스터 인덱스 한도인 2개에500도달할 수 있습니다.
경고
인덱스 수가 많으면 기본 클러스터 에 상당한 부하가 발생하고 워크로드 중단될 수 있습니다. 단일 클러스터 의 검색 인덱스에 대한 엄격한 제한은 2,500입니다. 그러나 클러스터 지원 수 있는 인덱스 수는 클러스터 계층 및 워크로드 에 따라 다릅니다. M10 와 같은 소규모 클러스터 계층에서는 훨씬 적은 수의 인덱스로 인해 성능 저하 또는 메모리 부족 오류가 발생할 수 있습니다. 적은 수의 인덱스로 시작하여 확장하다 에 따라 클러스터의 리소스 사용량을 모니터 .
테넌트당 하나의 컬렉션(권장하지 않음)
테넌트별 컬렉션 전략은 각 테넌트를 공유 데이터베이스 내의 자체 컬렉션 에 매핑합니다. 컬렉션 당 인덱스 유지 관리하는 오버헤드 인해 다음이 발생할 수 있습니다.
복제 지연 증가
리소스 경합으로 인한 OOM 오류
기본 계층 의 불안정성
테넌트에 예측 가능하고 간단한 워크로드가 있는 경우가 아니라면 MongoDB Search에는 이 전략을 사용하지 않는 것이 좋습니다. 현재 이 전략을 사용하는 경우 모든 테넌트를 위한 단일 컬렉션 전략으로 마이그레이션 .
인덱싱된 필드 관리
인덱싱된 필드를 관리 하려면 다음 권장 사항을 고려하세요.
멀티 테넌트 애플리케이션에는 검색, 정렬, 패싯 및 필터링이 가능한 사용자 지정 테넌트별 필드가 필요한 경우가 많습니다. typeSet 를 사용하여 경로의 하위 필드를 동적으로 인덱스 하여 전체 인덱스 다시 작성하지 않고도 MongoDB Search가 새 필드를 자동으로 선택하도록 합니다. 이러한 필드를 정적으로 인덱싱하면 재구축이 트리거되어 CPU 압박이 가중되고 인덱스의 디스크 공간을 최대 2배 사용하므로 이러한 필드를 정적으로 인덱싱 하지 않도록 합니다.
참고
필드가 너무 많음
고유 필드가 1000 개보다 많은 경우 루센 인덱스 성능이 저하될 수 있습니다. MongoDB Search 지표에서 MongoDB Search 인덱스의 고유 필드 수를 모니터 할 수 있습니다. 1,000개 이상의 필드를 지원 해야 하는 경우 다음을 권장합니다.
View를 사용하여 테넌트의 하위 집합을 별도의 인덱스 로 분리하여 단일 Lucene 인덱스 에 존재하는 고유한 필드 수가 1,000개 미만으로 유지되도록 합니다.
단일 테넌트가 추가할 수 있는 필드 수를 제한합니다.
속성 패턴 사용하여 테넌트별로 다른 키를 저장 하는 경우 다음을 수행하는 것이 좋습니다.
뷰를 사용하여 내장된 문서 배열 평면화합니다.
디스크에 저장된 View에 MongoDB Search 인덱스 생성합니다.
문서 배열을 평면화하지 않는 경우, 속성을 쿼리하려면 embeddedDocuments 연산자 쿼리( $elemMatch와 유사)를 사용해야 하며, 이는 평면화된 구조를 쿼리하는 것보다 성능이 떨어집니다.