검색 증강 생성(RAG), 시맨틱 검색, 그리고 AI 에이전트는 모두 한 가지, 즉 대규모 데이터셋에서 가장 관련성이 높은 벡터를 빠르게 찾아내는 능력에 의존합니다. 임베딩 데이터셋이 수백만 개에서 수십억 개의 레코드n로 성장함에 따라, 순수 메모리 내 벡터 인덱스는 재정적으로 유지 불가능해집니다. DiskANN은 RAM 대신 SSD에 벡터 인덱스를 저장하여 이 문제를 해결하며, 상용 하드웨어에서 웹 규모의 검색을 가능하게 합니다.
디스크앤(DiskANN)은 대규모 벡터 검색을 고속으로 수행하기 위해 마이크로소프트와 인도 과학원(IISc)이 공동 개발한 최첨단 근사 최근접 이웃(ANN) 검색 알고리즘입니다. RAM 대신 상대적으로 저렴하고 용량이 큰 솔리드 스테이트 드라이브(SSD, Disk)를 활용하여 수십억 개의 벡터를 효율적으로 인덱싱하고 검색할 수 있는 것이 특징입니다.
DiskANN 마이크로소프트 연구소(Microsoft Research)에서 개발하여 2019년 NeurIPS에서 처음 발표된 그래프 기반 벡터 검색 알고리즘입니다. SSD를 주요 저장 매체로 사용하고 인덱스의 압축된 표현만 RAM에 유지하면서, 10억 개 규모의 벡터 데이터셋에 대해 근사 믁근접 이웃(ANN) 검색을 수행합니다.
DiskANN 이전에는 HNSW 및 FAISS와 같은 알고리즘들이 전체 벡터 인덱스가 DRAM에 상주할 것을 요구했습니다. 10억 개의 벡터 규모에서는 수백 기가바이트의 RAM과 프로비저닝 및 확장 비용이 많이 드는 인프라가 필요합니다. DiskANN은 인 메모리 방식과 경쟁력 있는 재현율(recall) 및 지연 시간(latency) 특성을 유지하면서 인덱스의 대부분을 디스크로 이전하여 이러한 제약을 깨뜨립니다. 이 기술은 효율적인 디스크 기반 탐색에 매우 적합한 단일 계층 방향성 그래프를 생성하는 새로운 그래프 구축 방법인 Vamana 알고리즘을 기반으로 구축되었습니다.
원문의 주요 벤치마크 NeurIPS 2019 논문:
- 10억 이상 64GB RAM이 탑재된 단일 머신에 색인된 벡터들
- 5-10x 동일한 지연 시간에서의 DRAM 전용 솔루션 대비 머신당 더 많은 벡터
- 5 ms 미만 SIFT-1B 벤치마크에서 95%+ 리콜을 적용했을 때의 쿼리 지연 시간
DiskANN은 현재 마이크로소프트의 벡터 검색 인프라의 기반(Bing 및 Microsoft 365에서 사용됨)이며 다음과 같은 기업들에 의해 채택되었습니다. 카우치베이스, Azure Cosmos DB, Azure Database for PostgreSQL, TimescaleDB의 pgvectorscale 및 기타 데이터베이스.
디스크ANN이 작동하는 방식
DiskANN은 인덱스 구조 및 탐색을 위한 Vamana 그래프와 메모리 내 벡터 압축을 위한 양자화(PQ)라는 두 가지 기술을 결합합니다.
바마나(Vamana) 그래프 구축 중: 바마나(Vamana)는 각 노드가 벡터를 나타내는 단일 계층 유향 그래프를 구성합니다. 무작위 연결로 초기화한 후, 두 번의 패스로 이루어진 가지치기(pruning)를 통해 정제됩니다. 첫 번째 패스는 중복된 단거리 에지를 제거하고, 두 번째 패스는 검색 알고리즘이 비용이 많이 드는 다중 홉 탐색 없이 그래프의 올바른 영역으로 빠르게 이동할 수 있도록 장거리 에지를 추가합니다. HNSW의 다중 계층 구조와 달리, DiskANN의 단일 계층 구조는 디스크 상에서 실현 가능하게 만듭니다.
RAM/SSD 분할: PQ로 압축된 벡터(예: 128차원 float32 벡터의 경우 512바이트 대비 32바이트)는 빠른 대략적 거리 계산을 위해 RAM에 캐시됩니다. 전체 Vamana 그래프 인덱스 및 고정밀 벡터는 SSD에 상주하며 최종 재순위화(reranking)를 위해서만 읽혀집니다.
쿼리 실행: 검색은 두 단계로 실행됩니다. 먼저, 알고리즘은 RAM의 PQ 압축 벡터를 사용하여 그래프를 탐색하고 디스크 읽기 없이 후보 집합을 식별합니다. 그런 다음 해당 후보 집합에 대해 SSD에서 고정밀 벡터를 가져와 정확한 거리를 계산합니다. 이 두 단계 설계는 RAM 요구 사항을 낮게 유지하면서 높은 재현율을 유지하는 비결입니다.
FreshDiskANN 원래의 Vamana 구현은 정적 인덱스를 생성합니다. 마이크로소프트 리서치(Microsoft Research)에서 개발한 후속 기술인 FreshDiskANN은 DiskANN을 확장하여 전체 인덱스 재구축 없이도 동시적인 실시간 삽입, 삭제 및 업데이트를 지원합니다. 이 기술은 95% 이상의 리콜률을 유지하므로, 추천 시스템이나 실시간 문서 저장소와 같은 스트리밍 데이터셋에 실용적으로 적용할 수 있습니다.
DiskANN 대 HNSW 대 IVF
DiskANN, HNSW, IVF는 오늘날 프로덕션 환경에서 가장 주된 세 가지 ANN 인덱스 유형입니다.
| 디스크앤(바마나) | HNSW | 체외수정 | |
| 주기억장치 | SSD + 소형 RAM 캐시 | RAM (메모리 전체 색인) | RAM 또는 객체 스토리지 |
| 최대 실용 규모 | 수십억 개의 벡터 | 1억~2억 개의 벡터 (RAM 제한됨) | 수억 |
| 쿼리 지연 시간 | 낮음 (일반적으로 5-15 ms) | 매우 낮음(1-5 ms) | 중간 이하 |
| 메모리 사용량 | 낮음 (RAM에서 PQ 압축됨) | 높음 (DRAM 내 전체 벡터) | 중간 |
| 실시간 업데이트 | FreshDiskANN을 통해 | 기본 지원됨 | 비싼 (재구축) |
| 필터링된 검색 | 필터링된 DiskANN을 통해 | 후처리 필터링을 통해 | 강한형 (IVF 변형) |
| ~에 가장 좋은 | 비용 효율적인 하드웨어에서의 수십억 규모 RAG, 에이전트, 추천 시스템 | 초저지연이 필수적이고 RAM을 사용할 수 있는 소규모 데이터셋 | 필터 비율이 높은(>85%) 필터링 검색 |
데이터셋이 RAM에 모두 들어갈 경우(벡터 수 약 1억 개 미만), HNSW가 일반적으로 가장 낮은 지연 시간을 제공합니다. 벡터 수가 수억 개에 달하거나 RAM 비용이 제약 요인이 될 때는 DiskANN이 더 실용적인 선택입니다. 검색 전에 데이터셋 중 85%+가 필터링되는 워크로드의 경우, IVF 변형 모델이 두 방식 모두보다 더 우수한 성능을 보일 수 있습니다.
성능 및 벤치마크
원본 NeurIPS 2019 결과 (마이크로소프트 리서치): SIFT-1B 데이터셋(10억 개의 128차원 벡터)에서 DiskANN은 64GB RAM과 NVMe SSD를 탑재한 단일 시스템에서 95%+ recall@1 조건 하에 5,000 QPS를 달성했으며, 평균 지연 시간은 5ms 미만이었습니다. 이는 동등한 성능 조건에서 DRAM 기반 솔루션에 비해 시스템당 5~10배 더 많은 벡터를 처리할 수 있음을 의미합니다.
카우치베이스 하이퍼스케일 벡터 인덱스 벤치마크 (2025년 10월): Couchbase 8.0에 도입된 Couchbase의 Vamana/DiskANN 기반 하이스케일 벡터 인덱스는 10억 개의 벡터 데이터셋을 대상으로 VectorDBBench를 사용하여 독립적으로 벤치마크되었습니다:
- 초당 700+ 쿼리 93% 리콜 시 1초 미만의 지연 시간을 기록
- 350배 더 빠름 동일한 조건에서 89% 리콜 시 평균 지연 시간이 40초를 넘으며 2 QPS를 기록한 MongoDB Atlas보다
DiskANN 사용 사례
RAG 수십억 개의 문서 청크에 걸쳐 있는 엔터프라이즈 RAG 시스템은 RAM을 많이 사용하는 인프라 없이도 높은 재현율(recall)의 검색이 필요합니다. DiskANN은 프롬프트 콘텐츠를 예측할 수 없고 광범위한 의미론적 커버리지가 필수적인 워크로드에 매우 적합합니다.
AI 에이전트와 맥락적 기억: 에이전틱 시스템은 시간이 지남에 따라 상호작용 기록, 선호도, 작업 컨텍스트를 벡터로 축적합니다. DiskANN을 사용하면 에이전트는 RAM이 병목 현상이 되지 않으면서 무한정 커지는 메모리 코퍼스를 검색할 수 있습니다.
의미 기반 검색 및 추천: 수억에서 수십억 개의 아이템을 대상으로 운영되는 전자상거래, 미디어, 엔터프라이즈 검색 플랫폼은 DiskANN의 처리량과 재현율 정확도로부터 이점을 얻으며, 특히 Filtered-DiskANN을 통한 메타데이터 사전 필터링과 결합될 때 더욱 그렇습니다.
개인정보 보호 우선 및 온프레미스 AI: 데이터가 통제된 환경 밖으로 나갈 수 없을 때, 로컬 SSD 하드웨어에서 실행되는 DiskANN의 능력은 프라이버시 보호 생성형 AI 애플리케이션 클라우드 호스팅 및 대규모 RAM 집약적 클러스터가 필요한 접근 방식보다 더 실용적입니다.
데이터베이스와 플랫폼의 DiskANN
카우치베이스 하이퍼스케일 벡터 인덱스: 카우치베이스 8.0은 Vamana + IVF 하이브리드 구현 방식인 하이버스케일 벡터 인덱스(HVI)를 도입했으며, 이는 다음에서 사용할 수 있습니다. 카우치베이스 카펠라 그리고 자체 관리형 배포를 지원합니다. 분산 처리를 위해 파티션된 디스크 전반에서 작동하며, 광범위한 시맨틱 커버리지가 필요한 RAG 워크로드용으로 특별히 설계되었습니다.
마이크로소프트의 Azure Cosmos DB 및 PostgreSQL용 Azure Database: Azure Cosmos DB는 NoSQL API에서 벡터 검색을 구동하기 위해 DiskANN을 사용합니다. Azure Database for PostgreSQL은 pgvector의 HNSW 및 IVFFlat에 대한 Vamana 기반 대안으로 이를 제공합니다.
밀버스(Milvus)와 질리즈(Zilliz): Milvus는 디스크 기반의 Vamana 그래프와 RAM의 PQ 압축 벡터를 사용하여 십억 단위 규모의 컬렉션을 위해 DiskANN을 디스크 내 인덱스 타입(DISKANN)으로 지원하는 오픈 소스 벡터 데이터베이스입니다. Zilliz Cloud는 Milvus의 완전 관리형 엔터프라이즈 버전입니다.
pgvectorscale (타임스케일디비): pgvectorscale은 Timescale이 개발한 PostgreSQL 확장 기능으로, StreamingDiskANN을 구현합니다. 지속적으로 업데이트되는 시계열 및 스트리밍 데이터셋에 최적화되어 있습니다.
DiskANN 튜닝 방법
DiskANN의 핵심 매개변수는 재현율 지연 시간과 처리량 간의 절충 관계를 제어합니다.
- 최대 차수: 그래프 노드당 최대 아웃엣지 수. 값이 높을수록 재현율은 향상되지만 인덱스 크기와 SSD 읽기가 증가합니다. 기본값: 56.
- 검색목록크기: 검색 중 후보 목록 크기. 높은 재현율이 요구되는 작업(RAG, 에이전트 메모리)의 경우 150-200으로 늘리고, 최대 처리량을 위해서는 100으로 유지하세요. 기본값: 100.
- PQ코드예산GB비율: RAM 용량이 허용되고 지연 시간이 매우 중요한 경우 0.2로 늘리십시오. 기본값: 0.125.
- 빔너비비율: 쿼리 단계별 병렬 SSD 읽기. 고처리량 워크로드에서 QPS를 극대화하려면 상향 조정(6.0-8.0)하세요. 기본값: 4.0.
하드웨어 사이징의 경우, 10억 개의 128차원 float32 데이터셋을 위해 약 750GB~1TB의 NVMe SSD(전체 정밀도 벡터용 512GB + 그래프 에지용 약 224GB)와 PQ 캐시용 64~128GB의 RAM을 예산으로 잡으세요. DiskANN은 CPU 바운드(CPU-bound)가 아니며, 대부분의 배포 환경에서는 8~16코어로 충분합니다.
주요 내용
DiskANN addresses the fundamental economic problem of in-memory ANN indexing by using inexpensive SSDs rather than expensive RAM. By combining the Vamana graph construction algorithm with product quantization, it achieves recall and latency competitive with in-memory approaches at a fraction of the infrastructure cost.
- DiskANN is a graph-based ANN algorithm from Microsoft Research (NeurIPS 2019) that is built on the Vamana directed graph construction algorithm.
- It stores the full index and full-precision vectors on SSD, caching only PQ-compressed vectors in RAM for fast approximate routing.
- It indexes 1B+ vectors on a single machine with 64GB RAM, achieving 95%+ recall@1 with sub-5 ms latency on the SIFT-1B benchmark.
- DiskANN indexes 5-10x more vectors per machine than DRAM-only algorithms at equivalent latency, directly reducing infrastructure cost.
- It’s the right choice when datasets exceed 100-200M vectors or when RAM cost is a constraint. HNSW is preferable for smaller latency-critical workloads.
- FreshDiskANN extends DiskANN to support real-time inserts, deletes, and updates without full index rebuilds.
- Couchbase’s Hyperscale Vector Index delivers 700+ QPS at 93% recall at billion-vector scale. This is 350x faster than MongoDB Atlas in independent VectorDBBench testing.
Related resources
- 카우치베이스 8.0: 하이퍼스케일 AI 애플리케이션을 위한 통합 데이터 플랫폼
- Vector Search Using Hyperscale Vector Indexes
- AI Services in Capella
- Vector Search Database
- How I Built a Plant RAG Application With Couchbase Vector Search on iOS
- Artificial Intelligence (AI) Use Cases
자주 묻는 질문
What is the Vamana algorithm, and how does it differ from HNSW? Vamana builds a single-layer directed graph, while HNSW builds a multi-layer hierarchy. HNSW’s structure requires the entire index to be in RAM for efficient pointer traversal. Vamana’s single-layer design, with explicit long-range edges added during construction, enables the same fast navigation from disk without the RAM dependency.
How does product quantization work in DiskANN, and why is it necessary? PQ compresses each vector into a compact code (typically 16-32x smaller) by dividing it into sub-vectors and mapping each to a learned centroid. DiskANN stores these codes in RAM for fast approximate routing, then fetches full-precision vectors from SSD only for final reranking, keeping the in-memory footprint tractable even at billion-vector scale.
What are DiskANN’s limitations, and when is it not the best choice? DiskANN is less suitable for small datasets (under ~10M vectors), where HNSW offers lower latency with less overhead. It’s also less suitable for workloads with very high filter ratios (85-98%), where IVF variants outperform graph-based indexes. Query latency is also highly sensitive to disk speed, and SATA SSDs will significantly underperform NVMe.
How do I estimate hardware requirements for a DiskANN deployment? For a 1B 128-dimensional float32 dataset, budget roughly 750GB-1TB of NVMe SSD (512GB for vectors plus ~224GB for graph edges) and 64-128GB of RAM for the PQ cache. DiskANN is I/O-bound rather than CPU-bound, so 8-16 cores are sufficient for most production deployments.Which databases support DiskANN? DiskANN is available in Couchbase 8.0 (Hyperscale Vector Index, benchmarked at 700+ QPS at billion-vector scale), Azure Cosmos DB, Azure Database for PostgreSQL, Milvus/Zilliz Cloud, and TimescaleDB’s pgvectorscale. Microsoft also uses DiskANN in Bing and Microsoft 365, making it the most widely deployed billion-scale vector search algorithm in enterprise infrastructure today.
댓글 남기기
댓글을 달기 위해서는 로그인해야합니다.