Vektorindex-Löschmarkierungen: Wie gelöschte Dateien bis zur Komprimierung durchsuchbar bleiben

Gelöschte Dateien können weiterhin auffindbar bleiben, wenn ein Index ein logisches Tombstone speichert, ältere Segmente, Replikate, Caches oder abgeleitete Chunks jedoch weiterhin Suchanfragen bedienen.

Das Entfernen einer PDF-Datei von einem Heim-NAS entfernt nicht zwangsläufig ihr Embedding, den Text aus dem Thumbnail, die OCR-Ausgabe oder das zwischengespeicherte Abrufresultat. Viele Speicher-Engines markieren Datensätze zunächst als gelöscht und geben ihren Speicherplatz erst später während der Komprimierung frei. Korrekte Abfragepfade sollten den Marker sofort berücksichtigen, doch eine unvollständige Weitergabe oder ein umgangener Filter kann dazu führen, dass veraltete Informationen angezeigt werden.

Ein Tombstone trennt logisches Löschen von physischer Freigabe

Bei anhängeorientierter Speicherung wäre es teuer, für jede Löschung ein großes Segment neu zu schreiben. Ein Tombstone vermerkt, dass eine Kennung nicht mehr aktiv ist. Abfragen berücksichtigen diesen Status, während die Hintergrundkomprimierung später Segmente zusammenführt und sowohl den veralteten Datensatz als auch seinen Marker entfernt, sobald dies sicher möglich ist.

Eine Erklärung zu logischen Tombstones in Datenbanken weist darauf hin, dass Tombstones verhindern, dass gelöschte Zeilen zurückgegeben werden, bevor die Komprimierung ihre physischen Daten entfernt. Dasselbe Prinzip ist für Vektorsysteme relevant, auch wenn sich deren Segment- und Löschkarten-Implementierungen unterscheiden.

Diese Unterscheidung erklärt, warum der Speicherplatz nach einer Löschung möglicherweise nicht abnimmt. Sie erklärt jedoch nicht allein ein sichtbares Suchergebnis: Eine korrekte aktuelle Abfrage muss den mit einem Tombstone versehenen Vektor ausschließen, selbst wenn seine Bytes noch auf dem Datenträger liegen.

Eine gelöschte Datei kann mehrere unabhängige Ableitungen hinterlassen

Aus einer Quelldatei können Chunks, Embeddings, Keyword-Postings, Zusammenfassungen, OCR-Text, Thumbnails und Einträge im Antwort-Cache entstehen. Wenn nur die Vektor-IDs gelöscht werden, bleiben andere Abrufpfade intakt. Eine erneute Aufnahme unter einer neuen Kennung kann außerdem Duplikate erzeugen, die von der ursprünglichen Löschliste nicht erfasst werden.

Die Datenbankdokumentation zur Bereinigung während der Komprimierung erklärt, dass die Freigabe während der Komprimierung erfolgt, weil ein kontinuierliches Neuschreiben der Daten kostspielig wäre. Bis die koordinierte Bereinigung abgeschlossen ist, müssen physische Speicherung und logische Sichtbarkeit als getrennte Zustände behandelt werden. Diese Unterscheidung verändert die daraus resultierende Entscheidung im Haushalt.

Ein zuverlässiges Löschprotokoll ordnet die Quellidentität daher jeder Ableitung und jedem Namespace zu. Es erfasst außerdem die zu löschende Generation und verhindert so, dass ein verzögertes Löschereignis versehentlich einen neueren Ersatz mit demselben Dateinamen ausblendet.

Wo veraltete Replikate und Caches die Löschsemantik beeinträchtigen

Verteilte oder mehrprozessuale Suche bringt Verzögerungen bei der Weitergabe mit sich. Ein Worker berücksichtigt möglicherweise den Tombstone, während ein anderer ein älteres Segment ausliefert; ein Antwort-Cache kann eine zuvor erstellte Antwort zurückgeben, ohne den Index überhaupt abzufragen. Backups können die gelöschte Ableitung später wiederherstellen, wenn die Aufbewahrungsregeln sie nicht einbeziehen.

DataStax beschreibt Tombstones auf Replikaten als Marker, die über Replikate weitergegeben werden, bevor sie endgültig entfernt werden. Die Karenzzeit schützt in verteilten Speichern vor dem Wiederauftauchen von Daten, zeigt aber auch, warum eine vorzeitige Bereinigung und inkonsistente Replikate sorgfältige Koordination erfordern. Diese Grenze bleibt bei einer späteren Prüfung der Belege sichtbar.

Die Fehlergrenze liegt in der Sichtbarkeit von Abfragen, nicht im belegten Speicherplatz. Wenn ein unterstützter Suchpfad nach Ablauf des zugesagten Löschzeitraums die gelöschten Belege weiterhin zurückgeben kann, ist die Löschung nicht abgeschlossen, selbst wenn ein Dashboard den Erfolg meldet.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Die Löschung über jeden Suchpfad nachweisen

Erfassen Sie vor der Löschung die Quell-ID, die IDs der abgeleiteten Chunks, einen eindeutigen Ausdruck und eine zwischengespeicherte Frage. Löschen Sie die Datei und suchen Sie anschließend vor und nach der Komprimierung nach dem Ausdruck, einer semantischen Umschreibung, einem Metadatenfilter, der Quell-ID und der zwischengespeicherten Frage.

Verwenden Sie dieselbe Disziplin für aktuelle Dateien, die in der Zustandsverwaltung für inkrementelle Indizierung beschrieben wird: Der Test sollte zwischen logischer Sichtbarkeit, physischer Speicherung und historischer Aufbewahrung unterscheiden. Prüfen Sie jedes konfigurierte Replikat und jeden Worker, anstatt einer einzigen erfolgreichen Abfrage zu vertrauen. Die Abhängigkeit muss daher in der Praxis separat gemessen werden.

Der Test ist nur dann bestanden, wenn kein aktueller Modus die Quelle oder ihre Ableitungen zurückgibt, die Caches ungültig gemacht wurden und die Komprimierung den erwarteten Speicherplatz schließlich freigibt. Wenn eine historische Wiederherstellung beabsichtigt ist, isolieren Sie sie hinter einer separaten Autorisierung und machen Sie sie für gewöhnliche RAG-Abfragen unzugänglich.