벡터 검색 성능 개선하기

벡터 크기 줄이기

Atlas Vector Search는 최대 4096 까지 벡터 차원을 지원합니다. 그러나 벡터가 클수록 더 많은 부동 소수점 비교가 필요하므로 벡터 Atlas Search 인덱싱 및 쿼리는 계산 집약적입니다. 따라서 가능하면 임베딩 모델 변경이 벡터 쿼리의 정확도에 미치는 영향을 측정할 수 있는지 확인한 후 차원 수를 줄이는 것이 좋습니다.

쿼리 실행 시 벡터 인덱싱 피하기

벡터 임베딩은 인덱싱 중에 컴퓨팅 리소스를 소비합니다. 벡터 검색 중에는 인덱싱 및 재인덱싱을 피하는 것이 좋습니다. 인덱싱할 벡터를 생성하는 임베딩 모델을 변경하려는 경우 현재 사용 중인 인덱스를 업데이트하는 대신 새 벡터를 새 인덱스로 다시 인덱싱하는 것이 좋습니다.

데이터 사전 필터링

벡터가 더 많거나 차원이 더 높은 벡터가 있는 경우 시맨틱 검색 의 범위를 좁히고 모든 벡터가 비교 대상으로 고려되지 않도록 할 수 있습니다.filter $vectorSearch 벡터 검색 을 수행할 문서 수를 줄이기 위해 사전 필터링을 수행하는 파이프라인 내에 옵션을 포함하는 것이 좋습니다. 또한 배열이 크면 쿼리 성능이 저하될 수 있으므로 고차원 벡터가 성능에 영향 도 고려하세요.

전용 검색 노드 사용

mongod 및 mongot 프로세스를 동일한 노드 에 배포 하는 경우 프로세스 간에 mongot 리소스 경합이 발생할 수 있습니다. Atlas Vector Search 쿼리의 성능을 최적화하려면 프로세스 를 전용 검색 노드에 배포 하는 것이 좋습니다. 이렇게 하면 mongot 프로세스와 프로세스 간의 리소스 경합을 방지하는 데 mongod 도움이 될 뿐만 아니라 검색 노드의 쿼리에 $vectorSearch 대해 기본값 병렬 세그먼트 검색 을 사용할 수 있습니다.

결과에서 벡터 필드 제외

결과 내 문서의 기존 필드와 $project 단계에서 새로 계산된 필드가 반환되도록 요청할 수 있습니다. 쿼리 성능을 향상시키려면 결과에 모든 필드가 필요한 경우를 제외하고 $project 단계를 사용하여 결과에 반환할 필드를 현명하게 선택합니다. 벡터 임베딩이 크고 결과 반환 시 쿼리 지연 시간에 영향을 줄 수 있으므로 $project 단계에서 벡터 필드를 제외하는 것이 좋습니다.

충분한 메모리 확보

Hierarchical Navigable Small Worlds 는 벡터 데이터가 메모리에 저장되어 있을 때 효율적으로 작동합니다. 데이터 노드에 벡터 데이터와 인덱스를 저장할 수 있는 충분한 RAM 이 있는지 확인해야 합니다. 벡터 검색 사용 사례에서 메모리를 보다 효율적으로 사용할 수 있도록 데이터 격리 없이 워크로드 격리 를 위해 별도의 검색 노드를 배포하는 것이 좋습니다.

파일 시스템 캐시 워밍업

벡터 검색을 수행하는 경우 쿼리는 계층적 탐색 가능 소규모 세계를 탐색하면서 디스크에서 무작위 검색을 수행하고 그래프와 벡터 값이 메모리로 읽혀집니다. 이로 인해 초기 쿼리의 지연 시간 이 매우 길어집니다. 계층적 탐색 가능 소규모 세계 탐색을 통해 인덱싱된 모든 벡터를 메모리로 읽어들일 때 지연 시간이 단축되어 후속 쿼리에서 벡터에 훨씬 빠르게 액세스할 수 있습니다.

하지만 대규모 쓰기 작업이나 인덱스를 다시 작성할 때는 이 캐시 워밍 프로세스를 반복해야 합니다.