Jak migawki systemu plików wpływają na kompaktowanie bazy danych wektorowych?

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.

How Do Filesystem Snapshots Affect Vector Database Compaction? - Zima Store Online

Migawki systemu plików mogą sprawić, że kompaktowanie wektorów zachowa zarówno stare, jak i przepisane bloki, opóźniając odzyskiwanie miejsca i zwiększając obciążenie mechanizmu copy-on-write podczas scalania.

Baza danych wektorowych może kompaktować segmenty, aby usunąć znaczniki usunięcia, scalić małe pliki i poprawić lokalność zapytań, usuwając nieaktualne pliki po bezpiecznej podmianie. Migawka systemu plików wykonana przed scaleniem nadal odwołuje się do ich starych bloków, więc pula zachowuje je, jednocześnie przydzielając miejsce na skompaktowany wynik. Migawka zachowuje możliwość odzyskania danych, ale sposób wykorzystania wolnego miejsca i charakterystyka opóźnień różnią się od systemu plików bez migawki.

Kompaktowanie przepisuje rekordy logiczne do nowych plików

Wiele magazynów wektorowych korzysta z niezmiennych segmentów lub komponentów o strukturze logu. Aktualizacje i usunięcia dopisują nowy stan, a następnie kompaktowanie w tle odczytuje aktywne rekordy, zapisuje skonsolidowane pliki, aktualizuje manifesty i usuwa zastąpione segmenty po bezpiecznym zatwierdzeniu. Ten efekt powinien pozostać mierzalny w docelowym obciążeniu domowego serwera.

Podstawowe opracowanie dotyczące kompaktowania LSM opisuje drzewa scalania o strukturze logu jako hierarchię, która grupuje zapisy i z czasem scala komponenty. Ten sposób przepisywania wyjaśnia, dlaczego kompaktowanie tymczasowo wymaga zarówno danych wejściowych, jak i wyjściowych. Rozróżnienie ma znaczenie, gdy kilka etapów potoku współdzieli ten sam budżet pamięci masowej i operacyjnej.

Struktury specyficzne dla wektorów dodają połączenia grafowe, listy wystąpień, indeksy ładunków i pliki kwantyzacji, dlatego liczba skompaktowanych bajtów nie musi odpowiadać liczbie usuniętych bajtów. Czyszczenie na poziomie bazy danych i odzyskiwanie bloków na poziomie systemu plików to odrębne zdarzenia. Tę granicę należy sprawdzić na reprezentatywnych danych domowych, a nie zakładać jej z góry.

Migawki utrzymują dostępność bloków sprzed kompaktowania

Migawka copy-on-write rejestruje graf bloków w określonym momencie. Gdy kompaktowanie zapisuje nowe pliki, aktywny system plików odwołuje się do nowych bloków, a migawka nadal odwołuje się do starych segmentów; usunięcie nazw plików z bieżącego widoku nie może zwolnić bloków, które są nadal potrzebne migawce.

Zatrzymywanie bloków przez migawki w OpenZFS definiuje migawki jako wersje systemu plików lub woluminu tylko do odczytu w określonym momencie. Zajmowane przez nie miejsce rośnie wraz z rozbieżnością między danymi aktywnymi a migawką, co dokładnie odpowiada sytuacji powodowanej przez duże kompaktowanie wymagające intensywnego przepisywania.

Szybne utworzenie migawki może więc poprzedzać znaczny późniejszy wzrost zajętego miejsca. Koszt pojawia się przy kolejnych zapisach, a niekoniecznie podczas tworzenia migawki, i utrzymuje się do czasu usunięcia wszystkich migawkek odwołujących się do tych bloków. Ten efekt powinien pozostać mierzalny w docelowym obciążeniu domowego serwera.

Mała ilość wolnego miejsca może zamienić retencję w opóźnienia

Kompaktowanie wymaga tymczasowego zapasu miejsca, a alokacja copy-on-write wymaga wolnych bloków. Gdy migawki zachowują stare segmenty, pula może ulec fragmentacji lub zbliżyć się do pełnej pojemności, spowalniając zapisy i wydłużając kompaktowanie; dłuższe kompaktowanie z kolei pozostawia więcej segmentów i zwiększa ilość pracy podczas zapytań.

Kompaktowanie wektorów w Milvus opisuje kompaktowanie jako scalanie małych segmentów i czyszczenie usuniętych danych w celu poprawy działania pamięci masowej i zapytań. Mechanizm ten pokazuje, dlaczego bazy danych wektorowych mogą przepisywać znaczne pliki, nawet gdy logiczna zmiana polega na zbiorze usunięć.

Błędem jest założenie, że rozmiar migawki raportowany w momencie jej utworzenia przewiduje jej końcowy koszt. Objętość kompaktowania, intensywność aktualizacji, kompresja, usunięte wektory, ilość wolnego miejsca w puli i czas życia migawki określają liczbę zachowanych bajtów oraz opóźnienie ogona. Rozróżnienie ma znaczenie, gdy kilka etapów potoku współdzieli ten sam budżet pamięci masowej i operacyjnej.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

FAQ dotyczące migawek i kompaktowania wektorów

Czy podczas kompaktowania należy wyłączyć migawki?

Nie automatycznie. Migawki chronią punkty odzyskiwania, ale planowanie dużych operacji kompaktowania poza oknami tworzenia migawek może ograniczyć zachowywaną rozbieżność. Każda zmiana powinna zachować przetestowany plan tworzenia kopii zapasowych i zapewnić spójność bazy danych. Tę granicę należy sprawdzić na reprezentatywnych danych domowych, a nie zakładać jej z góry.

Dlaczego rozmiar bazy danych pozostaje duży po skompaktowaniu usuniętych wektorów?

Stare bloki mogą być nadal wskazywane przez migawki, klony lub kopie zapasowe, nawet gdy aktywna baza danych usunie nieaktualne segmenty. Sprawdzaj osobno pliki bazy danych i miejsce wskazywane przez system plików. Ten efekt powinien pozostać mierzalny w docelowym obciążeniu domowego serwera.

Czy migawka może przechwycić niespójny indeks wektorowy?

Tak, jeśli pliki bazy danych, dzienniki zapisu z wyprzedzeniem, manifesty i powiązane metadane nie zostaną wstrzymane lub przechwycone atomowo. W razie potrzeby przed wykonaniem migawki systemu plików użyj mechanizmu punktu kontrolnego lub opróżnienia buforów udostępnianego przez bazę danych. Rozróżnienie ma znaczenie, gdy kilka etapów potoku współdzieli ten sam budżet pamięci masowej i operacyjnej.

Zmierz rozbieżność migawki podczas kontrolowanego scalania

Sklonuj reprezentatywny indeks, zanotuj rozmiar logiczny i fizyczny, wykonaj migawkę, a następnie przeprowadź zmierzony cykl usuwania i kompaktowania. Śledź liczbę bajtów kompaktowania, szczytowe tymczasowe zużycie miejsca, liczbę bajtów wskazywanych przez migawkę, ilość wolnego miejsca w puli, opóźnienie zapisu, opóźnienie ogona zapytań oraz czas potrzebny na odzyskanie miejsca po usunięciu migawki.

Porównaj wynik z mechanizmem zatrzymywania migawki opisanym w artykule mechanizm zatrzymywania podczas tworzenia migawki. Powtórz test bez migawki i przy różnych okresach retencji, utrzymując stałe wersję bazy danych, indeks, dane, kompresję, ustawienia puli i obciążenie w tle. Tę granicę należy sprawdzić na reprezentatywnych danych domowych, a nie zakładać jej z góry.

Planuj migawki i kompaktowanie na podstawie zmierzonego zapasu miejsca, a nie wygody. Zachowaj spójny z bazą danych punkt przywracania, zarezerwuj miejsce na stare i nowe segmenty oraz wygaszaj migawki wyłącznie zgodnie z ustaloną polityką retencji, zamiast usuwać ochronę w celu ukrycia błędów w planowaniu pojemności.