블로그
Milvus Sizing Tool 이해하기

Milvus Sizing Tool 이해하기

Apr 10, 20255 min read

소개

Milvus 배포에 최적의 구성을 선택하는 것은 성능 최적화, 효율적인 리소스 활용, 비용 관리에 매우 중요합니다. 프로토타입을 구축하든 프로덕션 배포를 계획하든, Milvus 인스턴스의 크기를 적절히 산정하는 것은 원활하게 실행되는 벡터 데이터베이스와 성능 문제를 겪거나 불필요한 비용이 발생하는 데이터베이스를 가르는 차이가 될 수 있습니다.

이 과정을 단순화하기 위해, 특정 요구 사항을 기반으로 권장 리소스 추정치를 생성하는 사용자 친화적인 계산기인 Milvus Sizing Tool을 개편했습니다. 이 가이드에서는 이 도구를 사용하는 방법을 안내하고 Milvus 성능에 영향을 미치는 요소에 대해 더 깊이 있는 인사이트를 제공합니다.

Milvus Sizing Tool 사용 방법

이 sizing tool은 사용하기 매우 쉽습니다. 다음 단계를 따르기만 하면 됩니다.

Milvus Sizing Tool 페이지를 방문합니다.
주요 매개변수를 입력합니다:
- 벡터 수 및 벡터당 차원 수
- 인덱스 유형
- 스칼라 필드 데이터 크기
- 세그먼트 크기
- 선호하는 배포 모드
생성된 리소스 권장 사항을 검토합니다

milvus sizing tool

이제 이러한 각 매개변수가 Milvus 배포에 어떤 영향을 미치는지 살펴보겠습니다.

인덱스 선택: 스토리지, 비용, 정확도, 속도의 균형 맞추기

Milvus는 HNSW, FLAT, IVF_FLAT, IVF_SQ8, ScaNN, DiskANN 등 다양한 인덱스 알고리즘을 제공하며, 각각 메모리 사용량, 디스크 공간 요구 사항, 쿼리 속도, 검색 정확도 측면에서 고유한 트레이드오프를 가집니다.

가장 일반적인 옵션에 대해 알아야 할 사항은 다음과 같습니다:

index index

HNSW (Hierarchical Navigable Small World)

아키텍처: 스킵 리스트와 Navigable Small Worlds (NSWs) 그래프를 계층 구조로 결합합니다
성능: 뛰어난 recall 비율로 매우 빠른 쿼리를 제공합니다
리소스 사용량: 벡터당 가장 많은 메모리를 필요로 합니다(가장 높은 비용)
적합한 경우: 속도와 정확도가 중요하고 메모리 제약이 상대적으로 덜 중요한 애플리케이션
기술 참고: 검색은 노드 수가 가장 적은 최상위 계층에서 시작하여 점점 더 조밀한 계층을 따라 아래로 이동합니다

FLAT

아키텍처: 근사 없이 단순한 완전 탐색을 수행합니다
성능: 100% recall을 제공하지만 쿼리 시간이 매우 느립니다(데이터 크기 n에 대해 O(n))
리소스 사용량: 인덱스 크기는 원시 벡터 데이터 크기와 같습니다
적합한 경우: 완벽한 recall이 필요한 소규모 데이터셋 또는 애플리케이션
기술 참고: 쿼리 벡터와 데이터베이스의 모든 벡터 간 전체 거리 계산을 수행합니다

IVF_FLAT

아키텍처: 더 효율적인 검색을 위해 벡터 공간을 클러스터로 나눕니다
성능: 중상 수준의 recall과 보통 수준의 쿼리 속도를 제공합니다(HNSW보다 느리지만 FLAT보다 빠름)
리소스 사용량: FLAT보다 적은 메모리를 필요로 하지만 HNSW보다는 많습니다
적합한 경우: 일부 recall을 더 나은 성능과 맞바꿀 수 있는 균형형 애플리케이션
기술 참고: 검색 중에는 nlist 클러스터만 검사하므로 계산량이 크게 줄어듭니다

IVF_SQ8

아키텍처: IVF_FLAT에 스칼라 양자화를 적용하여 벡터 데이터를 압축합니다
성능: 중간 수준의 recall과 중상 수준의 쿼리 속도를 제공합니다
리소스 사용량: IVF_FLAT과 비교해 디스크, 컴퓨트, 메모리 소비를 70-75% 줄입니다
적합한 경우: 정확도를 약간 타협할 수 있는 리소스 제약 환경
기술 참고: 32비트 부동소수점 값을 8비트 정수 값으로 압축합니다

고급 인덱스 옵션: ScaNN, DiskANN, CAGRA 등

ScaNN: 유사한 재현율로 CPU에서 HNSW보다 20% 더 빠름
DiskANN: 높은 재현율로 대량의 벡터를 지원해야 하며 약간 더 긴 지연 시간(~100ms)을 허용할 수 있을 때 이상적인 하이브리드 디스크/메모리 인덱스입니다. 인덱스의 일부만 메모리에 유지하고 나머지는 디스크에 두어 메모리 사용량과 성능의 균형을 맞춥니다.
GPU 기반 인덱스:
- GPU_CAGRA: GPU 인덱스 중 가장 빠르지만, HBM 메모리가 있는 카드가 아니라 GDDR 메모리가 있는 추론 카드가 필요합니다
- GPU_BRUTE_FORCE: GPU에서 구현된 완전 탐색
- GPU_IVF_FLAT: GPU 가속 버전의 IVF_FLAT
- GPU_IVF_PQ: Product Quantization을 사용하는 IVF의 GPU 가속 버전
HNSW-PQ/SQ/PRQ:
- HNSW_SQ: 매우 빠른 쿼리, 제한된 메모리 리소스; 재현율에서 약간의 절충을 허용합니다.
- HNSW_PQ: 중간 속도 쿼리; 매우 제한된 메모리 리소스; 재현율에서 약간의 절충을 허용합니다
- HNSW_PRQ: 중간 속도 쿼리; 매우 제한된 메모리 리소스; 재현율에서 약간의 절충을 허용합니다
- AUTOINDEX: 오픈 소스 Milvus에서는 기본적으로 HNSW를 사용합니다(또는 관리형 Milvus인 Zilliz Cloud에서는 더 높은 성능의 독점 인덱스를 사용합니다).
Binary, Sparse 및 기타 특수 인덱스: 특정 데이터 유형과 사용 사례를 위한 것입니다. 자세한 내용은 이 인덱스 문서 페이지를 참조하세요.

세그먼트 크기 및 배포 구성

세그먼트는 Milvus 내부 데이터 조직의 기본 구성 요소입니다. 세그먼트는 배포 전반에 걸친 분산 검색과 로드 밸런싱을 가능하게 하는 데이터 청크로 기능합니다. 이 Milvus 사이징 도구는 세 가지 세그먼트 크기 옵션(512 MB, 1024 MB, 2048 MB)을 제공하며, 기본값은 1024 MB입니다.

성능 최적화를 위해서는 세그먼트를 이해하는 것이 중요합니다. 일반적인 지침은 다음과 같습니다:

512 MB 세그먼트: 4-8 GB 메모리의 쿼리 노드에 가장 적합
1 GB 세그먼트: 8-16 GB 메모리의 쿼리 노드에 최적
2 GB 세그먼트: >16 GB 메모리의 쿼리 노드에 권장

개발자 인사이트: 더 적고 더 큰 세그먼트는 일반적으로 더 빠른 검색 성능을 제공합니다. 대규모 배포의 경우, 2 GB 세그먼트가 메모리 효율성과 쿼리 속도 간의 최상의 균형을 제공하는 경우가 많습니다.

메시지 큐 시스템 선택

메시징 시스템으로 Pulsar와 Kafka 중 선택할 때:

Pulsar: 토픽당 오버헤드가 낮고 확장성이 더 좋아 신규 프로젝트에 권장됩니다
Kafka: 조직 내에 이미 Kafka 전문 지식이나 인프라가 있는 경우 선호될 수 있습니다

Zilliz Cloud의 엔터프라이즈 최적화

엄격한 성능 요구 사항이 있는 프로덕션 배포의 경우, Zilliz Cloud(클라우드에서 제공되는 Milvus의 완전 관리형 엔터프라이즈 버전)는 인덱싱 및 양자화에서 추가 최적화를 제공합니다:

Out of Memory (OOM) 방지: 메모리 부족 충돌을 방지하기 위한 정교한 메모리 관리
압축 최적화: 검색 성능 및 리소스 활용도를 개선합니다
계층형 스토리지: 적절한 컴퓨팅 유닛으로 핫 데이터와 콜드 데이터를 효율적으로 관리합니다
- 자주 액세스되는 데이터를 위한 표준 컴퓨팅 유닛(CU)
- 거의 액세스되지 않는 데이터를 비용 효율적으로 저장하기 위한 계층형 스토리지 CU

자세한 엔터프라이즈 사이징 옵션은 Zilliz Cloud 서비스 플랜 문서를 방문하세요.

개발자를 위한 고급 구성 팁

여러 인덱스 유형: 사이징 도구는 단일 인덱스에 초점을 맞춥니다. 다양한 컬렉션에 서로 다른 인덱스 알고리즘이 필요한 복잡한 애플리케이션의 경우, 사용자 지정 구성으로 별도의 컬렉션을 만드세요.
메모리 할당: 배포를 계획할 때 벡터 데이터와 인덱스 메모리 요구 사항을 모두 고려하세요. HNSW는 일반적으로 원시 벡터 데이터 메모리의 2-3배가 필요합니다.
성능 테스트: 구성을 최종 확정하기 전에, 대표 데이터셋에서 특정 쿼리 패턴을 벤치마크하세요.
확장 고려 사항: 향후 성장을 고려하세요. 나중에 재구성하는 것보다 약간 더 많은 리소스로 시작하는 것이 더 쉽습니다.

결론

Milvus Sizing Tool은 리소스 계획을 위한 훌륭한 출발점을 제공하지만, 모든 애플리케이션에는 고유한 요구 사항이 있다는 점을 기억하세요. 최적의 성능을 위해서는 특정 워크로드 특성, 쿼리 패턴 및 확장 요구 사항을 기반으로 구성을 세밀하게 조정하는 것이 좋습니다.

저희는 사용자 피드백을 바탕으로 도구와 문서를 지속적으로 개선하고 있습니다. Milvus 배포 규모 산정과 관련해 질문이 있거나 추가 지원이 필요하다면 GitHub 또는 Discord의 커뮤니티에 문의하세요.

참고 자료

Jul 13, 2026에 업데이트됨

계속 읽기

Vector Databases vs. Object-Relational Databases

Use a vector database for AI-powered similarity search; use an object-relational database for complex data modeling with both relational integrity and object-oriented features.

Milvus WebUI: A Visual Management Tool for Your Vector Database

Explore Milvus WebUI to monitor, manage, and optimize your vector database with real-time insights, performance tracking, and system health monitoring.

Selecting the Right ETL Tools for Unstructured Data to Prepare for AI

Learn the right ETL tools for unstructured data to power AI. Explore key challenges, tool comparisons, and integrations with Milvus for vector search.