Jak duży narzut na przestrzeń dyskową dodaje Home Assistant w porównaniu z danymi źródłowymi?

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.

Home Assistant nie dodaje uniwersalnego mnożnika pamięci masowej; narzut zależy od częstotliwości zdarzeń, przechowywanej historii, statystyk, indeksów, logów, kopii zapasowych, dodatków i tymczasowej przestrzeni roboczej.

Czujnik temperatury może wysyłać niewielkie wartości, jednak ich zmiany mogą stać się stanami ze znacznikami czasu, atrybutami, wpisami indeksów, agregatami, kopiami zapasowymi i metadanymi systemu plików. Klipy z kamer lub dane dodatków mogą zajmować najwięcej miejsca z zupełnie innych powodów. Dlatego przydatne oszacowanie rozdziela poszczególne role pamięci masowej i mierzy ich dzienny przyrost w oparciu o rzeczywistą liczbę encji w gospodarstwie domowym, częstotliwość aktualizacji, okres przechowywania, poziom logowania i zasady tworzenia kopii zapasowych.

Wartości źródłowe stają się uporządkowanymi danymi Rejestratora

Dane źródłowe to tylko wartość docierająca z urządzenia lub integracji. Rejestrator przechowuje wybrane zmiany stanów i zdarzenia wraz z czasem, odwołaniami do encji, atrybutami i strukturą relacyjną, aby historia i inne funkcje mogły je odpytywać. Dlatego krótki odczyt, taki jak 21.4, zajmuje więcej miejsca niż wynikałoby z widocznej liczby znaków, gdy uwzględni się strony bazy danych i relacje.

Home Assistant przechowuje surowe stany obok krótkoterminowych i długoterminowych postaci statystycznych. To szczegółowe wyjaśnienie modelu bazy danych i statystyk pokazuje, dlaczego zajętość pamięci zależy od częstotliwości zmian i reguł agregacji, a nie od nominalnego rozmiaru danych czujnika.

Ta pierwsza warstwa jest zwykle zależna od częstotliwości: często zmieniające się encje generują więcej wierszy niż encje stabilne, a rozbudowane atrybuty mogą dodatkowo zwiększyć tę różnicę. Tysiąc encji nie oznacza takiego samego zużycia pamięci w każdym domu. Do przewidywania narzutu potrzebne są zmiany dziennie, liczba przechowywanych dni i średni wpływ przechowywanego wiersza, a nie tylko liczba encji.

Indeksy i strony bazy danych dodają przestrzeń strukturalną

Relacyjna baza danych potrzebuje struktur, które zapewniają trwałość i możliwość wyszukiwania wierszy. Strony tabel, indeksy, wolne strony, dzienniki i logi zapisu z wyprzedzeniem mogą zajmować miejsce poza logiczną zawartością wierszy. Struktury te poprawiają spójność i wydajność zapytań, ale ich rozmiar nie zawsze zmniejsza się natychmiast po usunięciu starej historii.

SQLite przechowuje tabele i indeksy na stronach o stałym rozmiarze, dlatego rozmiar fizyczny odzwierciedla przydział stron, a nie prostą sumę długości pól. Przystępny przewodnik po układzie stron SQLite wyjaśnia, jak rekordy, indeksy i wolne miejsce współistnieją w pliku bazy danych.

Powstają więc dwa różne pomiary: logicznie przechowywane dane i fizycznie przydzielona pamięć. Czyszczenie może zmniejszyć pierwszą wartość bez natychmiastowego zmniejszenia drugiej, a operacja konserwacyjna może potrzebować dodatkowego tymczasowego miejsca, zanim zwolni przestrzeń. Planowanie pojemności musi uwzględniać zapas roboczy i nie traktować bieżącego pliku bazy danych jako maksymalnego możliwego zapotrzebowania.

Statystyki wymieniają szczegółowość na długoterminowe przechowywanie

Historia krótkoterminowa zachowuje szczegółowe zmiany przez ograniczony czas, podczas gdy statystyki długoterminowe przechowują kompaktowe agregaty dla obsługiwanych encji numerycznych. Agregacja zmniejsza tempo przyrostu danych na encję w porównaniu z przechowywaniem każdego surowego stanu bezterminowo, ale tworzy kolejny trwały zbiór danych, którego czas życia różni się od zwykłej historii.

Model danych Home Assistant może zatem jednocześnie zawierać surowe stany, krótkoterminowe próbki statystyczne i godzinowe podsumowania długoterminowe. Praktyczny podział przedstawiony w tym artykule o integracjach szeregów czasowych pokazuje, dlaczego analiza historyczna często wprowadza dodatkową rolę pamięci wykraczającą poza potrzeby bieżących stanów kontrolera.

Wynik zależy od sytuacji: dom z wieloma stabilnymi encjami binarnymi może mieć niewielki narzut statystyczny, podczas gdy czujniki energii i środowiskowe mogą przez długi czas gromadzić agregaty. Statystyki długoterminowe nie są duplikatem surowej historii; zachowują wartość analityczną o mniejszej rozdzielczości. Należy szacować je jako osobny dzienny przyrost, zamiast włączać je do jednego niewyjaśnionego mnożnika bazy danych.

Logi, kopie zapasowe i warstwy kontenerów zwielokrotniają zajętość

Pamięć masowa Home Assistant obejmuje więcej niż Rejestrator. Logi mogą rosnąć podczas powtarzających się błędów lub sesji debugowania. Kopie zapasowe mogą kopiować bazę danych, konfigurację, stan dodatków i wybrane foldery współdzielone. Wdrożenia kontenerowe przechowują również obrazy, warstwy zapisywalne, wolumeny, a czasem stare wersje lub pamięć podręczną kompilacji na tym samym dysku systemowym.

Zużycie miejsca przez Docker jest rozłożone na kilka magazynów, a nie na jeden katalog aplikacji. Ten przewodnik po miejscu na dysku Dockera rozdziela obrazy, kontenery, wolumeny i pamięć podręczną, pomagając wyjaśnić, dlaczego przyrost zajętości systemu plików może przekroczyć widoczny folder danych Home Assistant.

Okres przechowywania kopii zapasowych zwielokrotnia wybrane dane przez liczbę kopii, ale kompresja i sposób przyrostowy mogą zmienić dokładny współczynnik. Baza danych o rozmiarze 2 GB nie oznacza, że każda kopia zapasowa doda dokładnie 2 GB, podobnie jak mały folder konfiguracji nie gwarantuje, że kopie pozostaną niewielkie. Należy niezależnie mierzyć zawartość archiwów i liczbę przechowywanych generacji.

Tymczasowa przestrzeń tworzy szczyt powyżej stanu ustalonego

Konserwacja bazy danych, tworzenie kopii zapasowych, dekompresja, aktualizacje, pobieranie obrazów i migracje mogą wymagać tymczasowego miejsca, gdy stare i nowe postacie danych współistnieją. Łatwo tego nie zauważyć, ponieważ miejsce znika po pomyślnym zakończeniu operacji. Staje się to problemem z niezawodnością, gdy zadanie potrzebuje wolnych bloków do ukończenia, a dane w stanie ustalonym zajmują już większość dysku.

Główna baza danych SQLite i WAL mogą zachowywać przydzielone miejsce do czasu spełnienia warunków punktu kontrolnego lub kompaktowania. Analiza wydajności przyrostu plików SQLite wyjaśnia, dlaczego baza danych i log zapisu z wyprzedzeniem mogą rosnąć inaczej niż logiczne dane widoczne dla aplikacji.

Wymagany szczyt zależy od operacji. Przepisanie bazy danych może wymagać miejsca powiązanego z jej rozmiarem, a aktualizacja obrazu może tymczasowo zachować zarówno stare, jak i nowe warstwy. Wskazówki ZimaSpace dotyczące wolnego miejsca na zadania Home Assistant przedstawiają progi operacyjne po zidentyfikowaniu składników narzutu.

Gdzie pojedynczy współczynnik narzutu zawodzi

Stały procent zawodzi, gdy dominuje jeden składnik. Logowanie debugowania może podczas pętli błędów rozrosnąć się bardziej niż Rejestrator; lokalne multimedia z kamer mogą przyćmić każdą tabelę bazy danych; duży dodatek może powiększyć własny wolumen; a długi okres przechowywania kopii zapasowych może sprawić, że kopie będą większe niż aktywne dane stanu. Zmiany obciążenia sprawiają również, że wczorajszy współczynnik szybko traci aktualność.

Poradniki dotyczące wyczerpania miejsca w kontenerach rozdzielają obrazy, warstwy zapisywalne, logi, wolumeny i pamięć podręczną właśnie dlatego, że każdy z tych elementów ma inny mechanizm wzrostu. Pięcioczęściowy wykaz w tej analizie pamięci masowej Dockera pokazuje, dlaczego jedna suma ogólna nie może wskazać źródła mającego największy wpływ.

Współczynnik jest również mylący w przypadku różnych typów instalacji. Home Assistant OS, kontener, maszyna wirtualna i pakiet systemowy na hoście nadzorowanym przechowują dane systemowe w różny sposób. Należy porównywać takie same typy instalacji i wyłączyć multimedia lub dane niezwiązane z aplikacją z obliczeń, chyba że kopia zapasowa Home Assistant albo środowisko uruchomieniowe faktycznie nimi zarządza.

Zbuduj siedmiodniowy model przyrostu pamięci

Ustal jeden punkt bazowy dla plików bazy danych, konfiguracji, logów, kopii zapasowych, wolumenów dodatków, obrazów i warstw kontenerów, multimediów oraz wolnego miejsca. Przez siedem reprezentatywnych dni utrzymuj stałe ustawienia przechowywania i logowania. Codziennie o tej samej porze rejestruj każdy składnik i odnotowuj aktualizacje, ponowne uruchomienia, zadania tworzenia kopii zapasowych, nietypowe błędy lub dodanie urządzeń.

Zarządzanie pamięcią masową zaczyna się od widoczności, ponieważ wolumeny, obrazy, warstwy zapisywalne i pamięć podręczna mają odrębne cykle życia. Ten artykuł o wewnętrznych mechanizmach pamięci masowej Dockera pomaga przypisać zmierzone bajty do trwałych danych aplikacji lub narzutu związanego z pakowaniem środowiska uruchomieniowego.

Oblicz dzienny przyrost dla każdej roli, pomnóż go przez właściwy dla niej okres przechowywania, a następnie dodaj największy zaobserwowany szczyt tymczasowy i rezerwę na odzyskiwanie. Powtórz pomiary po dodaniu integracji lub zmianie ustawień logów, multimediów albo kopii zapasowych. Taki model składnikowy zapewnia uzasadniony zakres pojemności, czego nie może zapewnić uniwersalny mnożnik.

Centrum Technologii i Sztucznej Inteligencji

Więcej do przeczytania

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.