Czy warto przechowywać metadane Immich na dysku SSD, a dane zbiorcze na dysku HDD?

Tak, wdrożenie Immich często korzysta na przechowywaniu bazy danych i wrażliwych na opóźnienia wygenerowanych danych na SSD, podczas gdy duże, oryginalne pliki zdjęć i filmów są przechowywane na HDD, zwłaszcza gdy biblioteka jest znacznie większa niż stan aplikacji. Taki podział jest przydatny tylko wtedy, gdy ścieżki, zapas wolnego miejsca, kopie zapasowe i procedury odzyskiwania pozostają jasne.

Decyzja nie sprowadza się do zasady „szybkie metadane, wolne multimedia”. Immich korzysta z różnych ról pamięci masowej w odmienny sposób: PostgreSQL obsługuje wiele niewielkich operacji na stanie; miniatury i podglądy są często odczytywane podczas przeglądania; zakodowane filmy mogą być duże; oryginały wymagają pojemności i trwałości. Przed przeniesieniem czegokolwiek zmierz te role osobno.

Oddziel często używany stan z małymi operacjami wejścia-wyjścia od multimediów wymagających dużej pojemności

Spisz dane PostgreSQL, miniatury, podglądy, zakodowane filmy, pamięć podręczną modeli, przesłane oryginały, biblioteki zewnętrzne i kopie zapasowe. Zanotuj bieżący rozmiar, tempo przyrostu, częstotliwość odczytu i zapisu, koszt odbudowy oraz to, czy dana kategoria musi przetrwać przywracanie. Dzięki temu ogólna etykieta folderu „metadane” nie ukryje kilku bardzo różnych obciążeń.

Struktura pamięci masowej ZimaSpace dotycząca umieszczania metadanych multimediów i aktywnej pamięci podręcznej uwypukla istotne rozróżnienie: bazy danych i indeksy korzystają z pamięci masowej o małych opóźnieniach, natomiast duże pliki źródłowe mogą pozostać na pamięci o dużej pojemności, jeśli sposób dostępu do nich nie wymaga takiej samej liczby operacji wejścia-wyjścia na sekundę. Jeśli bieżący HDD charakteryzuje się małymi opóźnieniami podczas wyszukiwania, przeglądania osi czasu i zadań w tle, przeniesienie wszystkich plików pochodnych na SSD może przynieść niewielką, odczuwalną dla użytkownika korzyść. Pozostaw obecny układ do czasu, aż kontrolowane porównanie wykaże, że aktywna ścieżka pamięci masowej rzeczywiście oczekuje.

Umieść PostgreSQL i często odczytywane pliki pochodne na SSD, gdy to one powodują opóźnienia

PostgreSQL i przeglądanie z dużą liczbą miniatur generują wiele niewielkich odczytów i zapisów, które mogą działać wolno na zajętym dysku mechanicznym, szczególnie gdy importy lub kopie zapasowe korzystają z tego samego urządzenia.

W obecnych układach Immich przechowuj bazę danych na lokalnej pamięci masowej o małych opóźnieniach, a obsługiwane ścieżki wygenerowanych danych przenoś rozważnie, zamiast tworzyć dowolne zagnieżdżone punkty montowania.

Mechanizm pamięci masowej jest dobrze opisany poza Immich: dostrajanie pamięci masowej PostgreSQL korzysta z dostępu losowego znacznie tańszego pod względem czasu niż w przypadku dysków talerzowych. Nie gwarantuje to widocznej poprawy w Immich, ale wyjaśnia, dlaczego baza danych i operacje na indeksach są dobrymi kandydatami do przeniesienia na SSD, gdy zmierzone opóźnienie urządzenia jest przyczyną oczekiwania.

Zmierz poprawę, korzystając przed przeniesieniem i po nim z tego samego albumu oraz tej samej próbki wyszukiwania i importu. Jeśli opóźnienie bazy danych spadnie, ale żądanie widoczne dla użytkownika nadal będzie czekać na transfer sieciowy, dekodowanie obrazu lub uczenie maszynowe, przestań przypisywać pozostałe opóźnienie HDD.

Pozostaw oryginały na HDD, gdy pojemność i ochrona są ważniejsze niż losowe operacje wejścia-wyjścia

Oryginalne zdjęcia i filmy zwykle stanowią największą kategorię danych i często są odczytywane jako całe pliki, a nie jako małe, losowe strony bazy danych. Duże pule HDD mogą więc być rozsądnym miejscem na oryginały, jeśli zapewniają wymaganą niezawodność, przepustowość i pojemność kopii zapasowych. Warstwa HDD nadal potrzebuje wolnego miejsca oraz stabilnych opóźnień podczas jednoczesnego importowania i przeglądania.

Trwająca od dawna dyskusja dotycząca oddzielenia pamięci miniatur od multimediów w Immich odzwierciedla tę samą potrzebę operacyjną: wygenerowane zasoby używane podczas przeglądania i duże oryginały mają różne priorytety dostępu. Nie dowodzi to, że każda instalacja potrzebuje dwóch fizycznych urządzeń; korzyść zależy od tego, gdzie obecnie oczekują żądania.

Nie umieszczaj niezastąpionych oryginałów na HDD wyłącznie dlatego, że jest tańszy, a następnie nie traktuj macierzy RAID jako kopii zapasowej. Przechowuj drugą kopię oraz kopię poza hostem lub w trybie offline, zgodnie z wymaganym poziomem ochrony domowej. Warstwowanie pamięci masowej zmienia wydajność i koszty, ale nie zmniejsza skutków utraty jedynej kopii rodzinnej biblioteki.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Przenoś jedną kategorię danych naraz i testuj punkty montowania po ponownym uruchomieniu

Przed przeniesieniem ścieżki utwórz spójną z bazą danych kopię zapasową i zapisz bieżącą mapę montowania host–kontener. Przenieś jedną kategorię, uruchom stos, sprawdź stare i nowe zasoby, wykonaj wyszukiwanie, odtwórz film, prześlij plik testowy i potwierdź, że nowe zapisy trafiają na właściwe urządzenie. Nie przenoś bazy danych, miniatur, oryginałów i miejsc przechowywania kopii zapasowych w ramach jednej zmiany.

Uruchom ponownie hosta, zamiast tylko odtwarzać kontenery. Działający układ rozdzielony uruchamia punkty montowania SSD i HDD przed rozpoczęciem zapisu przez Immich, zachowuje użytkowników i relacje, odczytuje przykładowe oryginały oraz monitoruje wolne miejsce na obu warstwach. Pusty katalog zastępczy w oczekiwanym punkcie montowania jest sygnałem do zatrzymania. Zachowaj podział, gdy zmierzone wąskie gardło ulegnie poprawie, a mapa odzyskiwania pozostanie zrozumiała. Wycofaj zmianę, jeśli układ wprowadzi nieaktualne ścieżki, brakujące zasoby, rozbieżności uprawnień lub proces tworzenia kopii zapasowych chroniący tylko jedną warstwę. Najlepszy projekt pamięci masowej to najszybszy projekt, który nadal potrafisz prawidłowo odtworzyć.