Milvus
Zilliz
홈페이지
  • 사용자 가이드
  • Home
  • Docs
  • 사용자 가이드

  • 스토리지 최적화

  • 계층형 스토리지

  • 퇴거

EvictionCompatible with Milvus 2.6.4+

퇴거는 Milvus에서 각 쿼리 노드의 캐시 리소스를 관리합니다. 이 기능을 활성화하면 리소스 임계값에 도달하면 캐시된 데이터를 자동으로 제거하여 안정적인 성능을 보장하고 메모리 또는 디스크 고갈을 방지합니다.

퇴거는 최근 사용량(LRU) 정책을 사용해 캐시 공간을 회수합니다. 메타데이터는 쿼리 계획에 필수적이며 일반적으로 크기가 작기 때문에 항상 캐시되고 퇴거되지 않습니다.

퇴거는 명시적으로 활성화해야 합니다. 구성하지 않으면 리소스가 고갈될 때까지 캐시된 데이터가 계속 누적됩니다.

퇴거 유형

Milvus는 최적의 리소스 관리를 위해 함께 작동하는 두 가지 상호 보완적인 퇴출 모드(동기화비동기화)를 지원합니다:

측면

동기식 퇴거

비동기 퇴거

Trigger

쿼리 또는 검색 중에 메모리 또는 디스크 사용량이 내부 한도를 초과할 때 발생합니다.

사용량이 워터마크 상한을 초과하거나 캐시된 데이터가 TTL(Time-to-Live)에 도달하면 백그라운드 스레드에 의해 트리거됩니다.

동작

쿼리 노드가 캐시 공간을 회수하는 동안 쿼리 또는 검색 작업이 일시적으로 일시 중지됩니다. 사용량이 낮은 워터마크 아래로 떨어지거나 타임아웃이 발생할 때까지 퇴거가 계속됩니다. 타임아웃에 도달하여 회수할 수 있는 데이터가 충분하지 않은 경우 쿼리 또는 검색이 실패할 수 있습니다.

백그라운드에서 주기적으로 실행되며, 사용량이 하이 워터마크를 초과하거나 TTL에 따라 데이터가 만료되면 캐시된 데이터를 선제적으로 제거합니다. 사용량이 낮은 워터마크 아래로 떨어질 때까지 퇴거가 계속됩니다. 쿼리는 차단되지 않습니다.

최적의 대상

사용량이 급증하는 동안 잠깐의 지연 시간 급증 또는 일시적인 일시 중지를 견딜 수 있는 워크로드. 비동기 퇴거로 공간을 충분히 빨리 확보할 수 없을 때 유용합니다.

원활하고 예측 가능한 쿼리 성능이 필요한 지연 시간에 민감한 워크로드. 사전 예방적 리소스 관리에 이상적입니다.

주의 사항

퇴거 가능한 데이터가 충분하지 않은 경우 짧은 쿼리 지연 또는 시간 초과가 발생할 수 있습니다.

적절하게 조정된 하이/로우 워터마크 및 TTL 설정이 필요합니다. 백그라운드 스레드에서 약간의 오버헤드가 발생합니다.

설정

다음을 통해 활성화 evictionEnabled: true

backgroundEvictionEnabled: true 을 통해 활성화(동시에 evictionEnabled: true 필요)

권장 설정:

  • 워크로드가 계층형 스토리지의 이점을 누리고 퇴거 관련 가져오기 지연 시간을 견딜 수 있다면 최적의 균형을 위해 두 퇴거 모드를 함께 사용하도록 설정할 수 있습니다.

  • 성능 테스트 또는 지연 시간이 중요한 시나리오의 경우, 퇴거 후 네트워크 가져오기 오버헤드를 피하기 위해 퇴거를 완전히 비활성화하는 것을 고려하세요.

퇴거 가능한 필드 및 인덱스의 경우, 퇴거 단위는 로딩 단위와 일치합니다(스칼라/벡터 필드는 청크별로 퇴거되고, 스칼라/벡터 인덱스는 세그먼트별로 퇴거됩니다).

퇴출 활성화

milvus.yaml 에서 queryNode.segcore.tieredStorage 에서 퇴거를 구성합니다:

queryNode:
  segcore:
    tieredStorage:
      evictionEnabled: true             # Enables synchronous eviction
      backgroundEvictionEnabled: true   # Enables background (asynchronous) eviction

파라미터

유형

설명

권장 사용 사례

evictionEnabled

bool

true/false

퇴거 전략을 위한 마스터 스위치입니다. 기본값은 false. 동기화 퇴거 모드를 활성화합니다.

계층형 스토리지에서는 항상 true 로 설정합니다.

backgroundEvictionEnabled

bool

true/false

백그라운드에서 비동기적으로 퇴거를 실행합니다. evictionEnabled: true 가 필요합니다. 기본값은 false 입니다.

보다 원활한 쿼리 성능을 위해 true 을 사용하면 동기화 퇴거 빈도가 줄어듭니다.

워터마크 구성

워터마크는 메모리와 디스크 모두에 대해 캐시 제거가 시작되고 종료되는 시점을 정의합니다. 각 리소스 유형에는 두 가지 임계값이 있습니다:

  • 높은 워터마크: 사용량이 이 값을 초과하면 퇴거가 시작됩니다.

  • 낮은 워터마크: 사용량이 이 값 아래로 떨어질 때까지 퇴거가 계속됩니다.

이 구성은 퇴거가 활성화된 경우에만 적용됩니다.

예시 YAML:

queryNode:
  segcore:
    tieredStorage:
      # Memory watermarks
      memoryLowWatermarkRatio: 0.75    # Eviction stops below 75% memory usage
      memoryHighWatermarkRatio: 0.8    # Eviction starts above 80% memory usage

      # Disk watermarks
      diskLowWatermarkRatio: 0.75      # Eviction stops below 75% disk usage
      diskHighWatermarkRatio: 0.8      # Eviction starts above 80% disk usage

파라미터

유형

범위

설명

권장 사용 사례

memoryLowWatermarkRatio

float

(0.0, 1.0]

퇴거가 중지되는 메모리 사용량 수준입니다.

0.75 에서 시작합니다. 쿼리 노드 메모리가 제한되어 있으면 약간 낮춥니다.

memoryHighWatermarkRatio

float

(0.0, 1.0]

비동기 퇴거가 시작되는 메모리 사용량 수준.

0.8 에서 시작합니다. 빈번한 트리거를 방지하기 위해 낮은 워터마크(예: 0.05-0.10)와 적당한 간격을 유지합니다.

diskLowWatermarkRatio

float

(0.0, 1.0]

퇴거가 중지되는 디스크 사용량 수준.

0.75 에서 시작합니다. 디스크 I/O가 제한되어 있으면 더 낮게 조정합니다.

diskHighWatermarkRatio

float

(0.0, 1.0]

비동기 퇴거가 시작되는 디스크 사용량 수준.

0.8 에서 시작합니다. 빈번한 트리거를 방지하기 위해 낮은 워터마크(예: 0.05-0.10)와 적당한 간격을 유지하세요.

모범 사례:

  • 쿼리노드 정적 사용량과 쿼리 시간 버스트를 위한 헤드룸을 확보하기 위해 워터마크를 ~0.80 이상으로 높게 또는 낮게 설정하지 마세요.

  • 높은 워터마크와 낮은 워터마크 사이에 큰 간격을 두지 마세요. 큰 간격은 각 퇴거 주기를 연장하고 지연 시간을 증가시킬 수 있습니다.

캐시 TTL 구성

캐시 TTL(Time-to-Live)은 리소스 임계값에 도달하지 않더라도 설정된 기간이 지나면 캐시된 데이터를 자동으로 제거합니다. 이는 오래된 데이터가 캐시를 무한정 점유하는 것을 방지하기 위해 LRU 퇴거와 함께 작동합니다.

캐시 TTL은 동일한 백그라운드 스레드에서 실행되므로 backgroundEvictionEnabled: true 이 필요합니다.

예제 YAML:

queryNode:
  segcore:
    tieredStorage:
      evictionEnabled: true
      backgroundEvictionEnabled: true
      # Set the cache expiration time to 604,800 seconds (7 days),
      # and expired caches will be cleaned up by a background thread.
      cacheTtl: 604800

매개변수

유형

단위

설명

권장 사용 사례

cacheTtl

정수

캐시된 데이터가 만료되기 전까지의 기간입니다. 만료된 항목은 백그라운드에서 제거됩니다.

매우 동적인 데이터의 경우 짧은 TTL(시간)을 사용하고, 안정적인 데이터 세트의 경우 긴 TTL(일)을 사용합니다. 시간 기반 만료를 사용하지 않으려면 0으로 설정합니다.

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started
피드백

이 페이지가 도움이 되었나요?