성능 FAQ
IVF 인덱스에 nlist 및 nprobe 을 설정하는 방법은 무엇인가요?
nlist 설정은 시나리오에 따라 다릅니다. 일반적으로 nlist 의 권장 값은 4 × sqrt(n) 이며, 여기서 n 는 세그먼트의 총 엔티티 수입니다.
각 세그먼트의 크기는 datacoord.segment.maxSize 매개변수에 의해 결정되며, 기본적으로 512MB로 설정되어 있습니다. 세그먼트 n의 총 엔티티 수는 datacoord.segment.maxSize 을 각 엔티티의 크기로 나누면 추정할 수 있습니다.
nprobe 설정은 데이터 세트 및 시나리오에 따라 다르며 정확도와 쿼리 성능 간의 절충이 필요합니다. 반복적인 실험을 통해 이상적인 값을 찾는 것이 좋습니다.
다음 차트는 서로 다른 nlist/nprobe 쌍의 리콜 및 쿼리 성능을 비교하는 sift50m 데이터 세트와 IVF_SQ8 인덱스에서 실행한 테스트의 결과입니다.
정확도 테스트 
성능 테스트
작은 데이터 세트에서 쿼리 시간이 더 오래 걸리는 이유는 무엇인가요?
쿼리 작업은 세그먼트에서 수행됩니다. 인덱스는 세그먼트를 쿼리하는 데 걸리는 시간을 줄여줍니다. 세그먼트가 인덱싱되지 않은 경우, Milvus는 원시 데이터에 대한 무차별 검색을 사용하므로 쿼리 시간이 크게 늘어납니다.
따라서 일반적으로 인덱스를 구축하지 않았기 때문에 작은 데이터 세트(컬렉션)에 대한 쿼리 시간이 더 오래 걸립니다. 이는 세그먼트의 크기가 rootCoord.minSegmentSizeToEnableindex 에서 설정한 인덱스 구축 임계값에 도달하지 않았기 때문입니다. create_index() 을 호출하여 임계값에 도달했지만 아직 자동으로 색인되지 않은 세그먼트를 강제로 색인하면 쿼리 성능이 크게 향상됩니다.
CPU 사용량에 영향을 미치는 요인은 무엇인가요?
Milvus가 인덱스를 구축하거나 쿼리를 실행할 때 CPU 사용량이 증가합니다. 일반적으로 인덱스 구축은 단일 스레드에서 실행되는 Annoy를 사용하는 경우를 제외하고는 CPU 집약적입니다.
쿼리를 실행할 때 CPU 사용량은 nq 와 nprobe 에 의해 영향을 받습니다. nq 과 nprobe 이 작으면 동시성이 낮고 CPU 사용량이 낮게 유지됩니다.
데이터 삽입과 검색을 동시에 수행하면 쿼리 성능에 영향을 주나요?
삽입 작업은 CPU를 많이 사용하지 않습니다. 그러나 새 세그먼트가 인덱스 구축 임계값에 도달하지 않았을 수 있기 때문에 Milvus는 무차별 대입 검색을 사용하므로 쿼리 성능에 상당한 영향을 미칩니다.
rootcoord.minSegmentSizeToEnableIndex 매개변수는 세그먼트의 인덱스 구축 임계값을 결정하며, 기본적으로 1024행으로 설정되어 있습니다. 자세한 내용은 시스템 구성을 참조하세요.
Milvus에서 데이터를 삭제한 후 저장 공간이 바로 해제되나요?
아니요, Milvus에서 데이터를 삭제하면 저장 공간이 즉시 해제되지 않습니다. 데이터를 삭제하면 엔티티가 '논리적으로 삭제됨'으로 표시되지만 실제 공간은 즉시 해제되지 않을 수 있습니다. 그 이유는 다음과 같습니다:
- 압축: Milvus는 백그라운드에서 데이터를 자동으로 압축합니다. 이 프로세스는 작은 데이터 세그먼트를 큰 데이터 세그먼트로 병합하고 논리적으로 삭제된 데이터(삭제 표시된 엔티티) 또는 TTL(Time-To-Live)을 초과한 데이터를 제거합니다. 그러나 압축은 새로운 세그먼트를 생성하는 동시에 이전 세그먼트를 "삭제됨"으로 표시합니다.
- 가비지 컬렉션: 가비지 컬렉션(GC)이라는 별도의 프로세스가 주기적으로 이러한 '삭제된' 세그먼트를 제거하여 해당 세그먼트가 차지하고 있던 스토리지 공간을 확보합니다. 이렇게 하면 저장 공간을 효율적으로 사용할 수 있지만 삭제와 공간 확보 사이에 약간의 지연이 발생할 수 있습니다.
플러시를 기다리지 않고 작업 후 즉시 삽입, 삭제 또는 업서트된 데이터를 볼 수 있나요?
예. Milvus에서는 스토리지-컴퓨팅 분리 아키텍처로 인해 데이터 가시성이 플러시 작업과 직접적으로 연결되지 않습니다. 일관성 수준을 사용하여 데이터 가독성을 관리할 수 있습니다.
일관성 수준을 선택할 때는 일관성과 성능 간의 장단점을 고려하세요. 즉각적인 가시성이 필요한 작업의 경우 '강력' 일관성 수준을 사용하세요. 더 빠른 쓰기를 원한다면 약한 일관성(데이터가 즉시 표시되지 않을 수 있음)을 우선순위로 정하세요. 자세한 내용은 일관성을 참조하세요.
VARCHAR 필드를 색인하면 삭제 속도가 향상되나요?
예. VARCHAR 필드를 색인하면 '표현식으로 삭제' 작업 속도를 높일 수 있지만 특정 조건에서만 가능합니다:
- 반전 인덱스: 이 인덱스는 기본 키가 아닌 VARCHAR 필드에 있는
IN또는==표현식에 도움이 됩니다. - 트라이 인덱스: 이 인덱스는 주 키가 아닌 VARCHAR 필드에 대한 접두사 쿼리(예:
LIKE prefix%)에 도움이 됩니다.
그러나 VARCHAR 필드를 색인해도 속도가 빨라지지는 않습니다:
- ID로 삭제합니다: VARCHAR 필드가 기본 키인 경우.
- 관련 없는 표현식: VARCHAR 필드가 삭제 표현식에 포함되지 않은 경우.
아직 질문이 있으신가요?
그럴 수 있습니다:
