Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

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

MongoDB Vector Search를 사용하여 멀티 테넌시를 구현 애플리케이션 의 단일 인스턴스 여러 테넌트를 제공할 수 있습니다. 이 페이지에서는 특히 MongoDB Vector Search에 적용 설계 권장 사항에 대해 설명합니다. 이러한 권장 사항은 Atlas 에 대한 멀티 테넌시 권장 사항과 다릅니다.

MongoDB Vector Search용 멀티 테넌트 아키텍처를 설계할 때는 다음 권장 사항을 참조하세요.

중요

이 지침 단일 VPC 내에 테넌트를 배치할 수 있다고 가정합니다. 그렇지 않으면 각 테넌트에 대해 별도의 프로젝트를 유지 관리해야 하며, 이는 MongoDB Vector Search에 권장되지 않습니다.

모든 테넌트 데이터를 단일 컬렉션 과 단일 데이터베이스 및 클러스터 에 저장하는 것이 좋습니다.tenant_id 각 문서 내에 필드 포함하여 테넌트를 구분할 수 있습니다. 이 필드 UUID 또는 테넌트 이름과 같은 테넌트의 고유 식별자일 수 있습니다. 이 필드 MongoDB Vector Search 인덱스 및 쿼리에서사전 필터로 사용할 수 있습니다.

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

  • 모델링 및 확장 용이

  • 유지 관리 작업 간소화

  • tenant_id를 사용한 사전 쿼리 필터링으로 효율적인 쿼리 라우팅

    참고

    이 필터와 일치하지 않는 테넌트에게는 데이터가 제공되지 않도록 보장됩니다.

다음과 같은 이유로 각 테넌트를 별도의 컬렉션이나 데이터베이스에 저장하지 않는 것이 좋습니다.

  • 성능에 미치는 영향: 이 접근 방식은 컬렉션 수에 따라 변경 스트림 로드가 달라질 수 있으며, 이로 인해 성능 및 모니터링 기능에 부정적인 영향 수 있습니다.

  • 추가 격리 없음: Atlas 의 데이터 격리 보장 데이터베이스 수준에서 적용 . 동일한 데이터베이스 내에서 별도의 컬렉션을 사용하면 추가적인 데이터 격리 이점이 제공되지 않습니다. 별도의 데이터베이스를 사용하면 대부분의 사용 사례에서 의미 있는 보안 이점 없이 운영이 복잡해집니다.

대신 모든 테넌트를 위한 단일 컬렉션을 사용하는 것이 좋습니다. 테넌트당 하나의 컬렉션 모델에서 단일 컬렉션 모델로 마이그레이션하는 방법의 예시는 테넌트당 하나의 컬렉션 모델에서 마이그레이션하기를 참조하세요.

권장되는 접근 방식에서 발생할 수 있는 성능 문제를 완화하려면 다음과 같은 전략들을 고려해 보세요.

각각 상대적으로 벡터 수가 적은 테넌트가 많거나 데이터의 불균등한 배포(일부 대규모 테넌트와 다수의 소규모 테넌트)로 인해 성능 문제가 발생하는 경우 다음 전략을 고려하는 것이 좋습니다.

테넌트가 많고(최대 1 백만 개) 있고 각 테넌트에 벡터가 상대적으로 적은 경우(각각 10 미만,000 벡터), 기본값 Hierarchical Navigable Small Worlds 대신 flat 인덱스 사용합니다. 플랫 인덱스 만들려면 인덱스 정의에서 indexingMethod 필드를 flat설정하다.

각 테넌트에 소수의 벡터가 있는 경우 특정 테넌트로 필터링된 쿼리는 이미 철저하게 검색된 것입니다. 이러한 경우 Hierarchical Navigable Small Worlds 그래프 이점이 없지만 메모리 및 유지 관리 오버헤드 추가됩니다. 플랫 인덱스는 이러한 불필요한 오버헤드 제거합니다.

플랫 인덱스는 멀티 테넌트 워크로드에 다음과 같은 이점을 제공합니다.

  • 선택적 필터에 최적화됨: 각 테넌트에 소수의 벡터가 있는 고도로 선택적인 쿼리의 경우, 전체 스캔이 이미 가장 빠른 경로입니다. 플랫 인덱스가 이를 직접 지원 지연 시간 과 리콜을 모두 개선합니다.

  • 예측 가능한 성능: 쿼리 지연 시간 어떤 테넌트를 대상으로 하는지에 관계없이 타이트한 밴드 내에 유지되므로 테넌트 간에 잡음이 많은 이웃 효과가 제거됩니다.

  • 리소스 효율성: 플랫 인덱스는 Hierarchical Navigable Small Worlds 그래프 작성과 관련된 메모리 및 유지 관리 오버헤드를 제거합니다.

예시

다음 인덱스 정의는 tenant_id 필터 필드 있는 플랫 인덱스 만듭니다.

{
"fields": [
{
"type": "vector",
"path": "<fieldToIndex>",
"numDimensions": <numberOfDimensions>,
"similarity": "euclidean | cosine | dotProduct",
"indexingMethod": "flat"
},
{
"type": "filter",
"path": "tenant_id"
}
]
}

참고

플랫 인덱스는 스칼라 및 이진 양자화와 호환됩니다. 플랫 인덱스를 사용할 때는 항상 쿼리에 tenant_id 필드를 사전 필터 로 포함하세요.

각각 10,000 개 이상의 벡터가 있는 대규모 테넌트의 경우, Hierarchical Navigable Small Worlds 인덱스를 MongoDB Views 에서 사용하여 대규모 테넌트와 소규모 테넌트를 구분합니다.

  • 대형 테넌트(상위 1%):

    • 각 대형 테넌트에 대해 뷰 생성

    • 각 뷰에 대해 Hierarchical Navigable Small Worlds 인덱스 만듭니다.

    • 쿼리 시점에 확인할 대형 테넌트의 기록을 유지하여 쿼리를 적절히 라우팅

  • 소형 테넌트(잔여 테넌트):

    • 모든 소형 테넌트에 대해 단일 뷰 생성

    • 이 뷰에 대한 단일 플랫 인덱스 빌드합니다.

    • tenant_id 필드를 사전 필터로 사용해 쿼리를 적절히 라우팅

다음 예시는 mongosh를 사용하여 대규모 및 소형 테넌트에 대한 뷰를 만드는 방법을 보여줍니다.

대형 테넌트와 해당 tenant_id 값을 기록하고, 각 테넌트에 대한 뷰 생성:

db.createView(
"<viewName>",
"<collectionName>",
[
{
"$match": {
"tenant_id": "<largeTenantId>"
}
}
]
)

대형 테넌트를 필터링하여 소형 테넌트에 대한 뷰를 만듭니다.

db.createView(
"<viewName>",
"<collectionName>",
[
{
"$match": {
"tenant_id": {
"$nin": [ "<largeTenantId1>", "<largeTenantId2>", ... ]
}
}
}
]
)

뷰를 생성한 후 각 뷰에 대해 인덱스를 만듭니다. 다음을 확인하세요:

  • 인덱스의 컬렉션 이름을 지정할 때는 원래 컬렉션 이름 대신 뷰 이름을 사용해야 합니다.

  • 대규모 테넌트 뷰의 경우 Hierarchical Navigable Small Worlds 인덱스 (기본값)를 만듭니다.

  • 소규모 테넌트 뷰의 경우 플랫 인덱싱 메서드 를 사용하여 인덱스 만들고 tenant_id 필드 사전 필터로 포함합니다.

인덱스를 만드는 방법에 대한 지침은 인덱스 생성 페이지를 참조하세요.

여러 테넌트가 각각 많은 벡터를 가지고 있는 경우, 데이터를 샤드에 분산하여 파티션 기반 시스템을 사용하는 것을 고려하세요.

tenant_id 필드를 샤드 키로 사용하면 테넌트 ID를 기준으로 특정 범위에 데이터를 분산할 수 있습니다. 자세한 내용은 샤딩 범위 지정을 참조하세요.

테넌트당 하나의 컬렉션 모델에서 단일 컬렉션 모델로 마이그레이션하려면 각 테넌트 컬렉션을 처리하고 새 컬렉션에 문서를 삽입합니다.

돌아가기

추가 권장 사항

이 페이지의 내용