Lokalna baza danych Plex a dedykowany host bazy danych: czy separacja poprawia niezawodność?
Dedykowany host bazy danych nie jest zwykłym, bezpośrednim ulepszeniem niezawodności Plex. Plex przechowuje bazę danych aplikacji jako lokalny, osadzony stan, więc przeniesienie tego stanu do udziału sieciowego lub zastąpienie go oddzielnym serwerem bazy danych zmienia założenia, od których zależy działanie aplikacji.
Praktyczny wybór dotyczy niezawodnego lokalnego przechowywania stanu aplikacji, uruchomienia usługi Plex na oddzielnym hoście oraz przetestowanych kopii zapasowych — a nie dwóch wzajemnie wymiennych architektur baz danych.
Zacznij od architektury bazy danych, której faktycznie używa Plex
Plex używa lokalnej bazy danych z rodziny SQLite do śledzenia rekordów biblioteki i jej stanu, zamiast wymagać oddzielnie zarządzanej bazy danych typu klient-serwer. Niezależna analiza potwierdza, że pobrana baza danych Plex jest plikiem SQLite, do którego narzędzia mogą odwoływać się za pomocą ścieżki pliku.
Taka architektura utrzymuje silnik bazy danych wewnątrz procesu aplikacji, a główne pliki bazy danych w pobliżu usługi Plex. „Dedykowany host bazy danych” wymagałby obsługi przez aplikację zdalnego protokołu bazy danych, zachowania schematu, migracji i obsługi awarii; samo utworzenie serwera bazy danych nie zapewnia tych integracji.
Pierwszy wniosek jest zatem jednoznaczny: nie kupuj oddzielnej maszyny do obsługi bazy danych z oczekiwaniem, że Plex połączy się z nią jak typowa aplikacja internetowa. Ulepsz obsługiwaną ścieżkę lokalnego przechowywania stanu albo przenieś całą usługę Plex, jeśli wymagana jest izolacja hosta.
Lokalne przechowywanie bazy danych eliminuje nową zależność sieciową
Bazy danych osadzone w aplikacji zyskują prostotę dzięki lokalnemu dostępowi do plików. Eliminuje to przeskok sieciowy do bazy danych i zależność od jej dostępności; SQLite działający w procesie eliminuje oddzielną usługę bazy danych i ścieżkę awarii sieci.
Używaj responsywnego i sprawnego lokalnego magazynu danych dla katalogu aplikacji Plex, pozostawiaj wystarczającą ilość wolnego miejsca i chroń go przed nagłą utratą zasilania. Zwykle zapewnia to większą niezawodność niż dodanie kolejnego hosta, którego sieć, system operacyjny, dane uwierzytelniające i cykl aktualizacji muszą pozostawać dostępne.
Lokalne nie oznacza „na tym samym dysku co wszystko”. Host Plex może korzystać z dedykowanego lokalnego dysku SSD lub dublowanej puli danych aplikacji, podczas gdy multimedia znajdują się gdzie indziej. Najważniejsze jest, aby baza danych pozostawała na magazynie danych, którego charakterystyka blokad i opóźnień odpowiada oczekiwaniom aplikacji.
Udział sieciowy może obniżyć niezawodność zamiast ją poprawić
Umieszczenie pliku osadzonej bazy danych na NFS lub innym systemie plików dostępnym przez sieć nie jest równoznaczne z użyciem bazy danych klient-serwer. Blokady plików, spójność pamięci podręcznej, opóźnienia i krótkotrwałe rozłączenia trafiają teraz na ścieżkę zatwierdzania operacji. Wskazówki dotyczące SQLite jasno stwierdzają, że sieciowe systemy plików mogą zwiększać opóźnienia i mogą nieprawidłowo implementować blokowanie plików.
Zdalny udział może być doskonałym rozwiązaniem dla dużych plików multimedialnych, ponieważ odtwarzanie toleruje inny sposób dostępu. Dzienniki bazy danych i małe zsynchronizowane zapisy mają bardziej rygorystyczne wymagania dotyczące spójności. Nie należy kopiować jednego projektu przechowywania danych do drugiego tylko dlatego, że oba obejmują pliki związane z Plex.
Odrzuć plan umieszczenia działającej bazy danych Plex na ogólnym udziale sieciowym bez udokumentowanej obsługi aplikacji, zgodnego działania blokad i testów odzyskiwania. Szybsza sieć nie eliminuje problemów semantycznych związanych z blokowaniem ani obsługą rozłączeń.
Spójne kopie zapasowe zapewniają większą niezawodność niż rozdzielenie hostów
Niezawodność oznacza możliwość odtworzenia bazy danych biblioteki, preferencji, grafiki i konfiguracji do znanego punktu w czasie. Kopiowanie aktywnego pliku bazy danych bez obsługi jego dziennika może utworzyć niespójną kopię zapasową; metody tworzenia kopii zapasowych uwzględniające SQLite tworzą kopię z określonego punktu w czasie przy spójnie zarządzanych zapisach.
Korzystaj z obsługiwanej przez aplikację procedury tworzenia kopii zapasowej lub bezpiecznego zamykania, przechowuj wiele wersji, kopiuj je do oddzielnej domeny awarii i okresowo odtwarzaj jedną z nich w lokalizacji testowej. Chroń również cały otaczający katalog danych aplikacji, a nie tylko główną bazę danych, ponieważ użyteczne odzyskiwanie obejmuje więcej niż jeden plik.
Ta praca związana z tworzeniem kopii zapasowych i odtwarzaniem pozostaje konieczna nawet po przeniesieniu całej usługi Plex na inny host. Rozdzielenie może ograniczyć konkurencję o zasoby lub uprościć odbudowę, ale samo w sobie nie zapewnia historycznego odzyskiwania danych.
Oddziel całą usługę Plex tylko dla jasno określonej granicy awarii
Dedykowany host Plex może odizolować aktualizacje, konkurencję o zasoby i przechowywanie stanu aplikacji od niepowiązanych usług. Prawdziwa wysoka dostępność jest jednak większym projektem, ponieważ wysoka dostępność usług przechowujących stan może wprowadzać więcej trybów awarii z powodu dodatkowej złożoności.
Korzystaj z oddzielnego hosta usługi, gdy zmiany na współdzielonym hoście wielokrotnie powodują przestoje, zmierzono konkurencję o zasoby lub zakres odpowiedzialności za odzyskiwanie danych wymaga wyraźnej granicy. Porównanie dedykowanego serwera Plex ze współdzielonym hostem aplikacji pod kątem odzyskiwania danych bezpośrednio omawia ten obsługiwany wybór architektoniczny.
W większości domów kolejność działań pod względem niezawodności wygląda następująco: sprawny lokalny magazyn stanu aplikacji, kontrolowane zamykanie systemu i zasilanie, wersjonowane i spójne kopie zapasowe, przetestowane odtwarzanie, a dopiero potem izolacja usługi na osobnym hoście. Dedykowany host bazy danych nie jest brakującym ogniwem; jest nim jasno określona i przećwiczona ścieżka odzyskiwania.
Polecane produkty
Porównania produktów
Więcej do przeczytania
Procesor czterordzeniowy czy ośmiordzeniowy do Plexa: który lepiej sprawdzi się przy jednoczesnej obsłudze różnych klientów?
Cztery rdzenie wystarczą głównie do bezpośredniego odtwarzania; osiem rdzeni uzasadnia swój koszt, gdy oprogramowanie wykonuje transkodowanie lub równoległe zadania hosta przekraczają zmierzony próg.
Dedykowany serwer Jellyfin a współdzielony host aplikacji: która granica Ci odpowiada?
Wybierz hosting dedykowany, aby zapewnić przewidywalną obsługę multimediów i odzyskiwanie danych; wybierz hosting współdzielony, gdy obciążenia są niewielkie, a izolację można zmierzyć.
Jellyfin kontra Plex w domowym streamingu dla wielu użytkowników: szeroka obsługa klientów czy kontrola?
Plex wygrywa, gdy kluczowy jest zasięg wśród klientów; Jellyfin wygrywa, gdy kluczowa jest kontrola; oba rozwiązania mogą być odpowiednie, gdy użytkownicy wyraźnie się rozdzielają.
