/ /

MongoDB Vector Search 벤치마크 개요

이 페이지에서는 MongoDB Vector Search의 주요 성능 최적화 전략과 이를 사용하여 벤치마크를 만든 방법을 설명합니다. 이 가이드 해석하는 방법을 학습하려면 이 벤치마크 사용 방법을 참조하세요.

벤치마크 소개

벤치마크에 사용된 데이터셋과 환경에 대한 정보입니다.

벤치마크의 경우 가 포함된 대규모 전자상거래 데이터 세트인 Amazon 리뷰 데이터 2023 571 54세트를 33 1996 2023사용했습니다. 제품 카테고리에 걸친 수백만 개의 리뷰로, 부터 9월 까지의 상호 작용을 나타냅니다. 이 리뷰에서 다루는 약 48.2 백만 개의 고유 항목이 있으므로 사용자 리뷰(평점, 텍스트, 유용성 투표), 항목 메타데이터 (설명, 가격, 이미지), 사용자-항목 상호 작용 그래프 등 풍부한 멀티모달 데이터를 제공합니다. . 항목 데이터 세트(5.5M 및.15 3M)에 포함되며,voyage-3-large 다음 로직을 통해 다음과 같은 방식으로 임베딩할 수 있습니다.

source = "Item: Title: " + record["title"] + " Description: " + record["description"]
source_embedding = vo.embed(source, model="voyage-3-large", input_type="document", output_dimension=2048)

필터의 결과 품질은 ANN 쿼리 의 결과와 동일한 텍스트 입력 및 요청된 벡터 수에 대한 해당 float ENN의 정확한 결과를 사용하여 Jaccard 유사성()을intersection / expected number of results 계산하여 결정됩니다. 재현율은 50 전자상거래 데이터 세트에 대해 물을 수 있는 샘플 쿼리의 평균 교집합을 찾아 계산합니다.

참고

벤치마킹에 사용되는 소스 코드 와 소스 데이터 세트를 임베드하는 데 사용되는 코드를 확인하려면 성능 테스트 리포지토리.를 참조하세요.

성능에 영향을 미치는 요인

이 섹션에서는 MongoDB Vector Search의 성능에 영향 몇 가지 요인과 이를 테스트하기 위해 벤치마크를 구성한 방법을 간략하게 설명합니다.

양자화

양자화는 벡터 임베딩의 정밀도를 낮춰 메모리 사용량을 줄이고 검색 속도를 높이지만 검색 정확도가 일부 저하될 수 있습니다.

스칼라 양자화

스칼라 양자화는 32비트 부동소수점 벡터를 8비트 정수로 변환하여 메모리 사용량을 4배 줄입니다. 정수 벡터 비교는 부동소수점 벡터에 비해 계산 시간이 짧고 리소스도 적게 소모되지만, 검색 정확도에서는 손실이 발생할 수 있습니다.

이진 양자화

이진 양자화는 벡터를 1비트 표현으로 변환하여 메모리 사용량을 32배 줄입니다. 이진 벡터 비교는 해밍 거리를 계산하며, 정수형 벡터에 비해 계산 시간이 더 짧고 리소스도 적게 소모됩니다. 그러나 부동소수점 벡터에서 이진 벡터로 전환할 때 검색 정밀도의 손실이 매우 크기 때문에, 이를 보완하기 위해 지연 시간이 증가하는 재스코어링 단계를 추가합니다. 쿼리 시, 검색 과정에서 누적된 상위 numCandidates 항목은 디스크에 저장된 전체 충실도 벡터를 기준으로 재정렬된 후 상위 limit 결과가 반환됩니다.

벡터 차원 수

Voyage AI의 voyage-3-large 모델을 사용해 중간 크기(5.5M/550만 개)와 대형(15.3M/1,530만 개) 벡터 데이터셋을 임베딩했습니다. 이 임베딩 모델은 여러 IR 벤치마크에서 우수한 성능을 보였고, Matryoshka 표현 학습과 양자화를 고려하여 훈련되었기 때문에 선택되었습니다. 따라서 양자화를 활성화해도 더 낮은 차원이나 대용량 벡터 환경에서도 우수한 성능을 보입니다.

뷰 인덱싱 을 활용하여 소스 2048차원 벡터의 처음 N개 차원을 잘라 1024, 512, 256차원 벡터를 생성하고 이들 역시 소스 필드와 동일하게 인덱싱했습니다.

참고

뷰에서 벡터 검색 인덱스를 생성하려면 MongoDB 버전 8.1 이상을 사용해야 합니다.

데이터셋 보기

더 큰 컬렉션에서 뷰를 생성하기 위해 사용된 MongoDB 셸 명령입니다.

db.createView(
  "all_dims_amazon_dataset",
  "2048d_amazon_dataset",
  [
    {
      $addFields: {
        "1024_embedding": { $slice: ["$embedding", 1024] },
        "512_embedding": { $slice: ["$embedding", 512] },
        "256_embedding": { $slice: ["$embedding", 256] }
      }
    }
  ]
)

인덱스 사용됨

뷰에 인덱스를 생성하기 위해 사용된 MongoDB 셸 명령입니다.

db.all_dims_amazon_dataset.createSearchIndex(
  "all_dims_vector_index",
  "vectorSearch",
  {
    "fields": [
      {
        "numDimensions": 2048,
        "path": "embedding", // original 2048d embedding produced by voyage-3-large
        "quantization": "scalar", // adjust to binary when needed
        "similarity": "dotProduct",
        "type": "vector"
      },
      {
        "numDimensions": 1024,
        "path": "1024_embedding",
        "quantization": "scalar",
        "similarity": "cosine", // sliced embeddings aren't normalized, so must use cosine
        "type": "vector"
      },
      {
        "numDimensions": 512,
        "path": "512_embedding",
        "quantization": "scalar",
        "similarity": "cosine",
        "type": "vector"
      },
      {
        "numDimensions": 256,
        "path": "256_embedding",
        "quantization": "scalar",
        "similarity": "cosine",
        "type": "vector"
      }
    ]
  }
)

각 위치에서의 다양한 표현과 마찬가지로 벡터의 차원 수가 다르면 각 벡터의 표현력에도 영향을 미칩니다. 따라서, 특히 2048차원 부동소수점 등가 최근접 이웃 기준과 비교할 때 256차원 벡터보다 2048차원 벡터에서 더 높은 정확도를 달성할 수 있습니다.

고차원 벡터는 저차원 벡터에 비해 더 많은 저장 과 메모리가 필요할 뿐만 아니라, 쿼리 속도가 다소 느리지만 MongoDB Vector Search가 벡터 비교를 수행할 때 SIMD 명령어를 활용하므로 이러한 문제가 크게 완화됩니다.

필터링

또한 15.3M(1,530만 개)의 항목을 모두 포함하는 컬렉션에 별도의 인덱스 정의도 생성했습니다. 인덱스에는 두 필드에 대한 필터가 포함되어 있어, 이 데이터셋에 대해 사전 필터링 쿼리를 수행할 수 있습니다.

인덱스 사용됨

더 큰 MongoDB 컬렉션에 인덱스를 생성하기 위해 사용되는 MongoDB shell 명령입니다.

db.large_amazon_dataset.createSearchIndex(
  "vectorSearch",
  "large_vector_index",
  {
    "fields": [
      {
        "numDimensions": 2048,
        "path": "embedding",
        "quantization": "scalar", // adjust to binary when needed
        "similarity": "dotProduct",
        "type": "vector"
      },
      {
        "path": "category",
        "type": "filter"
      },
      {
        "path": "price",
        "type": "filter"
      }
    ]
  }
)

대규모 인덱스된 데이터셋에 대해 필터링되지 않은 벡터 검색 쿼리와 필터링된 쿼리 모두를 실행했습니다.

# unfiltered query
query = [
  {
    "$vectorSearch": {
      "index": "large_vector_index",
      "path": "embedding",
      "queryVector": embedding.tolist(),
      "limit": k,
      "numCandidates": candidates,
    }
  },
  {
    "$project": {"embedding": 0}
  }
]

# filtered query
query = [
  {
    "$vectorSearch": {
      "index": "large_vector_index",
      "path": "embedding",
      "queryVector": embedding.tolist(),
      "limit": k,
      "numCandidates": candidates,
      "filter": {"$and": [{'price': {'$lte': 1000}}, {'category': {'$eq': "Pet Supplies"}}]}
    }
  },
  {
    "$project": {"embedding": 0}
  }
]

참고

두 쿼리 패턴 모두 $project 단계를 사용하여 출력에서 임베딩된 필드를 제외합니다. 지연 시간을 줄이기 위해 항상 이 방식을 권장합니다. 다만, 결과에서 임베딩이 필요하다면 예외입니다.

검색 노드 구성

MongoDB 벡터 검색 성능은 프라이머리 데이터베이스 워크로드와 별도로 벡터 계산을 처리하는 전용 검색 노드를 통해 확장되며, 전용 hardware 인스턴스를 효율적으로 사용합니다. 모든 테스트는 M20 기본 클러스터 사용하여 수행되었지만 테스트 유형에 따라 테스트 사례에 더 적합하도록 사용되는 검색 노드를 재구성했습니다. 모든 테스트는 AWS us-east-1의 검색 노드를 사용하여 실행 되었으며, us-east-1 의 EC2 인스턴스 도 요청을 수행했습니다. AWS에서 프로비저닝할 수 있는 검색 노드에는 세 가지 유형이 있으며, 이는 사용 가능한 디스크, RAM 및 vCPU 측면에서 다릅니다.

노드 유형	리소스 프로필	권장 사용법
낮은 CPU	디스크 대 메모리 비율이 낮음(~6:1), vCPU 수가 적음	양자화를 활용하지 않는 여러 벡터 워크로드에 적합한 시작점
높은 CPU	디스크 대 메모리 비율이 높음(~25:1), vCPU가 높음	고 QPS 워크로드 또는 양자화 기술을 활용하는 워크로드에 최적화된 선택
스토리지 최적화	디스크 대 메모리 비율이 높고(~25:1), vCPU 수가 적음	양자화를 활용하는 워크로드에 적합한 비용 효율적인 선택

Amazon 데이터셋 크기 조정

768차원 부동 소수점 벡터는 디스크에서 ~3kb 공간을 차지합니다. 이 리소스 요구 사항은 벡터 수와 각 벡터의 차원 수에 따라 선형적으로 확장됩니다. 1M 768d 벡터가 ~3GB 차지합니다. 1M 1536d 는 ~6GB 차지합니다.

양자화를 사용하여 디스크에 저장된 고충실도 벡터로부터 메모리에 저장할 표현 벡터를 생성합니다. 이렇게 하면 스칼라 양자화의 경우 3.75배, 이진 양자화의 경우 24배까지 필요한 메모리를 줄일 수 있지만 양자화되지 않은 벡터와 양자화된 벡터를 모두 저장해야 하므로 디스크 공간 요구량은 증가합니다.

스칼라 양자화된 768차원 벡터 1개는 0.8kb의 메모리(3/3.75)와 약 3.8kb의 디스크 공간(3 + 3/3.75)이 필요합니다. 이러한 hardware 옵션과 양자화에 따른 리소스 요구 사항을 고려하여 다양한 테스트 케이스에 대해 다음과 같은 검색 노드 티어를 선정했습니다.

테스트 케이스	필요 리소스 (RAM, 저장소)	Search Node Tier RAM, disk, vCPUs	2x 노드 가격
중간 크기 데이터셋(5.5M 벡터, 전체 차원), 스칼라 양자화	22, 104.5 GB	S50-스토리지 최적화 32GB, 843GB, 4 vCPUs	$1.04/hr
중간 크기 데이터셋(5.5M 벡터, 전체 차원), 스칼라 양자화	3.43, 104.5 GB	S30-하이 CPU 8GB 213GB 4 vCPU	$0.24/hr
대규모 데이터셋(15.3M 벡터, 2048차원), 스칼라 양자화	32.64, 155.04 GB	S50-스토리지 최적화 32GB, 843GB, 4 vCPUs	$1.04/hr
대규모 데이터셋(15.3M 벡터, 2048차원), 이진 양자화	5.1, 155.04 GB	S30-하이 CPU 8GB 213GB 4 vCPU	$0.24/hr

`binData` 벡터 압축

대규모 데이터 세트의 경우 소스 컬렉션의 각 벡터의 크기를 약 60% 줄여주는 벡터 압축이라는 추가 기능을 활용했습니다. 이 단계는 쿼리 내에서 ID가 소스 컬렉션에서 로드될 때 해당 단계를 가속화하며 이는 모든 대규모 워크로드에 권장되는 단계입니다.

동시성

10건 및 100건의 요청이 동시에 발생할 때 직렬 쿼리 지연 시간뿐 아니라 전체 처리량(QPS)도 평가했습니다.

참고

더 높은 처리량을 지원하는 권장 방법은 검색 노드의 수를 수평적으로 확장하는 것이며 본 테스트에서는 이 부분을 측정하지 않았습니다.

샤딩

대규모 바이너리 양자화 인덱스에서 10건 및 100건의 요청 동시성에 초점을 두고 클러스터와 컬렉션의 샤딩이 _id 필드 기준으로 시스템 처리량에 미치는 영향을 평가했습니다.

돌아가기

성능 벤치마크

벤치마크 결과

MongoDB Vector Search 벤치마크 개요

벤치마크 소개

참고

성능에 영향을 미치는 요인

양자화

스칼라 양자화

이진 양자화

벡터 차원 수

참고

데이터셋 보기

인덱스 사용됨

필터링

인덱스 사용됨

참고

검색 노드 구성

Amazon 데이터셋 크기 조정

binData 벡터 압축

동시성

참고

샤딩

`binData` 벡터 압축