문서 삭제 후 벡터 데이터베이스 압축은 어떻게 공간을 회수하나요?

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

벡터 데이터베이스 압축은 활성 레코드를 정리된 세그먼트로 다시 작성하고, 삭제된 벡터가 여전히 포함된 기존 세그먼트 파일을 폐기하여 삭제된 공간을 회수합니다.

로컬 RAG 라이브러리에서 가정용 문서를 삭제하면 검색에서는 즉시 사라지지만 디스크 사용량은 거의 줄어들지 않을 수 있습니다. 그렇다고 삭제에 실패한 것은 아닙니다. 많은 벡터 데이터베이스는 논리적 표시 여부와 물리적 스토리지 정리를 분리하여, 포그라운드 쓰기 성능을 유지하고 리더가 변경 불가능하거나 추가 기록 방식의 세그먼트를 계속 사용할 수 있도록 합니다. 압축은 이러한 논리적 삭제를 더 작은 물리적 표현으로 바꾸는 이후의 유지 관리 과정입니다.

삭제는 보통 저장된 바이트를 다시 쓰기 전에 표시 여부를 변경합니다

삭제할 때마다 대형 인덱스 파일을 물리적으로 수정하면 값비싼 랜덤 쓰기와 복잡한 동시성 문제가 발생합니다. 대신 많은 엔진은 검색 시 해당 벡터를 무시하도록 삭제 표시, 삭제된 항목 표시(tombstone) 또는 삭제 로그를 기록합니다.

HNSW 삭제 표시를 사용하면 백그라운드 유지 관리가 모든 인덱스 상태를 물리적으로 제거하기 전에 삭제된 객체를 그래프 검색 대상에서 제외할 수 있습니다.

따라서 사용자에게 보이는 결과와 디스크 수준의 결과는 서로 다른 시점에 발생합니다. 레코드는 최근접 이웃 결과에서 사라질 수 있지만 기존 세그먼트 안에는 이전 바이트가 그대로 남아 있을 수 있습니다.

이러한 분리는 데이터베이스가 과거 스토리지 구조를 삭제하기 전에 동시 쿼리, 복제본, 스냅샷, 보존 규칙을 조율할 여지도 제공합니다.

삭제된 레코드는 정리 임계값에 도달할 때까지 세그먼트 안에 쌓입니다

하나의 세그먼트에는 활성 벡터와 더 이상 검색 대상이 아닌 레코드가 함께 포함될 수 있습니다. 업데이트와 삭제가 누적되면 유용한 데이터와 불필요한 데이터의 비율이 낮아집니다.

삭제된 벡터 임계값은 세그먼트를 다시 작성할 만큼 불필요한 포인트가 충분히 쌓일 때까지 비용이 큰 정리를 지연할 수 있습니다.

임계값을 기다리면 유지 관리 작업을 여러 항목에 분산할 수 있습니다. 삭제된 레코드 하나를 회수하기 위해 세그먼트를 다시 작성하면 절약되는 공간보다 더 많은 I/O 비용이 발생할 수 있습니다. 따라서 자주 재인덱싱하는 홈 서버에서는 옵티마이저가 정리할 가치가 있다고 판단하기 전까지, 눈에 보이는 오래된 물리 스토리지의 양이 한동안 증가할 수 있습니다.

압축은 활성 데이터를 새 세그먼트나 병합된 세그먼트로 복사합니다

유지 관리가 시작되면 데이터베이스는 대상 소스 세그먼트를 읽고, 논리적으로 삭제된 레코드를 건너뛴 다음, 남아 있는 벡터와 페이로드를 새로운 압축 표현으로 기록합니다.

세그먼트 병합 및 삭제 정리 방식의 압축은 이미 논리적으로 삭제되었거나 만료된 레코드를 제외하고 남은 데이터를 더 정리된 세그먼트로 다시 작성합니다.

이와 동시에 작은 세그먼트를 병합할 수 있으므로 검색 시 확인해야 하는 별도 구조의 수가 줄어듭니다. 새 세그먼트는 모든 과거 변경 사항을 이어받는 대신 현재 활성 상태를 나타냅니다.

교체 대상이 검증되어 활성화될 때까지 기존 세그먼트와 새 세그먼트가 함께 존재할 수 있으므로, 이 다시 쓰기 과정에는 일시적으로 추가 여유 공간이 필요할 수 있습니다.

인덱스는 남아 있는 벡터 집합을 기준으로 다시 구축됩니다

벡터 페이로드 바이트를 제거하는 것은 정리의 일부일 뿐입니다. 그래프 링크, 양자화 구조, 필터, 세그먼트 메타데이터가 더 이상 활성 세그먼트에 속하지 않는 레코드를 참조할 수 있습니다.

최적화 중 인덱스를 다시 구축하는 압축 과정은 그래프 및 보조 검색 구조가 제거된 포인트에 대한 참조를 유지하지 않고 남아 있는 벡터 집합에 맞도록 보장합니다.

HNSW에서는 남아 있는 벡터 자체가 변경되지 않더라도 그래프 토폴로지가 바뀔 수 있습니다. 따라서 논리적 데이터셋은 동일하게 유지하면서도 압축이 근사 최근접 이웃 탐색에 영향을 줄 수 있습니다. 이 글에서 다루는 핵심은 스토리지 수명 주기입니다. 불필요한 레코드는 다시 작성된 인덱스에서 제외되므로 물리적 공간을 결국 회수할 수 있습니다.

스토리지를 해제하려면 기존 세그먼트를 먼저 폐기해야 합니다

압축된 세그먼트가 활성 표현이 되면 기존 세그먼트는 더 이상 사용되지 않는 것으로 표시되거나 삭제됩니다. 하지만 실제 디스크 블록이 해제되기 전까지 기본 파일이 가비지 컬렉션 또는 보존 기간을 기다릴 수 있습니다.

압축 후 가비지 컬렉션이 실행되면 압축된 교체 세그먼트가 활성화된 뒤에도 삭제된 세그먼트 파일이 일시적으로 남을 수 있으므로, 파일 시스템 공간은 쿼리 표시 여부가 변경된 뒤에야 해제될 수 있습니다.

이전 세그먼트 세대를 보존하는 시스템에서는 스냅샷, 백업 보존, 복제 또는 참조를 유지하는 리더로 인해 지연 시간이 더 길어질 수 있습니다.

따라서 디스크 모니터링에서는 논리적 엔터티 수, 활성 세그먼트 크기, 임시 압축 공간, 삭제된 세그먼트, 파일 시스템의 여유 용량을 구분해야 합니다.

압축은 자체적인 리소스 비용이 발생하는 백그라운드 유지 관리입니다

기존 세그먼트 읽기, 새 세그먼트 쓰기, 인덱스 재구축, 불필요한 파일 삭제에는 CPU, 디스크 대역폭, 메모리, 때로는 임시 중복 스토리지가 사용됩니다.

삭제 표시 정리 지표를 사용하면 삭제 처리를 자체 주기, 기간, 리소스 사용량이 발생하는 유지 관리 작업으로 확인할 수 있습니다.

파일 업데이트 후 오래된 인덱스 레코드가 남지 않도록 하는 것은 선행 조건입니다. 압축이 불필요한 표현을 회수하려면 먼저 소스 삭제가 벡터 데이터베이스에 반영되어야 합니다.

기술 및 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.