Elasticsearch BBQ와 OpenSearch FAISS: 벡터 검색 성능 비교

벡터 검색부터 강력한 REST API까지, Elasticsearch는 개발자에게 가장 폭넓은 검색 도구 키트를 제공합니다. GitHub의 샘플 노트북을 살펴보고 새로운 기능을 시험해 보세요. 무료 체험판을 시작하거나 지금 바로 Elasticsearch를 로컬에서 실행할 수도 있습니다.

이진 양자화를 통한 벡터 검색: BBQ가 포함된 Elasticsearch는 FAISS가 포함된 OpenSearch보다 5배 빠릅니다. Elastic은 특히 시맨틱 검색/벡터 검색 영역에서 Elasticsearch와 OpenSearch 간의 성능 차이를 명확히 해달라는 커뮤니티의 요청을 받았기 때문에 명확한 데이터 기반 비교를 제공하기 위해 이러한 성능 테스트를 수행했습니다.

이진 양자화 대결

고차원 벡터를 원래 형태로 저장하는 것은 메모리 집약적일 수 있습니다. 양자화 기술은 이러한 벡터를 콤팩트한 표현으로 압축하여 메모리 사용량을 대폭 줄여줍니다. 그러면 검색이 압축된 공간에서 작동하므로 계산 복잡성이 줄어들고 특히 대규모 데이터 세트에서 검색 속도가 빨라집니다.

Elastic은 Lucene을 최고 성능의 벡터 엔진으로 만들기 위해 최선을 다하고 있습니다. 우리는 Lucene을 기반으로 Elasticsearch 8.16에서 더 나은 이진 정량화 (BBQ)를 도입했고 8.18과 9.0에서 이를 더욱 발전시켰습니다. BBQ는 플로트32 차원을 비트로 축소하는 새로운 스칼라 양자화 방식을 기반으로 구축되어 높은 순위 품질을 유지하면서 최대 95%의% 메모리 절감 효과를 제공합니다.

반면 OpenSearch는 여러 벡터 엔진, 즉 nmslib(현재는 더 이상 사용되지 않음), Lucene 및 FAISS를 사용합니다. 이전 블로그에서 벡터 검색을 위해 Elasticsearch와 OpenSearch를 비교한 적이 있습니다. 세 가지 데이터 세트를 사용하여 두 제품에서 서로 다른 엔진 및 구성 조합을 테스트했습니다.

이 블로그에서는 현재 두 제품에서 사용할 수 있는 이진 양자화 알고리즘에 초점을 맞춥니다. openai_vector Rally 트랙을 사용하여 BBQ와 함께 Elasticsearch를 테스트하고 FAISS의 이진 정량화를 통해 OpenSearch를 테스트했습니다.

주요 목표는 동일한 리콜 수준에서 두 솔루션의 성능을 평가하는 것이었습니다. 리콜이란 무엇을 의미하나요? 리콜은 검색 시스템에서 얼마나 많은 관련 결과를 성공적으로 검색했는지를 측정하는 지표입니다.

이 평가에서는 recall@k가 특히 중요한데, 여기서 k는 고려되는 상위 결과의 수를 나타냅니다. 따라서 리콜@10, 리콜@50 및 리콜@100은 각각 검색된 상위 10개, 50개 및 100개의 항목에서 얼마나 많은 실제 관련성 있는 결과가 나타나는지 측정합니다. 리콜은 0에서 1(또는 0% ~ 100% 정밀도)의 척도로 표시됩니다. 이는 리콜이 항상 1(100%)인 정확한 KNN이 아닌 근사 KNN(ANN)에 대해 이야기하고 있기 때문에 중요합니다.

k의 각 값에 대해 최종 순위를 적용하기 전에 고려되는 후보의 수인 n도 지정했습니다. 즉, Recall@10, Recall@50 및 Recall@100의 경우 시스템은 먼저 이진 양자화 알고리즘을 사용하여 n개의 후보를 검색한 다음 상위 k개의 결과에 예상되는 관련 항목이 포함되어 있는지 여부를 판단하기 위해 순위를 매깁니다.

n을 제어함으로써 효율성과 정확성 사이의 균형을 분석할 수 있습니다. 일반적으로 n이 높을수록 순위를 매길 수 있는 후보가 많아져 리콜률이 높아지지만 지연 시간이 길어지고 처리량도 감소합니다 . 반대로 n이 낮을수록 검색 속도가 빨라지지만 초기 세트에 관련 후보가 너무 적게 포함될 경우 검색 회수율이 떨어질 수 있습니다.

이 비교에서 Elasticsearch는 동일한 설정에서 OpenSearch보다 더 낮은 지연 시간과 더 높은 처리량을 보여주었습니다.

방법론

전체 구성과 함께 Terraform 스크립트, Kubernetes 매니페스트 및 특정 Rally 트랙은 이 리포지토리에서 openai_vector_bq 아래에서 확인할 수 있습니다.

이전 벤치마크와 마찬가지로 다음과 같이 구성된 Kubernetes 클러스터를 사용했습니다:

• 3개의 e2-standard-32 시스템(128GB RAM 및 32 CPU)을 갖춘 Elasticsearch 9.0용 노드 풀 1개
• OpenSearch 2.19용 노드 풀 1개, e2-standard-32 머신 3대(128GB RAM 및 32개 CPU)
• 2개의 e2-standard-4 머신(16GB RAM 및 4개의 CPU)이 있는 Rally용 노드 풀 1개

하나의 Elasticsearch 클러스터 버전 9.0과 하나의 OpenSearch 클러스터 버전 2.19를 설정했습니다.

Elasticsearch와 OpenSearch 모두 정확히 동일한 설정으로 테스트했습니다. OpenAI의 텍스트 임베딩-ada-002 모델을 사용해 생성된 임베딩으로 강화된 NQ 데이터 세트의 250만 개의 문서를 사용하는 openai_vector Rally 트랙을 일부 수정하여 사용했습니다.

검색 작업을 수행하기 위해 8개의 동시 클라이언트를 사용하여 다양한 리콜 수준(리콜@10, 리콜@50, 리콜@100)에서 측정된 지연 시간 및 처리량에 대한 결과 보고서입니다. 복제본 없이 단일 샤드를 사용했습니다.

다음과 같은 k-n-점수 조합을 실행했습니다. 10-2000-2000 또는 k:10, n:2000 및 rescore:2000 은 2000개의 결과에 대해 재점수('과대 표본 계수' 1에 해당)를 적용하여 n개의 후보(2000개) 중 상위 k(10개)를 검색합니다. 각 검색은 워밍업으로 1000회의 검색으로 10.000회 실행되었습니다:

Recall@10

• 10-40-40
• 10-50-50
• 10-100-100
• 10-200-200
• 10-500-500
• 10-750-750
• 10-1000-1000
• 10-1500-1500
• 10-2000-2000

Recall@50

• 50-150-150
• 50-200-200
• 50-250-250
• 50-500-500
• 50-750-750
• 50-1000-1000
• 50-1200-1200
• 50-1500-1500
• 50-2000-2000

Recall@100

• 100-200-200
• 100-250-250
• 100-300-300
• 100-500-500
• 100-750-750
• 100-1000-1000
• 100-1200-1200
• 100-1500-1500
• 100-2000-2000

벤치마크를 복제하기 위해, rally-elasticsearch와 rally-opensearch 모두에 대한 Kubernetes 매니페스트에는 모든 관련 변수가 컨피그맵에 외부화되어 있으며, 여기 (ES)와 여기 (OS)에서 확인할 수 있습니다. search_ops 매개변수는 k, n, rescore의 모든 조합을 테스트하도록 사용자 지정할 수 있습니다.

OpenSearch Rally 구성

/k8s/rally-openai_vector-os-bq.yml

검색 인덱스 구성

그런 다음 컨피그맵의 변수가 인덱스 구성에 사용되며, 일부 매개변수는 변경되지 않은 상태로 유지됩니다. OpenSearch의 1비트 양자화는 압축 수준을 "32배"로 설정하여 구성합니다.

index-vectors-only-mapping-with-docid-mapping.json

Elasticsearch Rally 구성

/k8s/rally-openai_vector-es-bq.yml

Elasticsearch 인덱스 구성

index-vectors-only-mapping-with-docid-mapping.json

결과

결과를 해석하는 방법에는 여러 가지가 있습니다. 지연 시간과 처리량 모두에 대해 각 리콜 수준에 따라 단순화된 차트와 상세한 차트를 표시했습니다. 각 지표에 대해 "높을수록 좋다"고 생각하면 차이를 쉽게 알 수 있습니다. 그러나 지연 시간은 음수(낮을수록 좋음)인 반면 처리량은 양수입니다. 단순화된 차트에서는 (리콜/레이턴시) * 10000 (간단히 '속도'라고 함)과 리콜 * 처리량을 사용했으므로 두 지표 모두 속도가 빠르고 처리량이 많을수록 더 좋다는 의미입니다. 시작해 보겠습니다.

리콜 @ 10 - 단순화

이 수준의 리콜에서 Elasticsearch BBQ는 OpenSearch FAISS보다 최대 5배 (평균 3.9배) 빠르며 평균 3.2배 더 많은 처리량을 제공합니다.

리콜 @ 10 - 상세

리콜 @ 50 - 단순화

이 수준의 리콜에서 Elasticsearch BBQ는 OpenSearch FAISS보다 최대 5배 (평균 4.2배) 빠르며 평균 처리량이 3.9배( ) 더 많습니다.

상세 결과 - 리콜 @ 50%

리콜 @ 100

이 수준의 리콜에서 Elasticsearch BBQ는 OpenSearch FAISS보다 최대 5배 (평균 4.6배) 빠르며 평균 3.9배 더 많은 처리량을 제공합니다.

상세 결과 - 리콜 @ 100

BBQ 개선 사항

BBQ는 첫 출시 이후 많은 발전을 거듭해 왔습니다. 비교를 위해 8.16 버전에서 현재 버전과 함께 실행한 벤치마크를 포함시켰는데, 그 이후 리콜과 지연 시간이 어떻게 개선되었는지 확인할 수 있습니다.

Elasticsearch 8.18과 9.0에서는 벡터를 정량화하기 위한 핵심 알고리즘을 다시 작성했습니다. 따라서 8.16의 BBQ도 좋았지만 최신 버전은 훨씬 더 좋습니다. 자세한 내용은 여기와 여기에서 확인할 수 있습니다. 즉, 모든 벡터는 최적화된 스칼라 사분위수를 통해 개별적으로 정량화됩니다. 그 결과, 사용자는 성능 저하 없이 벡터 검색의 정확도가 높아져 Elasticsearch의 벡터 검색이 더욱 강력해지는 이점을 누릴 수 있습니다.

결론

이 Elasticsearch BBQ와 OpenSearch FAISS 간의 성능 비교에서 Elasticsearch는 벡터 검색에서 OpenSearch보다 훨씬 뛰어난 성능을 발휘하여 다양한 수준의 리콜에서 평균적으로 최대 5배 빠른 쿼리 속도와 3.9배 높은 처리량을 달성했습니다.

주요 결과는 다음과 같습니다:

• Recall@10: Elasticsearch BBQ는 OpenSearch FAISS에 비해 최대 5배(평균 3.9배) 빠르며 평균 3.2배 더 많은 처리량을 제공합니다.
• Recall@50: Elasticsearch BBQ는 OpenSearch FAISS에 비해 최대 5배(평균 4.2배) 빠르며 평균 3.9배 더 많은 처리량을 제공합니다.
• Recall@100: Elasticsearch BBQ는 OpenSearch FAISS에 비해 최대 5배(평균 4.6배) 빠르며 평균 3.9배 더 많은 처리량을 제공합니다.

이러한 결과는 특히 고차원 벡터 검색 시나리오에서 Elasticsearch BBQ의 효율성과 성능 이점을 강조합니다. Elasticsearch 8.16에 도입된 더 나은 이진 양자화(BBQ) 기술은 높은 순위 품질을 유지하면서 상당한 메모리 절감(~95%)을 제공하므로 대규모 벡터 검색 애플리케이션에 탁월한 선택이 될 수 있습니다.

Elastic에서는 RAG(검색 증강 생성)를 비롯한 검색 및 검색 사용 사례를 위한 최고의 벡터 데이터베이스를 제공하기 위해 Apache Lucene과 Elasticsearch를 개선하기 위해 끊임없이 혁신하고 있습니다. 최근의 발전으로 성능이 크게 향상되어 이전보다 벡터 검색 속도가 빨라지고 공간 효율성이 높아졌으며, 이는 루씬 10에서 얻은 이점을 기반으로 합니다. 이 블로그는 이러한 혁신의 또 다른 예시입니다.