기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
벡터 검색 개요
ElastiCache for Valkey는 수십억 개의 고차원 벡터 임베딩을 인덱싱, 검색 및 업데이트할 수 있는 기능을 제공합니다. 벡터 검색을 사용하면 효율적이고 확장 가능한 검색을 위해 보조 인덱스를 생성, 유지 관리 및 사용할 수 있습니다. 각 벡터 검색 작업은 단일 인덱스에 적용됩니다. 인덱스 작업은 지정된 인덱스에만 적용됩니다. 인덱스 생성 및 삭제 작업을 제외하고 언제든지 인덱스에 대해 원하는 수의 작업이 실행될 수 있습니다. 클러스터 수준에서는 여러 인덱스에 대한 여러 작업이 동시에 진행 중일 수 있습니다.
이 문서 내에서 키, 행 및 레코드라는 용어는 동일한 의미로 통용됩니다. 마찬가지로 열, 필드, 경로 및 멤버라는 용어는 통용됩니다.
FT.CREATE 명령을 사용하여 지정된 인덱스 유형의 키 하위 집합에 대한 인덱스를 생성할 수 있습니다. FT.SEARCH는 생성된 인덱스에 대한 쿼리를 수행하고 FT.DROPINDEX는 기존 인덱스와 모든 관련 데이터를 제거합니다. 인덱싱된 데이터를 추가, 삭제 또는 수정하기 위한 특별한 명령은 없습니다. 인덱스에 있는 키를 수정하는 기존 HASH 또는 JSON 명령은 인덱스를 자동으로 업데이트합니다.
인덱스 및 Redis OSS 키스페이스
인덱스는 Valkey OSS 키스페이스의 하위 집합을 기준으로 구성되고 유지 관리됩니다. 각 인덱스의 키스페이스는 인덱스 생성 시 제공되는 키 접두사 목록에 의해 정의됩니다. 접두사 목록은 선택 사항이며 생략하면 전체 키스페이스가 해당 인덱스에 포함됩니다. 여러 인덱스는 키스페이스의 분리되거나 중복되는 하위 집합을 제한 없이 선택할 수 있습니다.
또한 인덱스는 유형이 일치하는 키만 포함하도록 입력됩니다. 현재 인덱스는 JSON 및 HASH 유형으로만 지원됩니다. HASH 인덱스는 접두사 목록에 포함된 HASH 키만 인덱싱하고, 마찬가지로 JSON 인덱스는 접두사 목록에 포함된 JSON 키만 인덱싱합니다. 인덱스의 키스페이스 접두사 목록 내에서 지정된 유형이 없는 키는 무시되며 검색 작업에 영향을 주지 않습니다.
명령이 인덱스의 키스페이스 내에 있는 키를 수정하면 해당 인덱스가 업데이트됩니다. Valkey는 각 인덱스에 대해 선언된 필드를 자동으로 추출하고 인덱스를 새 값으로 업데이트합니다. 업데이트 프로세스에는 세 단계가 있습니다. 첫 번째 단계에서는 HASH 또는 JSON 키가 수정되고 요청 클라이언트가 차단됩니다. 두 번째 단계는 백그라운드에서 수행되며 수정된 키가 포함된 각 인덱스를 업데이트합니다. 세 번째 단계에서는 클라이언트가 차단 해제됩니다. 따라서 변형과 동일한 연결에서 수행되는 쿼리 작업의 경우 해당 변경 사항이 검색 결과에 즉시 표시됩니다.
인덱스 생성은 다단계 프로세스입니다. 첫 번째 단계는 인덱스를 정의하는 FT.CREATE 명령을 실행하는 것입니다. 생성을 성공적으로 실행하면 두 번째 단계인 채우기가 자동으로 시작됩니다. 채우기 프로세스는 백그라운드 스레드에서 실행되며 키스페이스를 스캔하여 새 인덱스의 접두사 목록 내에 있는 키를 찾습니다. 발견된 각 키는 인덱스에 추가됩니다. 결국 전체 키스페이스가 스캔되어 인덱스 생성 프로세스가 완료됩니다. 채우기 프로세스가 실행되는 동안에는 제한 없이 인덱스 키를 변경할 수 있으며 모든 키가 제대로 인덱싱될 때까지 인덱스 채우기 프로세스가 완료되지 않습니다. 인덱스를 채우는 동안 시도한 쿼리 작업은 허용되지 않으며 오류가 발생하여 종료됩니다. FT.INFO 명령은 'backfill_status' 필드에 채우기 프로세스 상태를 반환합니다.
인덱스 필드 유형
각 인덱스에는 인덱스가 생성될 때 인덱싱할 필드(열)의 위치와 함께 선언되는 특정 유형이 있습니다. HASH 키의 경우 위치는 HASH 내의 필드 이름입니다. JSON 키의 경우 위치는 JSON 경로 설명입니다. 키가 수정되면 선언된 필드와 관련된 데이터가 추출되고 선언된 유형으로 변환되어 인덱스에 저장됩니다. 데이터가 누락되었거나 선언된 유형으로 성공적으로 변환할 수 없는 경우 해당 필드는 인덱스에서 제외됩니다. 필드에는 다음 설명과 같이 3가지 유형이 있습니다.
-
벡터 필드에는 벡터 임베딩이라고도 하는 숫자 벡터가 포함됩니다. 벡터 필드를 사용하여 유사성을 측정하는 지정된 거리 지표를 기반으로 벡터를 필터링할 수 있습니다.
HASH인덱스의 경우 필드에 바이너리 형식(리틀 엔디안 IEEE 754)으로 인코딩된 전체 벡터가 포함되어야 합니다.JSON키의 경우 경로는 숫자로 채워진 올바른 크기의 배열을 참조해야 합니다. JSON 배열을 벡터 필드로 사용하는 경우 JSON 키 내 배열의 내부 표현이 선택한 알고리즘에서 요구하는 형식으로 변환되므로 메모리 사용량과 정밀도가 줄어듭니다. 이후에 JSON 명령을 사용하여 읽기 작업을 수행하면 낮아진 정밀도 값을 출력합니다. -
숫자 필드에는 단일 숫자가 포함됩니다. 숫자 필드는 범위 검색 연산자와 함께 사용할 수 있습니다.
HASH의 경우 필드에 고정 또는 부동 소수점 숫자의 표준 형식으로 작성된 ASCII 텍스트가 포함되어야 합니다.JSON필드의 경우 JSON 번호의 숫자 규칙을 따라야 합니다. 키 내 표시 형식에 관계없이 이 필드는 64비트 부동 소수점 숫자로 변환되어 인덱스 내에 저장됩니다. 기본 숫자는 정밀도 제한에 따라 부동 소수점으로 저장되므로 부동 소수점 숫자 비교에 대한 일반적인 규칙이 적용됩니다. -
태그 필드에는 단일 UTF-8 문자열로 코딩된 0개 이상의 태그 값이 포함됩니다. 태그 필드를 사용하여 대소문자를 구분하거나 구분하지 않는 비교를 통해 태그 값이 동일한 쿼리를 필터링할 수 있습니다. 문자열은 선행 및 후행 공백이 제거된 구분 문자(기본값은 쉼표이지만 재정의할 수 있음)를 사용하여 태그 값으로 구문 분석됩니다. 단일 태그 필드에 원하는 수의 태그 값을 포함할 수 있습니다.
벡터 인덱스 알고리즘
Valkey에서는 두 가지 벡터 인덱스 알고리즘이 지원됩니다.
-
FLAT - FLAT 알고리즘은 인덱스의 각 벡터를 무차별 대입으로 선형 처리하여 거리 계산의 정밀도 범위 내에서 정확한 답을 산출합니다. 인덱스의 선형 처리로 인해 큰 인덱스의 경우 이 알고리즘의 실행 시간이 매우 길어질 수 있습니다. 플랫 인덱스는 더 높은 수집 속도를 지원합니다.
-
Hierarchical Navigable Small Worlds(HSSW) - HNSW 알고리즘은 실행 시간을 크게 줄이는 대신 가장 가까운 벡터 매치를 제공합니다. 알고리즘은 세 개의 파라미터
M,EF_CONSTRUCTION,EF_RUNTIME에 의해 제어됩니다. 처음 두 파라미터는 인덱스 생성 시 지정되며 변경할 수 없습니다. 이EF_RUNTIME파라미터는 인덱스 생성 시 지정되는 기본값을 갖지만 이후에 개별 쿼리 작업에서 재정의할 수 있습니다. 이 세 파라미터는 상호 작용하여 수집 및 쿼리 작업 중에 메모리와 CPU 사용량의 균형을 맞추고 정확한 KNN 검색의 근사치 품질(재현율)을 제어합니다.
HNSW에서 파라미터 M은 각 노드가 연결할 수 있는 최대 이웃 수를 제어하여 인덱스 밀도를 형성합니다. 32 이상과 같이 M이 높을수록 그래프가 더 많이 연결되어 관련 이웃에 도달하기 위한 경로가 더 많기 때문에 리콜 및 쿼리 속도가 향상됩니다. 그러나 인덱스 크기와 메모리 사용량을 늘리고 인덱싱 속도를 늦춥니다. 8 이하와 같이 M이 낮을수록 메모리 사용량이 적은 더 작고 빌드가 더 빠른 인덱스가 생성되지만 연결 수가 적기 때문에 리콜이 감소하고 쿼리가 더 오래 걸릴 수 있습니다.
파라미터 EF_construction은 인덱스를 빌드할 때 평가되는 후보 연결 수를 결정합니다. 400 이상과 같이 EF_construction이 높을수록 인덱서는 이웃을 선택하기 전에 더 많은 경로를 고려하므로 나중에 재현율과 쿼리 효율성을 모두 개선하는 그래프가 생성 중 인덱싱 속도가 느려지고 CPU 및 메모리 사용량이 늘어납니다. 64~120과 같은 낮은 EF_construction은 인덱싱 속도를 높이고 리소스 사용을 줄이지만 결과 그래프는 EF_runtime이 높게 설정된 경우에도 재현율을 줄이고 쿼리 속도를 늦출 수 있습니다.
마지막으로 EF_runtime은 쿼리 중 검색 범위를 제어하여 런타임 시 탐색할 후보 이웃 수를 제어합니다. 이 값을 높게 설정하면 재현율과 정확도가 향상되지만 쿼리 지연 시간과 CPU 사용 비용이 발생합니다. EF_runtime이 낮으면 쿼리가 더 빠르고 가볍지만 재현율은 줄어듭니다. M 또는 EF_construction과 달리이 파라미터는 인덱스 크기 또는 빌드 시간에 영향을 주지 않으므로 인덱스가 빌드된 후 재현율 대 지연 시간 균형을 조정하는 파라미터입니다.
벡터 검색 알고리즘(FLAT 및 HNSW) 모두 선택적 INITIAL_CAP 파라미터를 지원합니다. 이 파라미터를 지정하면 인덱스에 메모리를 사전 할당하여 메모리 관리 오버헤드를 줄이고 벡터 수집 비율을 높입니다. 플랫 인덱스는 HNSW보다 더 나은 수집 속도를 지원합니다.
HNSW와 같은 벡터 검색 알고리즘은 이전에 삽입한 벡터의 삭제 또는 덮어쓰기를 효율적으로 처리하지 못할 수 있습니다. 이러한 연산을 사용하면 인덱스 메모리가 과도하게 소모되거나 재현율이 저하될 수 있습니다. 인덱스를 다시 지정하는 것은 최적의 메모리 사용량 또는 재현율을 복원하기 위한 방법 중 하나입니다.
벡터 검색 보안
명령 및 데이터 액세스 모두에 대한 Valkey 액세스 제어 목록(ACL)@search가 추가되었으며 많은 기존 범주(@fast, @read, @write 등)가 새 명령을 포함하도록 업데이트되었습니다. 검색 명령은 키 데이터를 수정하지 않습니다. 즉, 쓰기 액세스를 위한 기존 ACL 시스템이 보존됩니다. HASH 및 JSON 작업에 대한 액세스 규칙은 인덱스가 있더라도 수정되지 않습니다. 이러한 명령에는 여전히 일반적인 키 수준 액세스 제어가 적용됩니다.
인덱스가 있는 검색 명령의 액세스도 ACL로 제어됩니다. 액세스 확인은 키별 수준이 아닌 전체 인덱스 수준에서 수행됩니다. 즉, 사용자가 해당 인덱스의 키스페이스 접두사 목록 내에서 가능한 모든 키에 액세스할 수 있는 권한을 가진 경우에만 사용자에게 인덱스 액세스 권한이 부여됩니다. 즉, 인덱스의 실제 콘텐츠는 액세스를 제어하지 않습니다. 그보다는 접두사 목록에 정의된 인덱스의 이론상 내용이 보안 검사에 사용됩니다. 사용자에게 키에 대한 읽기 및/또는 쓰기 액세스는 있지만 가능한 해당 키가 포함된 인덱스에는 액세스할 수 없는 상황입니다. 인덱스를 만들거나 사용할 때는 키스페이스에 대한 읽기 액세스만 필요하며 쓰기 액세스 유무는 고려되지 않습니다.
