이진 양자화 대결

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

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 - 상세

작업

latency.mean

throughput.mean

avg_recall

Elasticsearch-9.0-BBQ

10-100-100

11.70

513.58

0.89

Elasticsearch-9.0-BBQ

10-1000-100

27.33

250.55

0.95

Elasticsearch-9.0-BBQ

10-1500-1500

35.93

197.26

0.95

Elasticsearch-9.0-BBQ

10-200-200

13.33

456.16

0.92

Elasticsearch-9.0-BBQ

10-2000-2000

44.27

161.40

0.95

Elasticsearch-9.0-BBQ

10-40-40

10.97

539.94

0.84

Elasticsearch-9.0-BBQ

10-50-50

11.00

535.73

0.85

Elasticsearch-9.0-BBQ

10-500-500

19.52

341.45

0.93

Elasticsearch-9.0-BBQ

10-750-750

22.94

295.19

0.94

OpenSearch-2.19-faiss

10-100-100

35.59

200.61

0.94

OpenSearch-2.19-faiss

10-1000-1000

156.81

58.30

0.96

OpenSearch-2.19-faiss

10-1500-1500

181.79

42.97

0.96

OpenSearch-2.19-faiss

10-200-200

47.91

155.16

0.95

OpenSearch-2.19-faiss

10-2000-2000

232.14

31.84

0.96

OpenSearch-2.19-faiss

10-40-40

27.55

249.25

0.92

OpenSearch-2.19-faiss

10-50-50

28.78

245.14

0.92

OpenSearch-2.19-faiss

10-500-500

79.44

97.06

0.96

OpenSearch-2.19-faiss

10-750-750

104.19

75.49

0.96

리콜 @ 50 - 단순화

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

상세 결과 - 리콜 @ 50%

작업

지연 시간 평균

처리량 평균

평균 회수율

Elasticsearch-9.0-BBQ

50-1000-1000

25.71

246.44

0.95

Elasticsearch-9.0-BBQ

50-1200-1200

28.81

227.85

0.95

Elasticsearch-9.0-BBQ

50-150-150

13.43

362.90

0.90

Elasticsearch-9.0-BBQ

50-1500-1500

33.38

202.37

0.95

Elasticsearch-9.0-BBQ

50-200-200

12.99

406.30

0.91

Elasticsearch-9.0-BBQ

50-2000-2000

42.63

163.68

0.95

Elasticsearch-9.0-BBQ

50-250-250

14.41

373.21

0.92

Elasticsearch-9.0-BBQ

50-500-500

17.15

341.04

0.93

Elasticsearch-9.0-BBQ

50-750-750

31.25

248.60

0.94

OpenSearch-2.19-faiss

50-1000-1000

125.35

62.53

0.96

OpenSearch-2.19-faiss

50-1200-1200

143.87

54.75

0.96

OpenSearch-2.19-faiss

50-150-150

43.64

130.01

0.89

OpenSearch-2.19-faiss

50-1500-1500

169.45

46.35

0.96

OpenSearch-2.19-faiss

50-200-200

48.05

156.07

0.91

OpenSearch-2.19-faiss

50-2000-2000

216.73

36.38

0.96

OpenSearch-2.19-faiss

50-250-250

53.52

142.44

0.93

OpenSearch-2.19-faiss

50-500-500

78.98

97.82

0.95

OpenSearch-2.19-faiss

50-750-750

103.20

75.86

0.96

리콜 @ 100

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

상세 결과 - 리콜 @ 100

작업

latency.mean

throughput.mean

avg_recall

Elasticsearch-9.0-BBQ

100-1000-1000

27.82

243.22

0.95

Elasticsearch-9.0-BBQ

100-1200-1200

31.14

224.04

0.95

Elasticsearch-9.0-BBQ

100-1500-1500

35.98

193.99

0.95

Elasticsearch-9.0-BBQ

100-200-200

14.18

403.86

0.88

Elasticsearch-9.0-BBQ

100-2000-2000

45.36

159.88

0.95

Elasticsearch-9.0-BBQ

100-250-250

14.77

433.06

0.90

Elasticsearch-9.0-BBQ

100-300-300

14.61

375.54

0.91

Elasticsearch-9.0-BBQ

100-500-500

18.88

340.37

0.93

Elasticsearch-9.0-BBQ

100-750-750

23.59

285.79

0.94

OpenSearch-2.19-faiss

100-1000-1000

142.90

58.48

0.95

OpenSearch-2.19-faiss

100-1200-1200

153.03

51.04

0.95

OpenSearch-2.19-faiss

100-1500-1500

181.79

43.20

0.96

OpenSearch-2.19-faiss

100-200-200

50.94

131.62

0.83

OpenSearch-2.19-faiss

100-2000-2000

232.53

33.67

0.96

OpenSearch-2.19-faiss

100-250-250

57.08

131.23

0.87

OpenSearch-2.19-faiss

100-300-300

62.76

120.10

0.89

OpenSearch-2.19-faiss

100-500-500

84.36

91.54

0.93

OpenSearch-2.19-faiss

100-750-750

111.33

69.95

0.94

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에서 얻은 이점을 기반으로 합니다. 이 블로그는 이러한 혁신의 또 다른 예시입니다.

벡터 검색은 특히 AI, 머신 러닝 같은 분야에서 유사성 검색을 수행하는 방식을 혁신하고 있습니다. 벡터 임베딩 모델의 채택이 증가함에 따라 수백만 개의 고차원 벡터를 효율적으로 검색하는 능력이 중요해지고 있습니다.

벡터 데이터베이스를 지원하는 데 있어 Elastic과 OpenSearch는 눈에 띄게 다른 접근 방식을 취해 왔습니다. Elastic은 Elasticsearch와 함께 Apache Lucene을 최적화하는 데 막대한 투자를 진행했으며, 이를 통해 벡터 검색 애플리케이션 분야에서 업계 최고 수준의 옵션으로 자리매김했습니다. 이에 비해 OpenSearch는 Lucene의 범위를 넘어 다른 벡터 검색 구현을 통합하며 그 중점 분야를 확장했습니다. Elastic은 전략적으로 Lucene에 집중하여, Elasticsearch 버전에서 고도로 통합된 지원을 제공해 각 구성 요소가 서로의 기능을 보완하고 강화하는 향상된 기능 세트를 제공할 수 있게 되었습니다.

이 블로그에서는 다양한 구성과 벡터 엔진에 대해 Elasticsearch 8.14와 OpenSearch 2.14를 자세히 비교하고 있습니다. 이 성능 분석에서 Elasticsearch는 벡터 검색 작업에서 우수한 플랫폼임이 입증되었으며, 앞으로 출시될 기능들은 이러한 차이를 더욱 크게 확대할 것입니다. OpenSearch와 비교했을 때 모든 벤치마크 트랙에서 뛰어난 성능을 보였으며, 평균적으로 2~12배 더 빠른 성능을 제공했습니다. 이는 so_vector (2M 벡터, 768D), openai_vector (2.5M 벡터, 1536D), dense_vector (10M 벡터, 96D)를 포함한 다양한 벡터 수와 차원을 사용하는 시나리오에서 진행되었으며, 모든 항목은 Google 클라우드에서 필요한 인프라를 프로비저닝하기 위한 Terraform 스크립트와 테스트 실행용 Kubernetes 매니페스트와 함께 이 리포지토리에서 확인할 수 있습니다.

이 블로그에 자세히 설명된 결과는 이전에 발표되고 제3자가 검증한 연구 결과를 보완합니다. 해당 연구에서는 Elasticsearch가 가장 일반적인 검색 분석 작업(텍스트 쿼리, 정렬, 범위, 날짜 히스토그램, 용어 필터링)에서 OpenSearch보다 40%–140% 더 빠르다는 것을 보여줍니다. 이제 또 다른 차별화 요소인 벡터 검색을 추가할 수 있습니다.

기본 설정으로 최대 12배 더 빠른 성능

4개의 벡터 데이터 세트에 대한 집중 벤치마크에는 근사 KNN 및 정확한 KNN 검색이 모두 포함되었습니다. 다양한 크기, 차원, 구성을 고려하여 총 40.189.820 개의 캐시되지 않은 검색 요청에 대해 수행했습니다. 결과: Elasticsearch가 벡터 검색에서 OpenSearch보다 최대 12배 더 빨라, 더 적은 컴퓨팅 리소스를 필요로 한다는 것을 보여줍니다.

그림 1: Elasticsearch와 OpenSearch의 다양한 조합에서 수행된 ANN 및 정확한 KNN 작업 그룹.

knn-10-100 같은 그룹은 및 설정의 KNN 검색을 의미합니다. HNSW 벡터 검색에서 는 쿼리 벡터에 대해 검색할 최근접 이웃의 수를 결정합니다. 결과적으로 얼마나 많은 유사한 벡터를 찾을지 지정합니다. 은 각 세그먼트에서 검색할 후보 벡터의 수를 설정합니다. 후보자가 많을수록 정확도가 향상되지만 더 많은 계산 리소스가 필요합니다.

또한 다양한 양자화 기법과 엔진별 최적화를 활용하여 테스트했으며, 각 트랙, 작업, 벡터 엔진에 대한 자세한 결과는 아래에서 확인할 수 있습니다.

정확한 KNN과 근사 KNN

다양한 데이터 세트와 사용 사례를 다룰 때, 벡터 검색에 적합한 접근 방식은 달라집니다. 이 블로그에서 knn-* 로 표시된 모든 작업은 knn-10-100 처럼 근사 KNN을 사용하고, script-score-* 는 정확한 KNN을 참조합니다. 그렇다면 이 둘의 차이점은 무엇이며, 왜 중요할까요?

본질적으로 더 큰 데이터 세트를 처리할 때는, 확장성이 뛰어난 근사 K-최근접 이웃(ANN) 방법이 선호됩니다. 필터링 프로세스가 필요한 상대적으로 작은 데이터 세트의 경우, 정확한 KNN 방법이 이상적입니다.

정확한 KNN은 무차별 대입 방식을 사용하여 하나의 벡터와 데이터 세트의 다른 모든 벡터 사이의 거리를 계산합니다. 그런 다음 이 거리의 순위를 매겨 개의 최근접 이웃을 찾습니다. 이 방법은 정확한 일치를 보장하지만, 대규모의 고차원 데이터 세트에 대한 확장성 문제가 있습니다. 그러나 정확한 KNN이 필요한 경우가 많이 있습니다.

• 리스코어링: 어휘 또는 시맨틱 검색 후 벡터 기반 리스코어링을 포함하는 시나리오에서는 정확한 KNN이 필수적입니다. 예를 들어, 제품 검색 엔진에서 초기 검색 결과는 텍스트 쿼리(예: 키워드, 카테고리)를 기반으로 필터링할 수 있으며, 필터링된 항목과 연관된 벡터를 사용하여 보다 정확한 유사성 평가를 수행할 수 있습니다.

• 개인화: 많은 사용자가 각각 비교적 적은 수(예: 1백만)의 고유 벡터로 표현될 때, 사용자별 메타데이터(예: user_id)로 색인을 정렬하고 벡터를 이용한 무차별 대입 스코어링이 효율적입니다. 이 접근 방식을 사용하면 개별 사용자 선호도에 맞춘 정확한 벡터 비교를 기반으로, 개인화된 추천이나 콘텐츠 제공이 가능합니다.

따라서 정확한 KNN은 벡터 유사도에 기반한 최종 순위와 추천이 정확하며 사용자 선호도에 맞게 조정됩니다.

반면에 근사 KNN(ANN)은 대규모 고차원 데이터 세트에서 정확한 KNN보다 데이터를 더 빠르고 효율적으로 검색할 수 있는 방법을 사용합니다. 쿼리와 모든 지점 사이의 가장 가까운 정확한 거리를 측정하여 계산 및 확장 문제로 이어지는 무차별 대입 방식 대신, ANN은 특정 기술을 사용해 데이터 세트에서 검색 가능한 벡터의 인덱스와 차원을 효율적으로 재구성합니다. 이로 인해 약간의 부정확성이 발생할 수 있지만, 검색 프로세스의 속도가 크게 향상되어 대규모 데이터 세트를 처리하는 데 효과적인 대안이 됩니다.

이 블로그에서는 knn-* 로 표시된 모든 작업은 knn-10-100 과 같이 근사 KNN을 사용하고, script-score-* 는 정확한 KNN을 참조합니다.

테스트 방법론

Elasticsearch와 OpenSearch는 BM25 검색 작업을 위한 API 측면에서 비슷하지만, 후자가 전자의 포크이기 때문에 포크 이후에 도입된 벡터 검색에는 해당되지 않습니다. OpenSearch는 알고리즘에 있어서 Elasticsearch와는 다른 접근 방식을 취했습니다. lucene 외에도, 각각 고유한 구성과 제한 사항을 가진 2개의 다른 엔진인 nmslib 및 faiss 를 도입했습니다. 예를 들어, OpenSearch의 nmslib 은 많은 사용 사례에서 필수적인 기능인 필터를 허용하지 않습니다.

3개 엔진 모두 계층적으로 탐색 가능한 작은 세계(Hierarchical Navigable Small World, HNSW) 알고리즘을 사용합니다. HNSW 알고리즘은 근사 최근접 이웃을 검색하는 데 효율적이며 고차원 데이터를 처리할 때 특히 강력합니다. faiss는 두 번째 알고리즘인 ivf도 지원하지만, 데이터 세트에 대한 사전 학습이 필요하기 때문에, 여기서는 HNSW에만 집중하려고 합니다. HNSW의 핵심 아이디어는 데이터를 여러 계층의 연결된 그래프로 구성하는 것이며, 각 계층은 데이터 세트의 다양한 세분성을 나타냅니다. 검색은 가장 거친 보기를 제공하는 최상위 레이어에서 시작하여 기본 수준에 도달할 때까지 점점 더 세밀한 레이어로 진행됩니다.

두 검색 엔진은 모두 공정한 테스트 근거를 확보하기 위해 통제된 환경에서 동일한 조건으로 테스트되었습니다. 적용된 방법은 Elasticsearch, OpenSearch, Rally에 대한 전용 Node 풀을 사용하여 이전에 게시된 성능 비교와 유사합니다. terraform 스크립트는 (모든 소스와 함께) Kubernetes 클러스터를 프로비저닝하는 데 사용할 수 있습니다.

• 3개의 e2-standard-32 머신(128GB RAM 및 32개의 CPU)이 있는 Elasticsearch용 Node 풀 1개

• 3개의 e2-standard-32 머신(128GB RAM 및 32개의 CPU)이 있는 OpenSearch용 Node 풀 1개

• 2개의 t2a-standard-16 머신(64GB RAM 및 16개의 CPU)이 있는 Rally용 Node 풀 1개

각 '트랙'(또는 테스트)은 서로 다른 엔진, 서로 다른 구성, 서로 다른 벡터 유형을 포함하는 각 구성에 대해 10회씩 실행되었습니다. 트랙에는 트랙에 따라 1,000번에서 10,000번 반복되는 작업이 있습니다. 예를 들어 네트워크 시간 초과로 인해 트랙의 작업 중 하나가 실패하면, 모든 작업이 폐기되므로 모든 결과는 문제 없이 시작되고 완료된 트랙을 나타냅니다. 모든 테스트 결과는 통계적으로 검증되어, 개선이 우연이 아님을 보장합니다.

자세한 결과

왜 평균 지연 시간이 아닌 99번째 백분위수를 사용하여 비교해야 할까요? 한 예로 특정 지역의 평균 주택 가격을 들어 보겠습니다. 평균 가격은 비싼 지역을 나타낼 수 있지만, 자세히 살펴보면 대부분의 주택은 훨씬 낮은 가격에 거래되고 일부 고급 부동산만 평균 수치를 부풀리고 있는 것으로 드러날 수 있습니다. 이는 평균 가격이 해당 지역의 주택 가치 전체를 정확하게 나타내지 못할 수 있음을 보여줍니다. 이는 응답 시간를 조사하는 것과 유사하며, 평균값은 중요한 문제를 숨길 수 있습니다.

작업

• 근사 KNN(k:10 n:50)

• 근사 KNN(k:10 n:100)

• 근사 KNN(k:100 n:1000)

• 근사 KNN(k:10 n:50) 및 키워드 필터 적용

• 근사 KNN(k:10 n:100) 및 키워드 필터 적용

• 근사 KNN(k:100 n:1000) 및 키워드 필터 적용

• 근사 KNN(k:10 n:100) 및 인덱싱 병행

• 정확한 KNN(스크립트 점수)

벡터 엔진

• lucene Elasticsearch와 OpenSearch 모두, 버전 9.10에서

• faiss OpenSearch에서

• nmslib OpenSearch에서

벡터 유형

• hnsw Elasticsearch 및 OpenSearch에서

• int8_hnsw Elasticsearch에서(자동 8비트 양자화 적용 HNSW: 링크)

• sq_fp16 hnsw OpenSearch에서(자동 16비트 양자화 적용 HNSW: 링크)

기본 설정 상태에서 바로 사용 가능, 동시 세그먼트 검색 지원

아시다시피, Lucene은 Java로 작성된 고성능 텍스트 검색 엔진 라이브러리로 Elasticsearch, OpenSearch, Solr 등 많은 검색 플랫폼의 중추적인 역할을 합니다. 핵심적으로 Lucene은 데이터를 세그먼트로 구성하며, 세그먼트는 본질적으로 독립된 인덱스로서 Lucene이 검색을 보다 효율적으로 실행할 수 있게 해 줍니다. 따라서 Lucene 기반 검색 엔진에 검색을 요청하면, 해당 세그먼트에서 순차적으로 또는 병렬로 검색이 실행됩니다.

OpenSearch는 동시 세그먼트 검색을 선택적 플래그로 도입했지만 기본적으로 사용하지 않습니다. 여기에 자세히 설명된 대로 특수 인덱스 설정 index.search.concurrent_segment_search.enabled을 사용하여 활성화해야 하며, 몇 가지 제한 사항이 있습니다.

반면 Elasticsearch는 기본 설정으로 세그먼트를 동시에 검색합니다. 따라서 이 블로그에서 비교할 때 다양한 벡터 엔진과 벡터 유형뿐만 아니라 다양한 구성도 고려됩니다.

• Elasticsearch ootb: 기본 설정 상태에서 바로 사용 가능한 Elasticsearch, 동시 세그먼트 검색 지원;

• OpenSearch ootb: 동시 세그먼트 검색이 기본적으로 활성화되지 않은 상태;

• OpenSearch css: 동시 세그먼트 검색이 활성화된 상태

이제 테스트한 각 벡터 데이터 세트에 대한 자세한 결과를 살펴보겠습니다.

250만 개의 벡터, 1,536차원(openai_vector)

가장 간단하지만 차원 면에서 가장 큰 트랙인 openai_vector부터 시작합니다. 이 트랙은 OpenAI의 text-embedding-ada-002 모델을 사용하여 생성된 임베딩으로 강화된 NQ 데이터 세트를 사용합니다. 근사 KNN만 테스트하고 작업은 5개뿐이므로 가장 간단합니다. 인덱싱 없이 독립형으로, 인덱싱과 함께, 단일 클라이언트와 8개의 동시 클라이언트를 사용하여 테스트합니다.

작업

• standalone-search-knn-10-100-multiple-clients: 8개의 클라이언트로 250만 개의 벡터 동시에 검색(k: 10, n:100)

• standalone-search-knn-100-1000-multiple-clients: 8개의 클라이언트로 250만 개의 벡터 동시에 검색(k: 100, n:1000)

• standalone-search-knn-10-100-single-client: 단일 클라이언트로 250만 개의 벡터 검색(k: 10, n: 100)

• standalone-search-knn-100-1000-single-client: 단일 클라이언트로 250만 개의 벡터 검색(k: 100, n: 1000)

• parallel-documents-indexing-search-knn-10-100: 250만 개의 벡터 검색하는 동시에 추가로 100,000개의 문서를 색인(k:10, n:100).

평균 p99 성능은 다음과 같이 요약됩니다.

여기서 k:10 및 n:100 조건에서 인덱싱(예: 읽기+쓰기)과 함께 벡터 검색을 수행할 때 Elasticsearch가 OpenSearch보다 3~ 8배 정도 빠르다는 것을 관찰했습니다. 또한 동일한 및 조건에서, 인덱싱 없이 수행할 경우 2~3배 더 빠르다는 결과가 나왔습니다. :100 및 :1000(standalone-search-knn-100-1000-single-client 및 standalone-search-knn-100-1000-multiple-clients)에서 Elasticsearch는 평균적으로 OpenSearch보다 2~7배 더 빠릅니다.

자세한 결과에서는 정확한 사례와 벡터 엔진을 비교해 보여줍니다.

리콜

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969485

0.995138

Elasticsearch-8.14.0@lucene-int8_hnsw

0.781445

0.784817

OpenSearch-2.14.0@lucene-hnsw

0.96519

0.995422

OpenSearch-2.14.0@faiss

0.984154

0.98049

OpenSearch-2.14.0@faiss-sq_fp16

0.980012

0.97721

OpenSearch-2.14.0@nmslib

0.982532

0.99832

1,000만 개의 벡터, 96차원(dense_vector)

1천만 개의 벡터, 96차원으로 구성된 dense_vector에서. Yandex DEEP1B 이미지 데이터 세트를 기반으로 합니다. 데이터 세트는 learn.350M.fbin이라는 '샘플 데이터' 파일의 처음 1천만 개의 벡터로 생성됩니다. 검색 작업은 '쿼리 데이터' 파일 쿼리 public.10K.fbin의 벡터를 사용합니다.

Elasticsearch와 OpenSearch는 이 데이터 세트에서 매우 우수한 성능을 발휘합니다. 특히 일반적으로 읽기 전용 인덱스에서 수행되는 강제 병합 이후에는 더욱 그렇습니다. 이는 인덱스를 조각 모음하여 검색 대상으로 단일 '테이블'을 구성하는 것과 유사합니다.

작업

각 작업은 100개의 요청으로 워밍업한 후 1,000개의 요청을 측정합니다.

• knn-search-10-100: 1천만 개의 벡터 검색(k: 10, n: 100)

• knn-search-100-1000: 1천만 개의 벡터 검색(k: 100, n: 1000)

• knn-search-10-100-force-merge: 강제 병합 후 1천만 개의 벡터 검색(k: 10, n: 100)

• knn-search-100-1000-force-merge: 강제 병합 후 1천만 개의 벡터 검색(k: 100, n:1000)

• knn-search-100-1000-concurrent-with-indexing: 1천만 개의 벡터를 검색하면서 동시에 데이터 세트의 5% 업데이트(k: 100, n: 1000)

• script-score-query: 2천 개의 특정 벡터에 대한 정확한 KNN 검색.

Elasticsearch와 OpenSearch 모두 근접 KNN에서 우수한 성능을 보였습니다. knn-search-100-1000-force-merge와 knn-search-10-100-force-merge에서 인덱스가 병합되면(즉, 세그먼트가 하나만 있는 경우) nmslib 와 faiss를 사용할 때 모두 약 15ms로 매우 근접하지만 OpenSearch가 다른 엔진보다 성능이 더 좋습니다.

그러나 knn-search-10-100과 knn-search-100-1000에서 인덱스에 여러 세그먼트가 있는 경우(인덱스가 문서에 대한 업데이트를 받는 일반적인 상황) Elasticsearch는 대기 시간을 약 7ms와 16ms로 유지하는 반면, 다른 모든 OpenSearch 엔진은 더 느립니다.

또한 인덱스를 동시에 검색하고 작성하는 경우(knn-search-100-1000-concurrent-with-indexing) Elasticsearch는 지연 시간을 15ms(13.8ms) 미만으로 유지하여 OpenSearch(49.3ms)보다 거의 4배 빠르고, 동시 세그먼트 검색이 활성화된 경우에도 여전히 더 빠릅니다(17.9ms). 하지만 차이가 너무 작아 의미 있는 수준이라고 보기는 어렵습니다.

정확한 KNN의 경우 차이가 훨씬 큽니다. Elasticsearch는 OpenSearch보다 6배 더 빠릅니다(약 260ms vs. 1600ms).

리콜

knn-recall-10-100

knn-recall-100-1000

Elasticsearch-8.14.0@lucene-hnsw

0.969843

0.996577

Elasticsearch-8.14.0@lucene-int8_hnsw

0.775458

0.840254

OpenSearch-2.14.0@lucene-hnsw

0.971333

0.996747

OpenSearch-2.14.0@faiss

0.9704

0.914755

OpenSearch-2.14.0@faiss-sq_fp16

0.968025

0.913862

OpenSearch-2.14.0@nmslib

0.9674

0.910303

2백만 개의 벡터, 768차원(so_vector)

이 트랙 so_vector은 2022년 4월 21일에 다운로드한 StackOverflow 게시물 덤프에서 파생되었습니다. 질문 문서만 포함되어 있으며, 답변 문서는 모두 제거되었습니다. 각 질문 제목은 문장 변환기 모델 multi-qa-mpnet-base-cos-v1을 사용하여 벡터로 인코딩되었습니다. 이 데이터 세트에는 처음 2백만 개의 질문이 포함되어 있습니다.

이전 트랙과 달리, 각 문서에는 필터링 및 하이브리드 검색을 통한 근접 KNN과 같은 테스트 기능을 지원하기 위해 벡터 외에 다른 필드가 포함되어 있습니다. OpenSearch용nmslib 는 필터를 지원하지 않기 때문에 이 테스트에는 포함되지 않았습니다.

작업

각 작업은 100개의 요청으로 워밍업한 후, 100개의 요청을 측정합니다. 테스트에는 16개의 검색 유형 * 2개의 서로 다른 k 값 * 3개의 서로 다른 n 값이 포함되어 있으므로, 단순화를 위해 작업을 그룹화했습니다.

• knn-10-50: 필터 없이 2백만 개의 벡터 검색(k:10, n:50)

• knn-10-50-filtered: 필터를 적용하여 2백만 개의 벡터 검색(k:10, n:50)

• knn-10-50-after-force-merge: 강제 병합 후 필터를 적용하여 2백만 개의 벡터 검색(k:10, n:50)

• knn-10-100: 필터 없이 2백만 개의 벡터 검색(k:10, n:100)

• knn-10-100-filtered: 필터를 적용하여 2백만 개의 벡터 검색(k:10, n:100)

• knn-10-100-after-force-merge: 강제 병합 후 필터를 적용하여 2백만 개의 벡터 검색(k:10, n:100)

• knn-100-1000: 필터 없이 2백만 개의 벡터 검색(k:100, n:1000)

• knn-100-1000-filtered: 필터를 적용하여 2백만 개의 벡터 검색(k:100 , n:1000)

• knn-100-1000-after-force-merge: 강제 병합 후 필터를 적용하여 2백만 개의 벡터 검색(k:100, n:1000)

• exact-knn: 필터 적용 여부에 관계없이 정확한 KNN 검색.

Elasticsearch는 이 테스트에서 기본 설정 상태에서 OpenSearch보다 일관되게 빠릅니다. OpenSearch가 더 빠른 경우는 두 가지뿐이며, 그 차이도 크지 않습니다(knn-10-100 및 knn-100-1000). 필터와 함께 knn-10-50, knn-10-100, knn-100-1000 작업은 최대 7배(112ms vs 803ms)의 차이를 보입니다.

두 솔루션의 성능은 '강제 병합' 후에 균등해 지는 것으로 보이며, 이는 knn-10-50-after-force-merge, knn-10-100-after-force-merge, knn-100-1000-after-force-merge 에서 확인할 수 있습니다. 그러한 작업에서 faiss가 더 빠릅니다.

정확한 KNN의 성능은 다시 한 번 매우 다르게 나타났으며, 이번에는 Elasticsearch가 OpenSearch보다 13배 더 빨랐습니다(약 385ms vs 5262ms).

리콜

knn-recall-10-100

knn-recall-100-1000

knn-recall-10-50

Elasticsearch-8.14.0@lucene-hnsw

1

1

1

Elasticsearch-8.14.0@lucene-int8_hnsw

1

0.986667

1

OpenSearch-2.14.0@lucene-hnsw

1

1

1

OpenSearch-2.14.0@faiss

1

1

1

OpenSearch-2.14.0@faiss-sq_fp16

1

1

1

OpenSearch-2.14.0@nmslib

0.9674

0.910303

0.976394

Elasticsearch와 Lucene이 명백한 승자

Elastic에서는 RAG(Retrieval-Augmented Generation)를 비롯한 검색 및 조회 사용 사례를 위한 최고의 벡터 데이터베이스를 제공할 수 있도록 Apache Lucene과 Elasticsearch를 끊임없이 혁신하고 있습니다. 최근의 발전으로 성능이 획기적으로 향상되어 벡터 검색이 이전보다 더 빠르고 공간 효율적이 되었으며, 이는 Lucene 9.10에서 얻은 이점을 기반으로 합니다. 이 블로그는 최신 버전을 비교한 결과 Elasticsearch가 OpenSearch보다 최대 12배 빠르다는 연구를 소개합니다.

두 제품 모두 동일한 버전의 Lucene(Elasticsearch 8.14 릴리즈 노트 및 OpenSearch 2.14 릴리즈 노트)을 사용한다는 점은 주목할 만합니다.

Elastic의 빠른 혁신은 온프레미스 및 Elastic Cloud 고객뿐만 아니라 당사의 무상태(stateless) 플랫폼을 사용하는 고객에게도 더 많은 혜택을 가져다 줄 것입니다. int4에 대한 스칼라 양자화 지원과 같은 기능은 int8 테스트와 마찬가지로, 엄격한 테스트를 통해 고객이 재현율 저하 없이 이러한 기술을 활용할 수 있도록 보장할 것입니다.

AI 및 머신 러닝 애플리케이션의 확산으로 인해 최신 검색 엔진에서 벡터 검색 효율성은 타협할 수 없는 기능이 되고 있습니다. 대용량·고복잡 벡터 데이터의 요구를 충족할 수 있는 강력한 검색 엔진을 찾고 있는 조직에게는 Elasticsearch가 확실한 해답입니다.

기존 플랫폼을 확장하든 새로운 프로젝트를 시작하든, 벡터 검색 요구 사항을 위해 Elasticsearch를 통합하는 것은 가시적이고 장기적인 이점을 얻을 수 있는 전략적 움직임입니다. 입증된 성능 우위를 바탕으로 Elasticsearch는 차세대 검색 혁신을 이끌 준비가 되어 있습니다.