기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

적절한 구성 선택

콘솔 환경 내에서 ElastiCache는 벡터 워크로드의 메모리 및 cpu 요구 사항에 따라 올바른 인스턴스 유형을 쉽게 선택할 수 있는 방법을 제공합니다.

메모리 사용

메모리 소비는 벡터 수, 차원 수, M-값, 벡터가 아닌 데이터(예: 벡터에 연결된 메타데이터 또는 인스턴스에 저장된 기타 데이터)의 양을 기반으로 합니다. 필요한 총 메모리는 실제 벡터 데이터에 필요한 공간과 벡터 인덱스에 필요한 공간의 조합입니다. 벡터 데이터에 필요한 공간은 최적의 메모리 할당을 위해 HASH 또는 JSON 데이터 구조 내에 벡터를 저장하는 데 필요한 실제 용량과 가장 가까운 메모리 슬래브에 대한 오버헤드를 측정하여 계산됩니다. 각 벡터 인덱스는 이러한 데이터 구조에 저장된 벡터 데이터에 대한 참조와 인덱스에 있는 벡터의 추가 복사본을 사용합니다. 인덱스별이 추가 공간 소비를 계획하는 것이 좋습니다.

벡터 수는 데이터를 벡터로 표현하는 방법에 따라 달라집니다. 예를 들어 단일 문서를 여러 청크로 나타내도록 선택할 수 있습니다. 여기서 각 청크는 벡터를 나타냅니다. 또는 전체 문서를 단일 벡터로 나타내도록 선택할 수 있습니다. 벡터의 차원 수는 선택한 임베딩 모델에 따라 달라집니다. 예를 들어AWS Titan 임베딩 모델을 사용하기로 선택한 경우 차원 수는 1536입니다. 인스턴스 유형을 테스트하여 요구 사항에 맞는지 확인해야 합니다.

워크로드 규모 조정

벡터 검색은 수평, 수직 및 복제본이라는 세 가지 조정 방법을 모두 지원합니다. 용량 규모 조정 시 벡터 검색은 일반 Valkey처럼 동작합니다. 즉, 개별 노드의 메모리를 늘리거나(수직적 스케일링) 노드 수를 늘리면(수평적 스케일링) 전체 용량이 증가합니다. 클러스터 모드에서는 FT.CREATE 명령을 클러스터의 모든 프라이머리 노드로 전송할 수 있으며 시스템은 새 인덱스 정의를 모든 클러스터 멤버에게 자동으로 배포합니다.

그러나 성능 관점에서 벡터 검색은 일반 Valkey와 매우 다르게 동작합니다. 벡터 검색을 다중 스레드로 구현하면 추가 CPU에서 쿼리 처리량과 수집 처리량을 모두 선형으로 증가할 수 있습니다. 수평적 스케일링은 수집 처리량을 선형적으로 증가시키지만 쿼리 처리량을 줄일 수 있습니다. 추가 쿼리 처리량이 필요한 경우 복제본 또는 추가 CPU를 통해 규모를 조정해야 합니다.