VDBBench 1.0 발표: 실제 프로덕션 워크로드를 활용한 오픈 소스 VectorDB 벤치마킹
대부분의 벡터 데이터베이스 벤치마크는 정적 데이터와 사전 구축된 인덱스로 테스트합니다. 하지만 프로덕션 시스템은 그렇게 작동하지 않습니다—사용자가 쿼리를 실행하는 동안 데이터는 지속적으로 흐르고, 필터는 인덱스를 단편화하며, 동시 읽기/쓰기 부하에서는 성능 특성이 극적으로 변합니다.
오늘 저희는 현실적인 프로덕션 조건에서 벡터 데이터베이스를 테스트하도록 처음부터 설계된 오픈소스 벤치마크인 VDBBench 1.0을 출시합니다: 스트리밍 데이터 수집, 다양한 선택도를 가진 메타데이터 필터링, 실제 시스템 병목을 드러내는 동시 워크로드를 포함합니다.
VDBBench 1.0 다운로드 → | 리더보드 보기 →
현재 벤치마크가 오해를 불러일으키는 이유
솔직히 말해, 우리 업계에는 이상한 현상이 있습니다. 모두가 "벤치마크를 조작하지 말자"고 말하지만, 많은 이들이 정확히 그런 행동에 참여하고 있습니다. 2023년에 벡터 데이터베이스 시장이 폭발적으로 성장한 이후, "벤치마크에서는 훌륭해 보이지만" 프로덕션에서는 "참담하게 실패하는" 시스템 사례를 수없이 보아 왔고, 이는 엔지니어링 시간을 낭비하고 프로젝트 신뢰도를 떨어뜨렸습니다.
저희는 이러한 괴리를 직접 목격했습니다. 예를 들어, Elasticsearch는 밀리초 수준의 쿼리 속도를 자랑하지만, 그 이면에서는 인덱스를 최적화하는 데만 20시간 이상 걸릴 수 있습니다. 어떤 프로덕션 시스템이 이런 다운타임을 감당할 수 있을까요?
문제는 세 가지 근본적인 결함에서 비롯됩니다:
오래된 데이터셋: 많은 벤치마크가 여전히 SIFT(128차원)와 같은 레거시 데이터셋에 의존하는 반면, 최신 임베딩은 768~3,072차원에 이릅니다. 128D 벡터와 1024D+ 벡터에서 작동하는 시스템의 성능 특성은 근본적으로 다릅니다—메모리 접근 패턴, 인덱스 효율성, 계산 복잡도가 모두 극적으로 변합니다.
허영 지표: 벤치마크는 평균 지연 시간이나 최대 QPS에 초점을 맞추며 왜곡된 그림을 만들어냅니다. 평균 지연 시간이 10ms이지만 P99 지연 시간이 2초인 시스템은 끔찍한 사용자 경험을 만듭니다. 30초 동안 측정한 최대 처리량은 지속적인 성능에 대해 아무것도 알려주지 않습니다.
과도하게 단순화된 시나리오: 대부분의 벤치마크는 기본적인 "데이터 쓰기, 인덱스 구축, 쿼리" 워크플로를 테스트합니다—본질적으로 "Hello World" 수준의 테스트입니다. 실제 프로덕션에서는 쿼리를 제공하는 동안 지속적인 데이터 수집이 이루어지고, 인덱스를 단편화하는 복잡한 메타데이터 필터링이 있으며, 리소스를 두고 경쟁하는 동시 읽기/쓰기 작업이 발생합니다.
VDBBench 1.0의 새로운 점은 무엇인가요?
VDBBench는 오래된 벤치마킹 철학을 단순히 반복하지 않습니다—하나의 지침이 되는 믿음, 즉 벤치마크는 실제 프로덕션 동작을 예측할 수 있을 때만 가치가 있다는 믿음을 바탕으로 개념을 처음부터 다시 구축합니다.
저희는 VDBBench가 데이터 진정성, 워크로드 패턴, 성능 측정 방법론이라는 세 가지 핵심 차원에서 실제 조건을 충실히 재현하도록 설계했습니다.
어떤 새로운 기능들이 제공되는지 자세히 살펴보겠습니다.
🚀 프로덕션에 적합한 시각화를 갖춘 재설계된 대시보드
대부분의 벤치마크는 원시 데이터 출력에만 초점을 맞추지만, 중요한 것은 엔지니어가 그 결과를 어떻게 해석하고 행동으로 옮기는가입니다. 저희는 명확성과 상호작용성을 우선시하도록 UI를 재설계했습니다—시스템 간 성능 격차를 파악하고 빠른 인프라 결정을 내릴 수 있게 합니다.
새로운 대시보드는 성능 수치뿐 아니라 그들 사이의 관계도 시각화합니다: 다양한 필터 선택도 수준에서 QPS가 어떻게 저하되는지, 스트리밍 수집 중 recall이 어떻게 변동하는지, 지연 시간 분포가 시스템 안정성 특성을 어떻게 드러내는지 보여줍니다.
VDBbench 대시보드
최신 구성과 권장 설정을 적용하여 Milvus, Zilliz Cloud, Elastic Cloud, Qdrant Cloud, Pinecone, OpenSearch를 포함한 주요 벡터 데이터베이스 플랫폼을 다시 테스트했으며, 모든 벤치마크 데이터가 현재 역량을 반영하도록 했습니다. 모든 테스트 결과는 VDBBench 리더보드에서 확인할 수 있습니다.
🏷️ 태그 필터링: 숨겨진 성능 저하 요인
실제 쿼리는 거의 단독으로 발생하지 않습니다. 애플리케이션은 벡터 유사도와 메타데이터 필터링을 결합합니다("이 사진과 비슷하게 생겼지만 100달러 미만인 신발 찾기"). 이러한 필터링된 벡터 검색은 대부분의 벤치마크가 완전히 간과하는 고유한 과제를 만들어냅니다.
필터링된 검색은 두 가지 중요한 영역에서 복잡성을 유발합니다:
필터 복잡성: 더 많은 스칼라 필드와 복잡한 논리 조건은 계산 요구량을 증가시키며, 불충분한 재현율과 그래프 인덱스 단편화를 초래할 수 있습니다.
필터 선택도: 이는 프로덕션에서 반복적으로 확인한 "숨겨진 성능 저하 요인"입니다. 필터링 조건이 매우 선택적이 되면(데이터의 99% 이상을 걸러내는 경우), 쿼리 속도는 몇 자릿수 규모로 변동할 수 있고, 인덱스 구조가 희소한 결과 집합을 처리하는 데 어려움을 겪으면서 재현율이 불안정해질 수 있습니다.
VDBBench는 다양한 필터링 선택도 수준(50%부터 99.9%까지)을 체계적으로 테스트하여, 이 중요한 프로덕션 패턴에서 포괄적인 성능 프로필을 제공합니다. 결과는 전통적인 벤치마크에서는 결코 드러나지 않을 극적인 성능 절벽을 자주 보여줍니다.
예시: Cohere 1M 테스트에서 Milvus는 모든 필터 선택도 수준에서 일관되게 높은 재현율을 유지한 반면, OpenSearch는 서로 다른 필터링 조건에서 재현율이 크게 변동하는 불안정한 성능을 보였으며, 많은 경우 재현율이 0.8 아래로 떨어졌습니다. 이는 대부분의 프로덕션 환경에서 허용될 수 없습니다.
그림: 다양한 필터 선택도 수준에서 Milvus와 OpenSearch의 QPS 및 재현율(Cohere 1M 테스트).
🌊 스트리밍 읽기/쓰기: 정적 인덱스 테스트를 넘어
프로덕션 시스템은 정적 데이터라는 사치를 누리는 경우가 거의 없습니다. 검색이 실행되는 동안 새로운 정보가 지속적으로 유입됩니다. 이는 검색 성능을 유지하면서 지속적인 쓰기를 처리해야 하는 이중 압박 속에서, 겉보기에는 인상적인 많은 데이터베이스가 무너지는 시나리오입니다.
VDBBench의 스트리밍 시나리오는 실제 병렬 작업을 시뮬레이션하여, 개발자가 고동시성 환경에서 시스템 안정성을 이해하도록 돕습니다. 특히 데이터 쓰기가 쿼리 성능에 어떤 영향을 미치는지, 데이터 볼륨이 증가함에 따라 성능이 어떻게 변화하는지를 파악할 수 있습니다.
서로 다른 시스템 간의 공정한 비교를 보장하기 위해 VDBBench는 구조화된 접근 방식을 사용합니다:
목표 프로덕션 워크로드를 반영하는 제어된 쓰기 속도 구성(예: 5개의 병렬 프로세스에 분산된 500 rows/sec)
데이터 수집이 10% 진행될 때마다 검색 작업을 트리거하고, 직렬 모드와 동시 모드를 번갈아 실행
포괄적인 지표 기록: 지연 시간 분포(P99 포함), 지속 QPS, 재현율 정확도
데이터 볼륨과 시스템 스트레스가 증가함에 따라 시간에 따른 성능 변화 추적
이러한 제어된 점진적 부하 테스트는 지속적인 수집 상황에서 시스템이 안정성과 정확도를 얼마나 잘 유지하는지를 드러냅니다. 이는 전통적인 벤치마크가 거의 포착하지 못하는 부분입니다.
예시: Cohere 10M 스트리밍 테스트에서 Pinecone은 Elasticsearch와 비교해 쓰기 주기 전반에 걸쳐 더 높은 QPS와 재현율을 유지했습니다. 특히 Pinecone의 성능은 수집 완료 후 크게 향상되어 지속 부하에서 강한 안정성을 입증한 반면, Elasticsearch는 활성 수집 단계에서 더 불규칙한 동작을 보였습니다.
그림: Cohere 10M 스트리밍 테스트에서 Pinecone과 Elasticsearch의 QPS 및 재현율 비교(500 rows/s 수집 속도).
VDBBench는 선택적 최적화 단계를 지원함으로써 한층 더 나아가, 사용자가 인덱스 최적화 전후의 스트리밍 검색 성능을 비교할 수 있도록 합니다. 또한 각 단계에 실제로 소요된 시간을 추적하고 보고하여, 프로덕션과 유사한 조건에서 시스템 효율성과 동작에 대한 더 깊은 인사이트를 제공합니다.
그림: 최적화 후 Cohere 10M 스트리밍 테스트에서 Pinecone과 Elasticsearch의 QPS 및 Recall 비교(500 rows/s 수집 속도)
테스트에서 보였듯이, Elasticsearch는 인덱스 최적화 후 QPS에서 Pinecone을 앞질렀습니다. 하지만 x축이 실제 경과 시간을 반영하면, Elasticsearch가 해당 성능에 도달하는 데 훨씬 더 오래 걸렸다는 것이 명확합니다. 프로덕션에서는 이러한 지연이 중요합니다. 이 비교는 핵심적인 트레이드오프를 보여줍니다: 최대 처리량 vs. 서비스 제공까지 걸리는 시간.
🔬 현재 AI 워크로드를 반영하는 최신 데이터셋
벡터 데이터베이스 벤치마킹에 사용되는 데이터셋을 완전히 개편했습니다. SIFT와 GloVe 같은 레거시 테스트 세트 대신, VDBBench는 오늘날의 AI 애플리케이션을 구동하는 OpenAI 및 Cohere 같은 최신 임베딩 모델에서 생성된 벡터를 사용합니다.
특히 Retrieval-Augmented Generation (RAG) 같은 사용 사례와의 관련성을 보장하기 위해, 실제 엔터프라이즈 및 도메인 특화 시나리오를 반영하는 말뭉치를 선택했습니다:
| 말뭉치 | 임베딩 모델 | 차원 | 크기 | 사용 사례 |
|---|---|---|---|---|
| Wikipedia | Cohere V2 | 768 | 1M / 10M | 일반 지식 베이스 |
| BioASQ | Cohere V3 | 1024 | 1M / 10M | 도메인 특화(바이오메디컬) |
| C4 | OpenAI | 1536 | 500K / 5M | 웹 규모 텍스트 처리 |
| MSMarco V2 | udever-bloom-1b1 | 1536 | 1M / 10M / 138M | 대규모 검색 |
이러한 데이터셋은 오늘날의 대용량, 고차원 벡터 데이터를 더 잘 시뮬레이션하여, 최신 AI 워크로드에 부합하는 조건에서 저장 효율성, 쿼리 성능, 검색 정확도에 대한 현실적인 테스트를 가능하게 합니다.
⚙️ 산업별 테스트를 위한 사용자 지정 데이터셋 지원
모든 비즈니스는 고유합니다. 금융 산업은 트랜잭션 임베딩에 초점을 맞춘 테스트가 필요할 수 있고, 소셜 플랫폼은 사용자 행동 벡터에 더 관심을 둘 수 있습니다. VDBBench를 사용하면 특정 워크로드를 위해 특정 임베딩 모델에서 생성한 자체 데이터로 벤치마킹할 수 있습니다.
사용자 지정할 수 있는 항목:
벡터 차원 및 데이터 유형
메타데이터 스키마 및 필터링 패턴
데이터 볼륨 및 수집 패턴
프로덕션 트래픽과 일치하는 쿼리 분포
결국, 자체 프로덕션 데이터보다 더 나은 이야기를 들려주는 데이터셋은 없습니다.
VDBBench가 프로덕션에서 실제로 중요한 것을 측정하는 방법
프로덕션 중심 메트릭 설계
VDBBench는 단순한 실험실 결과가 아니라 실제 성능을 반영하는 메트릭을 우선시합니다. 벤치마킹을 프로덕션 환경에서 실제로 중요한 것, 즉 부하 상황에서의 안정성, 테일 지연 시간 특성, 지속 처리량, 정확도 유지를 중심으로 재설계했습니다.
실제 사용자 경험을 위한 P95/P99 지연 시간: 평균/중앙값 지연 시간은 실제 사용자를 좌절시키고 근본적인 시스템 불안정성을 나타낼 수 있는 이상치를 가립니다. VDBBench는 P95/P99 같은 테일 지연 시간에 초점을 맞춰, 쿼리의 95% 또는 99%가 실제로 달성할 성능을 드러냅니다. 이는 SLA 계획과 최악의 사용자 경험을 이해하는 데 매우 중요합니다.
부하 상황에서의 지속 가능한 처리량: 5초 동안만 잘 작동하는 시스템은 프로덕션에서는 충분하지 않습니다. VDBBench는 동시성을 점진적으로 증가시켜 데이터베이스의 최대 지속 가능 초당 쿼리 수(
max_qps)를 찾습니다. 이는 짧고 이상적인 조건에서의 최대 수치가 아닙니다. 이 방법론은 시스템이 시간이 지나도 얼마나 잘 버티는지 보여주며 현실적인 용량 계획에 도움이 됩니다.성능과 균형을 이룬 리콜: 정확도 없는 속도는 의미가 없습니다. VDBBench의 모든 성능 수치는 리콜 측정값과 함께 제공되므로, 처리량을 위해 얼마나 많은 관련성을 포기하고 있는지 정확히 알 수 있습니다. 이를 통해 내부 트레이드오프가 크게 다른 시스템 간에도 공정한, 동등 조건의 비교가 가능합니다.
현실을 반영하는 테스트 방법론
VDBBench 설계의 핵심 혁신은 직렬 테스트와 동시성 테스트를 분리한 것으로, 이를 통해 시스템이 다양한 유형의 부하에서 어떻게 동작하는지 포착하고, 다양한 사용 사례에 중요한 성능 특성을 드러낼 수 있습니다.
지연 시간 측정 분리:
serial_latency_p99는 한 번에 하나의 요청만 처리되는 최소 부하 상태에서의 시스템 성능을 측정합니다. 이는 지연 시간 측면에서 최상의 시나리오를 나타내며, 기준 시스템 역량을 식별하는 데 도움이 됩니다.conc_latency_p99는 여러 요청이 동시에 도착하여 시스템 리소스를 두고 경쟁하는 현실적인 고동시성 조건에서의 시스템 동작을 포착합니다.
2단계 벤치마크 구조:
직렬 테스트: 기준 성능과 정확도를 확립하는 1,000개 쿼리의 단일 프로세스 실행으로,
serial_latency_p99와 리콜을 모두 보고합니다. 이 단계는 이론적 성능 한계를 식별하는 데 도움이 됩니다.동시성 테스트: 지속적인 부하가 있는 프로덕션 환경을 시뮬레이션하며, 다음과 같은 몇 가지 핵심 혁신을 포함합니다:
현실적인 클라이언트 시뮬레이션: 각 테스트 프로세스는 자체 연결과 쿼리 세트를 가지고 독립적으로 작동하여, 결과를 왜곡할 수 있는 공유 상태 간섭을 방지합니다
동기화된 시작: 모든 프로세스가 동시에 시작하여, 측정된 QPS가 주장된 동시성 수준을 정확히 반영하도록 보장합니다
독립적인 쿼리 세트: 프로덕션 쿼리 다양성을 반영하지 않는 비현실적인 캐시 적중률을 방지합니다
이처럼 신중하게 구성된 방법은 VDBBench가 보고하는 max_qps 및 conc_latency_p99 값이 정확하면서도 프로덕션과 관련성이 있도록 보장하여, 프로덕션 용량 계획 및 시스템 설계에 의미 있는 인사이트를 제공합니다.
VDBBench 1.0 시작하기
VDBBench 1.0은 프로덕션 관련성이 높은 벤치마킹을 향한 근본적인 전환을 의미합니다. 지속적인 데이터 쓰기, 다양한 선택도를 가진 메타데이터 필터링, 동시 접근 패턴에서의 스트리밍 부하를 다룸으로써, 오늘날 이용 가능한 실제 프로덕션 환경에 가장 가까운 근사치를 제공합니다.
벤치마크 결과와 실제 성능 사이의 격차가 추측 게임이 되어서는 안 됩니다. 벡터 데이터베이스를 프로덕션에 배포할 계획이라면, 이상화된 실험실 테스트를 넘어 실제로 어떻게 성능을 내는지 이해할 가치가 있습니다. VDBBench는 오픈소스이고 투명하며, 의미 있는 동등 조건 비교를 지원하도록 설계되었습니다.
프로덕션 가치로 이어지지 않는 인상적인 수치에 흔들리지 마십시오. VDBBench 1.0을 사용하여 비즈니스에 중요한 시나리오를, 여러분의 데이터로, 실제 워크로드를 반영하는 조건에서 테스트하십시오. 벡터 데이터베이스 평가에서 오해를 불러일으키는 벤치마크의 시대는 끝나가고 있습니다. 이제 프로덕션 관련 데이터에 기반해 결정을 내려야 할 때입니다.
자체 워크로드로 VDBBench 사용해 보기: https://github.com/zilliztech/VectorDBBench
주요 벡터 데이터베이스의 테스트 결과 보기: VDBBench Leaderboard
질문이 있거나 결과를 공유하고 싶으신가요? GitHub에서 대화에 참여하거나 Discord에서 커뮤니티와 연결하세요.
계속 읽기
Vector Lakebase: End the AI Data Silo
Learn how Vector Lakebase unifies vector search, data lakes, and AI data operations so teams can serve RAG and agents without copy-and-sync pipelines.
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.
Vector Databases vs. Hierarchical Databases
Use a vector database for AI-powered similarity search; use a hierarchical database for organizing data in parent-child relationships with efficient top-down access patterns.