vectorDB-Bench를 사용하는 milvus 독립 실행형 클러스터에 대해 다음과 같은 성능 검증을 수행했습니다.
milvus 독립 실행형 클러스터의 네트워크 및 서버 연결은 다음과 같습니다.

이 섹션에서는 Milvus 독립 실행형 데이터베이스 테스트의 관찰 결과 및 결과를 공유합니다.
. 이러한 테스트의 인덱스 유형으로 DiskANN을 선택했습니다.
. 약 100GB의 데이터 세트에 대한 인덱스를 수집, 최적화 및 생성하는 데 약 5시간이 걸렸습니다. 대부분의 기간 동안 20개의 코어(하이퍼 스레딩을 사용할 경우 40개의 vCPU와 동일)를 장착한 Milvus 서버는 최대 CPU 용량인 100%에서 작동하고 있었습니다. DiskANN은 특히 시스템 메모리 크기를 초과하는 대규모 데이터세트에 매우 중요합니다.
. 조회 단계에서 0.9987을 리콜한 상태에서 QPS(Queries per second)가 10.93인 것을 확인했습니다. 쿼리의 99번째 백분위수 지연 시간은 708.2밀리초로 측정되었습니다.

스토리지 관점에서 볼 때 데이터베이스는 수집, 삽입 후 최적화, 인덱스 생성 단계에서 약 1,000 ops/sec를 기록했습니다. 쿼리 단계에서는 32,000 ops/초가 필요했습니다

다음 섹션에서는 스토리지 성능 메트릭에 대해 설명합니다.

vectorDB-bench 결과는 다음과 같습니다.

독립 실행형 Milvus 인스턴스의 성능 검증을 통해 현재 설정이 치수 1536의 5백만 벡터로 구성된 데이터 세트를 지원하기에는 불충분하다는 것을 알 수 있습니다. 스토리지에 적절한 리소스가 있으며 시스템에 병목 현상이 발생하지 않는 것으로 확인되었습니다.

이 섹션에서는 Kubernetes 환경 내에 Milvus 클러스터를 구축하는 방법에 대해 설명합니다. 이 Kubernetes 설정은 Kubernetes 마스터 및 작업자 노드를 호스팅하는 VMware vSphere 배포를 바탕으로 구성되었습니다.

VMware vSphere 및 Kubernetes 구축에 대한 자세한 내용은 다음 섹션에서 설명합니다.

이 섹션에서는 Milvus 데이터베이스 테스트에서 얻은 관찰 내용과 결과를 설명합니다.
*사용된 인덱스 유형은 DiskANN입니다.
*아래 표는 1536의 치수에서 5백만 벡터로 작업할 때 독립형 배포와 클러스터 배포를 비교한 것입니다. 우리는 데이터 수집 및 삽입 후 최적화에 걸리는 시간이 클러스터 구축에서 더 낮은 것으로 확인되었습니다. 독립 실행형 설정에 비해 클러스터 구축 시 쿼리의 99번째 백분위수 지연 시간이 6배 감소했습니다.
*클러스터 배포에서 QPS(Queries per Second) 비율이 높았지만 원하는 수준에서는 그렇지 않았습니다.

아래 이미지는 스토리지 클러스터 지연 시간 및 총 IOPS(초당 입출력 작업 수)를 포함한 다양한 스토리지 메트릭을 보여 줍니다.

다음 섹션에서는 주요 스토리지 성능 메트릭에 대해 설명합니다.

독립 실행형 Milvus 및 Milvus 클러스터의 성능 검증을 토대로 스토리지 I/O 프로필에 대한 세부 정보를 제공합니다.
* 독립 실행형 및 클러스터 구축 모두에서 I/O 프로필이 일관되게 유지되는 것을 확인했습니다.
* 피크 IOPS에서 관찰된 차이는 클러스터 구축 시 클라이언트 수가 많기 때문입니다.

VectorDB-Bench를 사용하여 PostgreSQL(pgvecto.rs)에 대해 다음 작업을 수행했습니다.
PostgreSQL(특히 pgvecto.rs)의 네트워크 및 서버 연결에 대한 세부 정보는 다음과 같습니다.

이 섹션에서는 특히 pgvecto.rs를 사용하여 PostgreSQL 데이터베이스를 테스트한 결과 및 관찰 결과를 공유합니다.
* 테스트 당시 DiskANN은 pgvecto.RS에 사용할 수 없었기 때문에 이러한 테스트의 인덱스 유형으로 HNSW를 선택했습니다.
* 데이터 수집 단계 동안, 우리는 768의 치수에서 천만 벡터로 구성된 COHERE 데이터세트를 로드했습니다. 이 과정은 약 4.5시간이 걸렸습니다.
* 쿼리 단계에서 0.6344를 리콜하여 1,068의 QPS(Queries per Second)를 확인했습니다. 쿼리의 99번째 백분위수 지연 시간은 20밀리초로 측정되었습니다. 대부분의 런타임 동안 클라이언트 CPU는 100% 용량으로 작동했습니다.

아래 이미지는 스토리지 클러스터 지연 시간 총 IOPS(초당 입출력 작업 수)를 포함한 다양한 스토리지 메트릭을 보여 줍니다.

VectorDBBench를 사용한 Milvus 및 PostgreSQL의 성능 검증을 토대로 다음과 같은 점을 관찰했습니다.

우리는 pgvecto.RS가 0.6344의 리콜로 1,068의 QPS(Queries per Second)를 달성했으며, Milvus는 0.9842의 리콜로 106의 QPS 속도를 달성했습니다.

쿼리의 높은 정밀도가 우선 순위인 경우 Milvus는 쿼리당 관련 항목의 비율이 더 높기 때문에 pgvecto.rs보다 성능이 뛰어납니다. 그러나 초당 쿼리 수가 더 중요한 요소인 경우 pgvecto.RS는 Milvus를 초과합니다. 하지만 pgvecto.rs를 통해 검색된 데이터의 품질이 낮고 검색 결과의 약 37%가 관련 없는 항목이라는 점을 유의해야 합니다.

성능 검증을 토대로 다음과 같이 관찰했습니다.

Milvus의 I/O 프로필은 Oracle SLOB에서 볼 수 있는 OLTP 워크로드와 비슷합니다. 벤치마크는 데이터 수집, 사후 최적화 및 쿼리의 세 단계로 구성됩니다. 초기 단계는 주로 64KB 쓰기 작업이 특징이며, 쿼리 단계에는 대개 8KB 읽기가 포함됩니다. ONTAP는 Milvus I/O 로드를 능숙하게 처리할 것으로 기대하고 있습니다.

PostgreSQL 입출력 프로파일은 까다로운 스토리지 워크로드를 제공하지 않습니다. 현재 인메모리 구현이 진행 중이라는 점을 감안할 때 쿼리 단계에서 디스크 입출력을 관찰하지 못했습니다.

DiskANN은 스토리지 차별화를 위한 중요한 기술로 등장했습니다. 시스템 메모리 경계를 넘어 벡터 DB 검색의 효율적인 확장을 지원합니다. 그러나 HNSW와 같은 인메모리 벡터 DB 인덱스와 스토리지 성능 차이를 구별할 가능성은 거의 없습니다.

또한 인덱스 유형이 RAG 애플리케이션을 지원하는 벡터 데이터베이스의 가장 중요한 작동 단계인 HSNW인 경우 쿼리 단계에서 스토리지가 중요한 역할을 수행하지 않는다는 점도 주목할 필요가 있습니다. 여기서 중요한 점은 스토리지 성능이 이러한 애플리케이션의 전체 성능에 크게 영향을 미치지 않는다는 것입니다.