Co powoduje, że segmenty indeksu wektorowego przyrastają szybciej niż nowe dokumenty?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

What Causes Vector Index Segments to Multiply Faster Than New Documents?

Segmenty indeksu wektorowego mnożą się szybciej niż dokumenty, gdy podczas pobierania danych zatwierdzanych jest wiele małych, niezmiennych partii albo kompaktowanie nie może szybko scalić zastępowanych i usuniętych rekordów.

Jeden domowy plik PDF może dać setki fragmentów, a jego aktualizacja może zapisać nowe wektory oraz znaczniki usunięcia dla starych. Częste zatwierdzanie, wiele pól wektorowych, indeksy metadanych, repliki i kolejne generacje ponowień tworzą struktury fizyczne wykraczające poza liczbę dokumentów. Jeśli kompaktowanie w tle nie nadąża, te małe segmenty pozostają widoczne i gromadzą się szybciej niż rośnie biblioteka.

Polityka opróżniania zamienia małe partie pobierania danych w segmenty

Wiele indeksów buforuje zapisy w pamięci i zamyka niezmienny segment po osiągnięciu progu rozmiaru, czasu, transakcji lub pamięci. Obserwator, który zatwierdza każdy plik lub fragment, może tworzyć wiele niedopełnionych segmentów. Różnica ta pozostaje widoczna podczas późniejszych testów domowych.

Wyjaśnienie dotyczące niezmiennych komponentów indeksu pokazuje, jak drzewa zoptymalizowane pod kątem zapisu opróżniają dane z pamięci do wielu komponentów tylko do dopisywania. Magazyny wektorowe różnią się wewnętrznie, ale sygnatura wzrostu segmentów jest taka sama: tworzenie segmentów zależy od liczby opróżnień, a nie od liczby dokumentów.

Porównaj liczbę wektorów na segment i przyczynę opróżnienia. Małe, równomiernie rozmieszczone w czasie segmenty wskazują na częstotliwość zatwierdzania lub progi pamięci; duże segmenty pojawiające się wyłącznie podczas importów zbiorczych są normalnym elementem struktury pobierania danych. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

Aktualizacje i znaczniki usunięcia tworzą więcej rekordów niż nowych dokumentów

Zastąpienie jednego pliku może zapisać każdy nowy fragment, zachowując znaczniki usunięcia lub nieaktualne wektory do czasu oczyszczenia. Reprezentacje metadanych, rzadkie, gęste i skwantyzowane mogą znajdować się w osobnych rodzinach segmentów, a repliki ponownie mnożą każdą z tych rodzin. Tę granicę należy mierzyć osobno w realistycznych warunkach działania.

Szczegółowy opis kompromisów związanych z rozmiarem segmentów wyjaśnia, jak rozmiar segmentu wpływa na liczbę plików oraz działanie odczytu i kompaktowania. Właściwym mianownikiem są rekordy fizyczne i repliki, a nie liczba dokumentów źródłowych. Praktyczna konsekwencja ujawnia się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Charakterystycznym sygnałem są duże liczby zapisanych i usuniętych wektorów mimo niewielkiej liczby dokumentów netto. Stabilna liczba segmentów przy rosnącej liczbie znaczników usunięcia to inny problem niż zbyt wiele nowo zamkniętych segmentów. Ta zależność powinna pozostać wyraźnie określona w interfejsie końcowym.

Zaległości kompaktowania i nieudane kompilacje uniemożliwiają konsolidację

Kompaktowanie wymaga wolnego miejsca, przepustowości operacji wejścia/wyjścia, procesora oraz nieprzerwanego czasu na odczyt segmentów i zapis ich zamienników. Migawki, obciążenie zapytaniami, mała ilość wolnego miejsca na dysku, awarie lub ograniczenia harmonogramowania mogą opóźniać wycofanie danych wejściowych. Wynik należy zatem sprawdzić względem pierwotnych dowodów.

Opis inżynieryjny zaległości kompaktowania segmentów przedstawia kompaktowanie zorientowane na segmenty oraz kompromisy związane ze zwielokrotnieniem odczytu i zapisu. Pokazuje, dlaczego polityka kompaktowania musi odpowiadać cyklowi życia i wzorcowi aktualizacji danych indeksu. Różnica ta pozostaje widoczna podczas późniejszych testów domowych.

Granica awarii przebiega przy tymczasowym skoku liczby segmentów podczas prawidłowego scalania. Proliferację należy diagnozować dopiero wtedy, gdy stare segmenty pozostają po pomyślnym zatwierdzeniu i okresach karencji albo gdy wiek zaległości i zwielokrotnienie odczytu nadal rosną. Wynik pośredni musi pozostać możliwy do sprawdzenia, zanim automatyzacja będzie kontynuowana.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Uzgodnij dokumenty, wektory, segmenty i zadania kompaktowania

Dla każdej transakcji pobierania danych rejestruj dokumenty źródłowe, fragmenty, wektory gęste i rzadkie, rekordy metadanych, znaczniki usunięcia, repliki, przyczynę opróżnienia, rozmiar segmentu, dane wejściowe i wyjściowe kompaktowania, porzucone kompilacje, odwołania do migawek, wolne miejsce oraz wiek najstarszej zaległości. Tę granicę należy mierzyć osobno w realistycznych warunkach działania.

Użyj struktury indeksu wektorowego, aby powiązać liczbę wektorów z kosztem wyszukiwania. Przetestuj zatwierdzanie zbiorcze w porównaniu z zatwierdzaniem każdego pliku, aktualizację jednego dokumentu, usunięcie i ponowne dodanie, wstrzymanie kompaktowania oraz ponowne uruchomienie, zachowując ten sam zestaw treści. Praktyczna konsekwencja ujawnia się, gdy kilka źródeł konkuruje o ograniczony kontekst.

Test przechodzi, gdy liczba segmentów wraca do oczekiwanego poziomu po kompaktowaniu, a każdy zachowany segment ma aktywny manifest, migawkę lub oczekujące scalanie. Dostosuj rozmiar opróżniania lub zasoby kompaktowania dopiero po usunięciu porzuconych generacji i wyjaśnieniu mnożników replik.