벡터 인덱스 삭제 표시란 무엇이며, 파일 삭제 후 왜 중요한가요?

벡터 인덱스 툼스톤은 제거된 레코드를 기반 검색 구조에서 물리적으로 회수하기 전에 숨기는 논리적 삭제 표시입니다.

로컬 RAG 인덱스에서는 PDF나 사진을 삭제해도 벡터 그래프, 세그먼트 파일 또는 스토리지 페이지가 다시 작성되기 훨씬 전부터 해당 청크가 일반 검색 결과에서 사라질 수 있습니다. 툼스톤을 사용하면 나중에 유지 관리가 수행되는 동안 데이터베이스가 인덱스 일관성을 유지할 수 있습니다. 이러한 중간 상태는 스토리지 용량 추정, 인덱스 상태, 업데이트 변동량, 그리고 논리적 삭제가 즉각적인 물리적 삭제와 같다는 가정에 영향을 줍니다.

툼스톤은 물리적 정리 전에 레코드를 삭제된 것으로 표시합니다

근사 인덱스에서 레코드를 삭제할 때 모든 물리적 참조를 한 번의 저비용 작업으로 제거할 수 있는 것은 아닙니다. 대신 시스템은 항목을 삭제된 것으로 표시하고, 표시되는 검색 결과에서 제외한 다음, 구조적 정리를 나중에 유지 관리 과정에서 수행할 수 있습니다.

HNSW 인덱스에서는 툼스톤이 삭제된 객체를 표시하며, 정리 프로세스가 이를 제거할 때까지 그래프에 남아 있을 수 있습니다.

가정용 지식 베이스에서는 원본 파일이 사라지고 쿼리 계층이 해당 청크를 올바르게 숨기더라도, 내부 인덱스 상태에는 해당 노드가 한때 존재했다는 기록이 남아 있을 수 있다는 뜻입니다.

인덱스에 상태가 남아 있는 동안에도 검색에서는 삭제된 벡터를 숨길 수 있습니다

논리적 삭제와 물리적 회수는 서로 다른 질문에 답합니다. 전자는 레코드가 검색 결과에 표시될 수 있는지를 묻고, 후자는 해당 레코드의 바이트와 인덱스 관계가 스토리지 및 메모리 구조에서 제거되었는지를 묻습니다.

세그먼트 기반 인덱스는 모든 삭제 작업이 즉시 세그먼트를 다시 작성하도록 강제하는 대신, 삭제된 레코드를 병합 시점까지 남겨 둘 수 있습니다.

이러한 분리 때문에 컬렉션의 레코드 수는 줄어도 디스크 사용량은 그대로일 수 있습니다. 또한 과도한 삭제 및 업데이트 작업이 오래된 레코드를 일반 검색 결과에 다시 노출시키지 않으면서 유지 관리 부채를 누적할 수 있는 이유이기도 합니다.

따라서 모니터링 대시보드는 하나의 지표만으로 정리가 완료되었다고 판단하지 말고, 활성 레코드, 삭제 대기 상태, 세그먼트 수, 실제 디스크 사용량을 구분해서 표시해야 합니다.

파일이 반복해서 변경되거나 교체되면 툼스톤이 누적됩니다

개인용 인덱스는 사용자가 파일을 영구적으로 삭제할 때뿐 아니라 일반적인 업데이트 과정에서도 삭제 표시를 생성할 수 있습니다. 문서 버전을 교체하면 이전 청크가 삭제되고 새 청크가 삽입될 수 있으며, 폴더를 재구성하면 이전 식별자에 속한 레코드가 폐기될 수 있습니다.

변경 가능한 벡터 컬렉션은 세그먼트 최적화가 이러한 변경 사항을 비동기적으로 통합하기 전에 업데이트와 삭제를 누적합니다.

가정용 지식 베이스에서 문서를 자주 다시 임베딩한다면, 툼스톤 부담은 현재 검색 가능한 파일 수보다 변경량을 더 잘 나타내는 지표가 될 수 있습니다. 정리 빈도는 업데이트 속도와 사용 가능한 I/O 여유 용량을 반영해야 합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

툼스톤은 안전한 완전 삭제가 아닙니다

논리적 표시는 포렌식 수준의 삭제가 아니라 인덱스 정확성을 위해 설계되었습니다. 별도의 수명 주기 프로세스가 해당 데이터를 제거할 때까지 이전 바이트가 세그먼트 파일, 스냅샷, 복제본, 백업, 파일 시스템의 여유 공간 또는 기타 파생 저장소에 남아 있을 수 있습니다.

이후 진행되는 삭제 후 컴팩션 단계는 툼스톤 자체와 다른 메커니즘입니다. 컴팩션은 오래된 세그먼트 상태를 다시 작성하고 공간을 회수할 수 있기 때문입니다.

민감한 데이터의 삭제는 원본 파일, 벡터 저장소, 메타데이터, 캐시, 스냅샷, 백업을 모두 포함하는 엔드투엔드 보존 문제로 다뤄야 합니다. 툼스톤은 이러한 전체 수명 주기 안에서 사용되는 하나의 중간 일관성 메커니즘일 뿐입니다.

이러한 구분은 잘못된 스토리지 기대도 방지합니다. 수천 개의 청크를 삭제하면 검색 결과에서는 즉시 올바르게 반영될 수 있지만, 예약된 정리가 완료될 때까지 여유 공간 그래프에는 변화가 나타나지 않을 수 있습니다.