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

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

요약: Elasticsearch는 최대 12배 더 빠릅니다 - Elastic에서는 커뮤니티로부터 시맨틱 검색/벡터 검색 영역에서 특히 Elasticsearch와 OpenSearch의 성능 차이를 명확히 해달라는 요청을 많이 받았습니다. 따라서 명확한 데이터 기반의 비교를 제공하기 위해 이 성능 테스트를 수행했으며, 그 취지는 모호함 없이 사용자에게 명확한 사실만을 전달한다는 데 있었습니다. 결과는 Elasticsearch가 벡터 검색에서 OpenSearch보다 최대 12배 더 빨라, 더 적은 컴퓨팅 리소스를 필요로 한다는 것을 보여줍니다. 이는 검색 및 조회용으로 Lucene을 최고의 벡터 데이터베이스로 통합하려는 Elastic의 노력을 반영합니다.

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

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

정확한 KNN과 근사 KNN

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

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

정확한 KNN은 무차별 대입 방식을 사용하여 하나의 벡터와 데이터 세트의 다른 모든 벡터 사이의 거리를 계산합니다. 그런 다음 이 거리의 순위를 매겨 $k$개의 최근접 이웃을 찾습니다. 이 방법은 정확한 일치를 보장하지만, 대규모의 고차원 데이터 세트에 대한 확장성 문제가 있습니다. 그러나 정확한 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배 정도 빠르다는 것을 관찰했습니다. 또한 동일한 $k$ 및 $n$ 조건에서, 인덱싱 없이 수행할 경우 2~3배 더 빠르다는 결과가 나왔습니다. $k$:100 및 $n$:1000(standalone-search-knn-100-1000-single-client 및 standalone-search-knn-100-1000-multiple-clients)에서 Elasticsearch는 평균적으로 OpenSearch보다 2~7배 더 빠릅니다.

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

리콜

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).

리콜

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).

리콜

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는 차세대 검색 혁신을 이끌 준비가 되어 있습니다.