Home
Blog
Reddit에서 ANN 검색을 위한 벡터 데이터베이스 선택하기

Reddit에서 ANN 검색을 위한 벡터 데이터베이스 선택하기

Engineering

November 28, 2025

Chris Fournie

이 게시물은 Reddit의 스태프 소프트웨어 엔지니어인 크리스 푸니가 작성한 것으로, 원래 Reddit에게시되었으며 허가를 받아 여기에 다시 게시되었습니다.

2024년에 Reddit 팀은 다양한 솔루션을 사용하여 근사 이웃(ANN) 벡터 검색을 수행했습니다. Google의 Vertex AI 벡터 검색과 일부 대규모 데이터 세트에 Apache Solr의 ANN 벡터 검색을 사용하는 실험부터 소규모 데이터 세트(수직으로 확장된 사이드카에서 호스팅)를 위한 Facebook의 FAISS 라이브러리까지. 점점 더 많은 Reddit 팀이 비용 효율적이고, 원하는 검색 기능을 갖추고 있으며, Reddit 크기의 데이터로 확장할 수 있는 광범위하게 지원되는 ANN 벡터 검색 솔루션을 원했습니다. 이러한 요구를 해결하기 위해, 2025년에 저희는 Reddit 팀에 가장 이상적인 벡터 데이터베이스를 찾았습니다.

이 포스팅에서는 현재 Reddit의 필요에 가장 적합한 벡터 데이터베이스를 선정하기 위해 사용한 프로세스에 대해 설명합니다. 모든 상황에 가장 적합한 벡터 데이터베이스나 가장 필수적인 기능적, 비기능적 요구사항에 대해 설명하지는 않습니다. 이 글은 Reddit과 엔지니어링 문화가 벡터 데이터베이스를 선택할 때 중요하게 여기고 우선순위를 두었던 사항을 설명합니다. 이 게시물은 자체 요구 사항 수집 및 평가에 영감을 줄 수 있지만 각 조직마다 고유한 문화, 가치 및 요구 사항이 있습니다.

평가 프로세스

전반적인 선정 단계는 다음과 같습니다:

1. 팀으로부터 컨텍스트 수집

2. 솔루션의 정성적 평가

3. 상위 경쟁자를 정량적으로 평가

4. 최종 선정

1. 팀으로부터 컨텍스트 수집

ANN 벡터 검색을 수행하는 데 관심이 있는 팀으로부터 세 가지 컨텍스트를 수집했습니다:

기능적 요구 사항(예: 하이브리드 벡터 및 어휘 검색? 범위 검색 쿼리? 비벡터 속성으로 필터링?)
비기능적 요구 사항(예: 1B 벡터를 지원할 수 있는가? 100ms 미만의 P99 레이턴시에 도달할 수 있는가?)
벡터 데이터베이스 팀이 이미 관심을 갖고 있는 분야

팀과 요구 사항을 인터뷰하는 일은 결코 간단하지 않습니다. 많은 팀이 현재 문제를 해결하고 있는 방식으로 요구 사항을 설명할 것이므로, 이러한 편견을 이해하고 제거하는 것이 과제입니다.

예를 들어, 한 팀은 이미 ANN 벡터 검색에 FAISS를 사용하고 있었고, 새로운 솔루션은 검색 호출당 10,000개의 결과를 효율적으로 반환해야 한다고 말했습니다. 추가 논의 결과, 10K 개의 결과가 나오는 이유는 사후 필터링을 수행해야 하는데, FAISS는 쿼리 시점에 필터링 ANN 결과를 제공하지 않기 때문이었습니다. 실제 문제는 필터링이 필요했기 때문에 효율적인 필터링을 제공하는 솔루션이면 충분했고, 10K 결과를 반환하는 것은 리콜을 개선하는 데 필요한 임시방편에 불과했습니다. 그들은 가장 가까운 이웃을 찾기 전에 전체 컬렉션을 사전 필터링하는 것이 이상적이었습니다.

팀이 이미 사용 중이거나 관심이 있는 벡터 데이터베이스를 요청하는 것도 유용했습니다. 적어도 한 팀 이상이 현재 솔루션에 대해 긍정적인 견해를 가지고 있다면, 벡터 데이터베이스가 회사 전체에서 공유할 수 있는 유용한 솔루션이 될 수 있다는 신호입니다. 솔루션에 대해 부정적인 견해만 가진 팀이 있다면 해당 솔루션을 옵션에 포함시키지 않아야 합니다. 또한 팀이 관심을 보이는 솔루션을 수락하는 것은 팀이 프로세스에 포함되었다고 느끼게 하고 평가할 주요 경쟁자 목록을 작성하는 데 도움이 되는 방법이었습니다. 신규 및 기존 데이터베이스에는 너무 많은 ANN 벡터 검색 솔루션이 있어 모든 솔루션을 철저하게 테스트하기에는 한계가 있습니다.

2. 솔루션의 정성적 평가

팀이 관심을 갖고 있는 솔루션 목록부터 시작하여, 어떤 ANN 벡터 검색 솔루션이 우리의 요구에 가장 적합한지 정성적으로 평가했습니다:

각 솔루션을 조사하고 각 요구 사항을 얼마나 잘 충족하는지, 그리고 해당 요구 사항의 중요도에 따라 가중치를 부여하여 점수를 매겼습니다.
정성적 기준과 토론을 바탕으로 솔루션을 제거했습니다.
정량적으로 테스트할 상위 N개의 솔루션 선정

ANN 벡터 검색 솔루션의 시작 목록은 다음과 같습니다:

Milvus
Qdrant
Weviate
오픈 검색
Pgvector(이미 RDBMS로 Postgres 사용)
Redis(이미 KV 저장소 및 캐시로 사용 중)
Cassandra(이미 비 ANN 검색에 사용 중)
Solr(이미 어휘 검색에 사용 중이며 벡터 검색에 실험적으로 사용됨)
Vespa
Pinecone
Vertex AI(이미 ANN 벡터 검색에 사용됨)

그런 다음 팀에서 언급한 모든 기능적 및 비기능적 요구사항과 엔지니어링 가치와 목표를 나타내는 몇 가지 제약 조건을 추가하여 스프레드시트에 행을 만들고 그 중요도를 1에서 3까지 평가했습니다(아래 요약 표에 표시됨).

비교 대상인 각 솔루션에 대해 각 시스템이 해당 요구 사항을 얼마나 잘 충족하는지 평가(0~3점 척도)했습니다(아래 표 참조). 이러한 방식으로 점수를 매기는 것은 다소 주관적일 수 있으므로 한 시스템을 선택하여 서면 근거와 함께 점수 예시를 제시하고 검토자가 해당 예시를 다시 참조하도록 했습니다. 또한 각 점수 값을 할당할 때 다음과 같은 지침을 제공했습니다. 다음과 같은 경우 이 값을 할당합니다:

0: 요구 사항 지원/증거 없음
1: 기본적이거나 부적절한 요구 사항 지원
2: 요구 사항이 합리적으로 지원됨
3: 비교 가능한 솔루션을 뛰어넘는 강력한 요구 사항 지원

그런 다음 솔루션의 요구 사항 점수와 해당 요구 사항의 중요도의 곱을 합산하여 각 솔루션에 대한 전체 점수를 만들었습니다(예: Qdrant는 재순위/점수 결합에서 3점을 받았고 중요도가 2이므로 3 x 2 = 6, 모든 행에 대해 이를 반복하여 합산). 마지막에는 솔루션의 순위를 매기고 논의할 때 가장 중요한 요구 사항의 기준으로 사용할 수 있는 전체 점수를 얻게 됩니다(이 점수는 최종 결정을 내리는 데 사용되는 것이 아니라 논의 도구로 사용됨을 유의하세요).

편집자 주: 이 리뷰는 Milvus 2.4를 기반으로 작성되었습니다. 이후 Milvus 2.5, Milvus 2.6이 출시되었고 Milvus 3.0이 곧 출시될 예정이므로 일부 수치는 최신 버전이 아닐 수 있습니다. 그럼에도 불구하고 이 비교는 여전히 강력한 인사이트를 제공하며 여전히 매우 유용합니다.


카테고리	중요도	Qdrant	Milvus (2.4)	카산드라	Weviate	Solr	Vertex AI

검색 유형
하이브리드 검색	1	3	2	0	2	2	2
키워드 검색	1	2	2	2	2	3	1
대략적인 NN 검색	3	3	3	2	2	2	2
범위 검색	1	3	3	2	2	0	0
재순위/점수 합산	2	3	2	0	2	2	1

인덱싱 방법
HNSW	3	3	3	2	2	2	0
여러 인덱싱 방법 지원	3	0	3	1	2	1	1
정량화	1	3	3	0	3	0	0
지역 민감 해싱(LSH)	1	0	0주: Milvus 2.6에서 지원합니다.	0	0	0	0

데이터
플로트 이외의 벡터 유형	1	2	2	0	2	2	0
벡터의 메타데이터 속성(여러 속성, 큰 레코드 크기 등 지원)	3	3	2	2	2	2	1
메타데이터 필터링 옵션(메타데이터에 대한 필터링 가능, 사전/사후 필터링 가능)	2	3	2	2	2	3	2
메타데이터 속성 데이터 유형(강력한 스키마, 예: 부울, int, 문자열, json, 배열)	1	3	3	2	2	3	1
메타데이터 속성 제한(범위 쿼리, 예: 10 < x < 15)	1	3	3	2	2	2	1
속성별 결과의 다양성(예: 응답의 각 하위 레딧에서 N 개 이하의 결과만 가져옴)	1	2	1	2	3	3	0

스케일
수억 개의 벡터 인덱스	3	2	3		1	2	3
10억 벡터 인덱스	1	2	2		1	2	2
2k 이상의 지원 벡터	2	2	2	2	2	1	1
2k보다 큰 벡터 지원	2	2	2	2	1	1	1
P95 지연 시간 50-100ms @ X QPS	3	2	2	2	1	1	2
P99 지연 시간 <= 10ms @ X QPS	3	2	2	2	3	1	2
99.9% 가용성 검색	2	2	2	3	2	2	2
99.99% 가용성 인덱싱/저장	2	1	1	3	2	2	2

스토리지 운영
AWS에서 호스팅 가능	3	2	2	2	2	3	0
다중 지역	1	1	2	3	1	2	2
다운타임 없는 업그레이드	1	2	2	3	2	2	1
멀티 클라우드	1	3	3	3	2	2	0

API/라이브러리
gRPC	2	2	2	2	2	0	2
RESTful API	1	3	2	2	2	1	2
라이브러리 이동	3	2	2	2	2	1	2
자바 라이브러리	2	2	2	2	2	2	2
Python	2	2	2	2	2	2	2
기타 언어(C++, 루비 등)	1	2	2	3	2	2	2

런타임 운영
프로메테우스 메트릭	3	2	2	2	3	2	0
기본 DB 작업	3	2	2	2	2	2	2
업서트	2	2	2	2	1	2	2
쿠버네티스 오퍼레이터	2	2	2	2	2	2	0
결과 페이지 매김	2	2	2	2	2	2	0
ID로 조회 임베딩하기	2	2	2	2	2	2	2
후보자 ID 및 후보자 점수가 포함된 임베딩 반환	1	3	2	2	2	2	2
사용자 제공 ID	2	2	2	2	2	2	2
대규모 배치 컨텍스트에서 검색 가능	1	2	1	1	2	1	2
백업/스냅샷: 전체 데이터베이스의 백업을 생성하는 기능을 지원합니다.	1	2	2	2	3	3	2
효율적인 대용량 인덱스 지원(콜드 스토리지와 핫 스토리지 구분)	1	3	2	2	2	1	2

지원/커뮤니티
공급업체 중립성	3	3	2	3	2	3	0
강력한 API 지원	3	3	3	2	2	2	2
공급업체 지원	2	2	2	2	2	2	0
커뮤니티 속도	2	3	2	2	2	2	0
프로덕션 사용자 기반	2	3	3	2	2	1	2
커뮤니티 느낌	1	3	2	2	2	2	1
깃허브 스타	1	2	2	2	2	2	0

구성
비밀 처리	2	2	2	2	1	2	2

Source
오픈 소스	3	3	3	3	2	3	0
언어	2	3	3	2	3	2	0
릴리스	2	3	3	2	2	2	2
업스트림 테스트	1	2	3	3	2	2	2
문서 가용성	3	3	3	2	1	2	1

비용
비용 효율적	2	2	2	2	2	2	1

성능
CPU, 메모리 및 디스크의 리소스 사용률 조정 지원	3	2	2	2	2	2	2
멀티노드(포드) 샤딩	3	2	2	3	2	2	2
지연 시간과 처리량 간의 균형을 맞추기 위해 시스템을 조정할 수 있는 능력 보유	2	2	2	3	2	2	2
사용자 정의 파티셔닝(쓰기)	1	3	2	3	1	2	0
멀티 테넌트	1	3	2	1	3	2	2
파티셔닝	2	2	2	3	2	2	2
복제	2	2	2	3	2	2	2
중복성	1	2	2	3	2	2	2
자동 페일오버	3	2	0 참고: Milvus 2.6에서 지원합니다.	3	2	2	2
로드 밸런싱	2	2	2	3	2	2	2
GPU 지원	1	0	2	0	0	0	0

		Qdrant	Milvus	카산드라	Weviate	Solr	Vertex AI
전체 솔루션 점수		292	281	264	250	242	173

다양한 시스템의 전체 및 요구사항 점수를 논의하고 요구사항의 중요도에 적절한 가중치를 부여했는지, 일부 요구사항이 핵심 제약 조건으로 간주되어야 할 정도로 중요한지 여부를 파악하고자 했습니다. 우리가 파악한 요구 사항 중 하나는 솔루션이 오픈 소스인지 여부였는데, 우리 규모에서 작은 문제가 발생할 경우 우리가 참여하고 기여할 수 있으며 신속하게 해결할 수 있는 솔루션을 원했기 때문입니다. 오픈소스 소프트웨어에 기여하고 사용하는 것은 Reddit의 엔지니어링 문화에서 중요한 부분입니다. 따라서 호스팅 전용 솔루션(Vertex AI, Pinecone)은 고려 대상에서 제외되었습니다.

논의하는 과정에서 몇 가지 다른 주요 요구 사항이 매우 중요하다는 것을 알게 되었습니다:

규모와 안정성: 1억 개 이상의 벡터 또는 10억 개 이상의 벡터로 솔루션을 실행하는 다른 회사의 사례를 보고 싶었습니다.
커뮤니티: 빠르게 성숙해가는 이 분야에서 많은 추진력을 가진 건강한 커뮤니티가 있는 솔루션을 원했습니다.
표현형 메타데이터 유형과 필터링을 통해 더 많은 사용 사례(날짜, 부울 등으로 필터링 등)를 지원합니다.
다양한 고유 사용 사례의 성능에 더 잘 맞도록 여러 인덱스 유형(HNSW 또는 DiskANN뿐만 아니라)을 지원합니다.

주요 요구사항에 대한 논의와 연마 결과, 정량적 테스트를 (순서대로) 선택하게 되었습니다:

Qdrant
Milvus
Vespa, 그리고
Weviate

안타깝게도 이와 같은 결정에는 시간과 리소스가 필요하며, 어느 조직도 이 두 가지를 무제한으로 확보할 수는 없습니다. 저희는 예산을 고려하여 Qdrant와 Milvus를 테스트하기로 결정하고 Vespa와 Weviate 테스트는 확장 목표로 남겨두기로 했습니다.

Qdrant와 Milvus는 서로 다른 두 아키텍처에 대한 흥미로운 테스트이기도 했습니다:

Qdrant: 모든 ANN 벡터 데이터베이스 연산을 수행하는 동종 노드 유형
밀버스: 이기종 노드 유형 (밀버스; 쿼리용, 인덱싱용, 데이터 수집용, 프록시 등)

어떤 것이 설정하기 쉬웠나요(문서 테스트)? 어느 것이 실행하기 쉬웠나요(복원력 기능 및 광택 테스트)? 그리고 어떤 것이 우리가 중요하게 생각하는 사용 사례와 규모에 가장 적합한가? 솔루션을 정량적으로 비교하면서 이러한 질문에 대한 답을 찾고자 했습니다.

3. 상위 경쟁 솔루션의 정량적 평가

각 솔루션의 확장성을 더 잘 이해하고, 그 과정에서 각 솔루션을 대규모로 설정, 구성, 유지 관리 및 실행하는 것이 어떤 것인지 경험하고 싶었습니다. 이를 위해 세 가지 사용 사례에 대한 세 가지 문서 및 쿼리 벡터 데이터 세트를 수집하고, Kubernetes 내에서 유사한 리소스로 각 솔루션을 설정하고, 각 솔루션에 문서를 로드한 다음, 램핑 도착 속도 실행기와 함께 Grafana의 K6를 사용하여 동일한 쿼리 부하를 전송하여 시스템을 워밍업한 다음 목표 처리량(예: 100 QPS)에 도달했습니다.

처리량, 각 솔루션의 한계점, 처리량과 지연 시간 간의 관계, 부하가 걸린 노드 손실에 대한 반응(오류율, 지연 시간 영향 등)을 테스트했습니다. 주요 관심사는 필터링이 지연 시간에 미치는 영향이었습니다. 또한 문서에 설명된 기능(예: 업서트, 삭제, ID로 조회, 사용자 관리 등)이 설명대로 작동하는지 확인하고 해당 API의 인체공학적 특성을 체험하기 위해 간단한 예/아니오 테스트를 진행했습니다.

테스트는 Milvus v2.4 및 Qdrant v1.12에서 수행되었습니다. 시간 제약으로 인해 모든 유형의 인덱스 설정을 철저하게 조정하거나 테스트하지는 않았으며, 각 솔루션에서 유사한 설정이 사용되었고, 높은 ANN 리콜에 편향되어 HNSW 인덱스의 성능에 중점을 두고 테스트가 진행되었습니다. 또한 각 솔루션에 비슷한 CPU 및 메모리 리소스를 할당했습니다.

실험을 통해 두 솔루션 간에 몇 가지 흥미로운 차이점을 발견했습니다. 다음 실험에서 각 솔루션에는 각각 384개의 차원을 가진 약 3억 4천만 개의 Reddit 포스트 벡터가 있었고, HNSW, M=16, efConstruction=100의 경우였습니다.

한 실험에서 동일한 쿼리 처리량(동시에 수집이 없는 100 QPS)의 경우 필터링을 추가하는 것이 Qdrant보다 Milvus의 지연 시간에 더 많은 영향을 미치는 것으로 나타났습니다.

필터링을 사용한 포스트 쿼리 지연 시간

또 다른 테스트에서는 수집과 쿼리 부하 간에 상호 작용이 Milvus보다 Qdrant에서 훨씬 더 많이 발생하는 것으로 나타났습니다(아래는 일정한 처리량에서 표시). 이는 아키텍처 때문인 것으로 보입니다. Milvus는 수집의 대부분을 쿼리 트래픽을 처리하는 노드와 별도의 노드 유형으로 분리하는 반면, Qdrant는 동일한 노드에서 수집과 쿼리 트래픽을 모두 처리합니다.

수집 중 100 QPS의 쿼리 지연 시간 게시

속성별 결과의 다양성(예: 응답의 각 하위 레딧에서 N개 이하의 결과 가져오기)을 테스트했을 때, 동일한 처리량에서 Milvus의 지연 시간이 Qdrant보다 더 나쁜 것으로 나타났습니다(100 QPS 기준).

결과 다양성을 통한 쿼리 후 지연 시간

또한 데이터 복제본이 더 많이 추가될 때(즉, 복제 계수인 RF를 1에서 2로 늘렸을 때) 각 솔루션이 얼마나 효과적으로 확장되는지도 살펴보고 싶었습니다. 처음에 RF=1로 설정했을 때, Qdrant는 Milvus보다 더 많은 처리량에 대해 만족스러운 지연 시간을 제공할 수 있었습니다(테스트가 오류 없이 완료되지 않았기 때문에 더 높은 QPS는 표시되지 않음).

다양한 처리량에 대해 RF=1 지연 시간을 게시하는 Qdrant

Milvus는 다양한 처리량에 대해 RF=1 지연 시간을 게시합니다.

그러나 복제 계수를 늘렸을 때 Qdrant의 p99 레이턴시는 개선되었지만 Milvus는 허용 가능한 레이턴시로 Qdrant보다 더 높은 처리량을 유지할 수 있었습니다(높은 레이턴시와 오류로 인해 테스트가 완료되지 않았으므로 Qdrant 400 QPS는 표시되지 않음).

다양한 처리량에 대해 RF=2 지연 시간을 게시하는 Milvus

다양한 처리량에 대해 RF=2 지연 시간을 게시하는 Qdrant

시간 제약으로 인해 데이터 세트에서 솔루션 간의 ANN 호출을 비교할 시간이 충분하지 않았지만, 공개적으로 사용 가능한 데이터 세트에서 https://ann-benchmarks.com/ 에서 제공하는 솔루션에 대한 ANN 호출 측정값을 고려했습니다.

4. 최종 선택

성능 측면에서, 별다른 튜닝 없이 HNSW만 사용한 Qdrant는 많은 테스트에서 Milvus보다 원시 지연 시간이 더 나은 것으로 나타났습니다. 그러나 Milvus는 복제가 증가함에 따라 더 잘 확장되는 것처럼 보였고, 다중 노드 유형 아키텍처로 인해 수집과 쿼리 부하 간의 격리가 더 잘 이루어졌습니다.

운영 측면에서는 Milvus 아키텍처의 복잡성(다중 노드 유형, Kafka와 같은 외부 쓰기 전 로그와 etcd와 같은 메타데이터 저장소에 의존)에도 불구하고, 두 솔루션 중 하나가 불량 상태에 진입했을 때 Qdrant보다 Milvus를 디버깅하고 수정하는 데 더 수월했습니다. 또한 Milvus는 컬렉션의 복제 계수를 늘릴 때 자동 리밸런싱 기능을 제공하는 반면, 오픈 소스 Qdrant에서는 복제 계수를 늘리려면 수동으로 샤드를 생성하거나 삭제해야 했습니다(이 기능은 우리가 직접 구축하거나 오픈 소스 이외의 버전을 사용해야 했을 것입니다).

Milvus는 Qdrant보다 더 "Reddit형" 기술이며, 나머지 기술 스택과 더 많은 유사성을 공유합니다. Milvus는 우리가 선호하는 백엔드 프로그래밍 언어인 Golang으로 작성되었기 때문에 Rust로 작성된 Qdrant보다 기여하기가 더 쉽습니다. Milvus는 오픈 소스 제품치고는 프로젝트 속도가 Qdrant에 비해 뛰어났고, 저희의 주요 요구 사항을 더 많이 충족했습니다.

결국 두 솔루션 모두 대부분의 요구 사항을 충족했으며, 일부 경우 Qdrant가 성능 면에서 우위를 보였지만 Milvus를 더 확장할 수 있고 더 편하게 실행할 수 있으며 Qdrant보다 우리 조직에 더 잘 맞는다고 느꼈습니다. Vespa와 Weaviate를 테스트할 시간이 더 있었다면 좋았겠지만, 이 역시 조직 적합성(Vespa는 Java 기반)과 아키텍처(Weaviate는 Qdrant와 같은 단일 노드 유형) 때문에 선택되지 않았을 수도 있습니다.

주요 요점

주어진 요구 사항에 도전하고 기존 솔루션에 대한 편견을 없애세요.
후보 솔루션에 점수를 매기고, 이를 모든 것이 아닌 필수 요구 사항에 대한 논의에 활용하세요.
솔루션을 정량적으로 평가하되, 그 과정에서 해당 솔루션으로 작업하는 것이 어떤 느낌인지 기록해 두세요.
단순히 성능이 가장 좋은 솔루션이 아니라 유지보수, 비용, 사용성, 성능의 관점에서 조직에 가장 적합한 솔루션을 선택하세요.

감사의 말

이 평가 작업은 벤 코치, 찰스 은조로게, 아밋 쿠마르, 그리고 제가 수행했습니다. 또한 질적 솔루션 연구를 위해 Annie Yang, Konrad Reiche, Sabrina Kong, Andrew Johnson 등 이 작업에 기여한 다른 분들께도 감사드립니다.

편집자 주

벡터 검색 워크로드에 Milvus를 선택해 주었을 뿐만 아니라 시간을 내어 상세하고 공정한 평가를 발표해 주신 Reddit 엔지니어링 팀에 진심으로 감사의 말씀을 전합니다. 실제 엔지니어링 팀이 데이터베이스를 비교하는 방식에 대해 이 정도 수준의 투명성을 보이는 경우는 드물며, 이 글은 성장하는 벡터 데이터베이스 환경을 이해하고자 하는 Milvus 커뮤니티와 그 밖의 모든 사람들에게 도움이 될 것입니다.

크리스도 글에서 언급했듯이 "최고의" 벡터 데이터베이스는 하나밖에 없습니다. 중요한 것은 시스템이 워크로드, 제약 조건 및 운영 철학에 맞는지 여부입니다. Reddit의 비교는 이러한 현실을 잘 반영하고 있습니다. Milvus가 모든 카테고리에서 1위를 차지하지는 못하며, 이는 다양한 데이터 모델과 성능 목표에 따른 장단점을 고려할 때 충분히 예상할 수 있는 일입니다.

한 가지 명확히 할 필요가 있습니다: Reddit의 평가는 당시 안정 버전이었던 Milvus 2.4를 사용했습니다. LSH 및 여러 인덱스 최적화와 같은 일부 기능은 아직 존재하지 않았거나 2.4에서는 성숙하지 않았기 때문에 일부 점수는 자연스럽게 이전 기준선을 반영하고 있습니다. 그 이후 Milvus 2.5를 출시한 데 이어 Milvus 2.6을 출시했는데, 성능, 효율성, 유연성 측면에서 매우 다른 시스템입니다. 커뮤니티의 반응은 매우 뜨거웠고 이미 많은 팀이 업그레이드를 완료했습니다.

Milvus 2.6의 새로운 기능을 간략히 살펴보세요: