MongoDB Search를 위한 멀티테넌트 아키텍처 구축

모든 테넌트를 위한 단일 컬렉션(권장)

모든 테넌트에 단일 컬렉션 전략을 적용하는 것이 좋습니다. 이 아키텍처에서는 모든 테넌트 데이터를 단일 데이터베이스 내의 단일 컬렉션 에 저장 . tenant_id 각 문서 내에 필드 포함하여 테넌트를 구분할 수 있습니다. 이 필드 UUID 또는 테넌트 이름과 같은 테넌트의 고유 식별자일 수 있습니다.

이 중앙 집중식 접근 방식은 다음과 같은 이점을 제공합니다.

• 인덱스 수 감소

  모든 테넌트 데이터가 하나의 컬렉션 에 저장되므로 모든 테넌트에 대한 문서를 제공하는 단일 인덱스 만 필요합니다. 클러스터 리소스 제한에 도달하지 않도록 방지할 수 있습니다. 예시 들어 tenant_id 및 기타 공유 또는 테넌트별 필드를 단일 인덱스 에 포함할 수 있습니다.

• 유지 관리 작업 간소화

  모든 데이터를 저장하는 단일 컬렉션 만 사용하므로 여러 컬렉션을 유지 관리하거나 여러 데이터베이스에 걸쳐 리소스를 확장하다 필요가 없습니다. 또한 단일 데이터베이스 에서 단일 컬렉션 만 대상으로 지정하면 되므로 백업, 샤딩 및 복제 작업을 간소화할 수 있습니다.

• 쿼리 효율적으로 처리

  절 내의 등호 연산자 사용하여 쿼리의 필드 tenant_id $search.compound.filter 필터하다 로 제공합니다.

  참고

  쿼리 결과에는 일치하는 테넌트의 문서만 포함되므로 테넌트 간에 데이터가 유출되는 것을 방지할 수 있습니다.

함께 배치하는 테넌트가 유사한 액세스 패턴과 리소스 크기를 주식 경우 이 전략을 사용하면 루센 인덱스 필드 수도 적게 유지됩니다.

고유한 리소스 또는 인덱싱 요구 사항이 있는 대규모 테넌트가 있는 경우 View를 사용하세요.

1. 테넌트를 격리합니다. 테넌트의 문서만 필터하다 $expr 하는 $match 작업과 함께 를 사용하여 뷰를 만듭니다.

2. 별도로 인덱스합니다. 뷰에 MongoDB Search 인덱스 생성합니다.

   이를 통해 다른 사람이 사용하는 공유 인덱스 영향을 주지 않고 대규모 테넌트에 대한 인덱스 정의를 사용자 지정할 수 있습니다. 다른 모든 테넌트는 단일 인덱스 사용할 수 있습니다.

   클러스터 당 2500 개의 인덱스를 초과하면 기본 클러스터 에 높은 부하가 발생하고 데이터베이스 워크로드 방해할 위험이 있으므로 권장하지 않습니다.

현재 테넌트당 하나의 컬렉션 전략을 적용 경우,많은 수의 인덱스로 인한 리소스 경합으로 인해 복제 지연 OOM 오류가 증가하지 않도록 기본 계층 확장 것이 좋습니다. 또한 모든 테넌트를 위한 단일 컬렉션 전략으로 마이그레이션하는 것이 좋습니다.

테넌트당 데이터베이스 1개

테넌트별 데이터베이스 설정 에서 각 테넌트는 자체 데이터베이스 포함합니다. 이 설정 테넌트 데이터를 격리하지만 클러스터 의 인덱스 수도 증가합니다. 각 테넌트에 인덱싱된 필드가 많은 경우 클러스터 2500- 인덱스 한도에 도달할 수 있습니다.

테넌트당 하나의 컬렉션(권장하지 않음)

테넌트별 컬렉션 전략은 각 테넌트를 공유 데이터베이스 내의 자체 컬렉션 에 매핑합니다. 컬렉션 당 인덱스 유지 관리하는 오버헤드 인해 다음이 발생할 수 있습니다.

• 복제 지연 증가

• 리소스 경합으로 인한OOM 오류

• 기본 계층 의 불안정성

테넌트에 예측 가능하고 간단한 워크로드가 있는 경우가 아니라면 MongoDB Search에는 이 전략을 사용하지 않는 것이 좋습니다. 현재 이 전략을 사용하는 경우 모든 테넌트를 위한 단일 컬렉션 전략으로 마이그레이션 .