벡터 인덱스의 삭제 표시: 컴팩션 전까지 삭제된 파일을 검색할 수 있는 이유

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

인덱스에 논리적 삭제 표시가 기록되어도 오래된 세그먼트, 복제본, 캐시 또는 파생 청크가 여전히 검색 결과를 제공하면 삭제된 파일을 계속 찾을 수 있습니다.

홈 NAS에서 PDF를 제거해도 해당 파일의 임베딩, 썸네일 텍스트, OCR 출력 또는 캐시된 검색 결과까지 반드시 제거되는 것은 아닙니다. 많은 스토리지 엔진은 먼저 레코드를 삭제된 것으로 표시한 다음, 나중에 컴팩션 과정에서 바이트를 회수합니다. 올바른 쿼리 경로는 즉시 삭제 표시를 반영해야 하지만, 전파가 불완전하거나 필터가 우회되면 오래된 정보가 다시 나타날 수 있습니다.

삭제 표시는 논리적 삭제와 물리적 회수를 분리합니다

추가 중심 스토리지에서는 삭제할 때마다 대규모 세그먼트를 다시 작성하는 작업에 많은 비용이 듭니다. 삭제 표시는 식별자가 더 이상 활성 상태가 아님을 기록합니다. 쿼리는 이 상태를 확인하고, 백그라운드 컴팩션은 나중에 세그먼트를 병합하면서 안전한 시점에 오래된 레코드와 삭제 표시를 모두 제거합니다.

데이터베이스의 논리적 삭제 표시에 대한 설명에 따르면, 삭제 표시는 컴팩션이 물리적 데이터를 제거하기 전에 삭제된 행이 반환되지 않도록 합니다. 세그먼트와 삭제 맵의 구현 방식은 다르더라도 벡터 시스템에도 같은 원칙이 적용됩니다.

이러한 구분은 삭제 후에도 디스크 사용량이 줄지 않을 수 있는 이유를 설명합니다. 하지만 그 자체로 검색 결과가 표시되는 이유를 설명하지는 못합니다. 올바른 최신 쿼리는 바이트가 디스크에 남아 있는 동안에도 삭제 표시가 있는 벡터를 제외해야 합니다.

삭제된 파일은 여러 개의 독립적인 파생물을 남길 수 있습니다

하나의 원본 파일에서 청크, 임베딩, 키워드 포스팅, 요약, OCR 텍스트, 썸네일 및 답변 캐시 항목이 생성될 수 있습니다. 벡터 ID만 삭제하면 다른 검색 경로가 그대로 남습니다. 새 식별자로 다시 수집하면 원래 삭제 목록이 포함하지 않는 중복 항목이 생길 수도 있습니다.

컴팩션 정리에 대한 데이터베이스 문서에서는 데이터를 계속 다시 작성하는 작업이 비용이 많이 들기 때문에 컴팩션 중에 회수가 이루어진다고 설명합니다. 조정된 정리가 완료될 때까지 물리적 스토리지와 논리적 가시성은 서로 별개의 상태로 다뤄야 합니다. 이러한 구분은 최종적인 가정 내 의사결정에도 영향을 줍니다.

따라서 신뢰할 수 있는 삭제 원장은 원본 식별자를 모든 파생물 및 네임스페이스에 매핑해야 합니다. 또한 삭제되는 세대를 기록하여, 지연된 삭제 이벤트가 같은 파일 이름을 가진 최신 대체 파일을 실수로 숨기지 않도록 해야 합니다.

오래된 복제본과 캐시가 삭제 의미를 무너뜨리는 지점

분산 검색 또는 다중 프로세스 검색에서는 전파 지연이 발생합니다. 한 작업자는 삭제 표시를 반영하지만 다른 작업자는 오래된 세그먼트를 제공할 수 있으며, 응답 캐시는 인덱스를 전혀 조회하지 않고 이전에 생성된 답변을 반환할 수 있습니다. 보존 규칙에 삭제된 파생물이 포함되지 않으면 백업이 나중에 해당 파생물을 복원할 수도 있습니다.

DataStax는 복제본 삭제 표시를 최종 제거 전에 복제본 전체에 전파되는 표식으로 설명합니다. 유예 기간은 분산 스토리지에서 데이터가 되살아나는 것을 방지하지만, 동시에 너무 이른 정리와 일관되지 않은 복제본에 신중한 조정이 필요한 이유도 보여 줍니다. 이러한 경계는 이후 증거 검토에서도 계속 드러납니다.

실패의 경계는 사용 중인 바이트가 아니라 쿼리 가시성입니다. 약속된 삭제 기간이 지난 후에도 지원되는 검색 경로에서 삭제된 증거를 반환할 수 있다면, 대시보드에 성공으로 표시되더라도 시스템은 삭제를 완료한 것이 아닙니다.

-15% OFF

모든 검색 경로에서 삭제를 입증하세요

삭제하기 전에 원본 ID, 파생 청크 ID, 고유한 문구 하나와 캐시된 질문 하나를 기록하세요. 파일을 삭제한 다음 컴팩션 전후에 문구, 의미적으로 바꿔 표현한 검색어, 메타데이터 필터, 원본 ID 및 캐시된 질문으로 각각 쿼리를 실행하세요.

증분 인덱싱 상태에서 설명한 동일한 최신 파일 관리 원칙을 사용하세요. 테스트에서는 논리적 가시성, 물리적 스토리지 및 과거 보존을 구분해야 합니다. 한 번의 성공적인 쿼리를 믿지 말고 구성된 모든 복제본 또는 작업자를 점검하세요. 따라서 실제로는 해당 의존성을 별도로 측정해야 합니다.

현재 모드의 어떤 경로에서도 원본 또는 그 파생물이 반환되지 않고, 캐시가 무효화되며, 컴팩션이 결국 예상 스토리지를 회수할 때만 통과로 처리하세요. 과거 복구가 의도된 기능이라면 별도의 권한 체계 뒤에 격리하고 일반 RAG 쿼리에서는 사용할 수 없도록 하세요.

기술 및 AI 허브

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.