Jak retencja czujników wpływa na pamięć masową serwera inteligentnego domu?

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 Does Sensor Retention Drive Smart Home Server Storage? - Zima Store Online

Przechowywanie danych z czujników napędza pamięć serwera inteligentnego domu, mnożąc liczbę jednostek, częstotliwość próbkowania, narzut na zapisy, wzrost indeksów oraz historię kopii zapasowych w czasie.

Dom może zacząć od kilku jednostek temperatury i ruchu, a następnie dodać liczniki energii, czujniki jakości powietrza, detektory wycieków, kontaktrony drzwiowe, dane pogodowe, telemetrię urządzeń i obliczone statystyki. Każda wartość jest niewielka, ale serwer przechowuje znaczniki czasu, identyfikatory, atrybuty, indeksy, zapisy transakcji i często kilka kopii zapasowych wokół nich. Poniższe sekcje pokazują, dlaczego retencja to decyzja dotycząca cyklu życia danych, a nie proste obliczenie „bajtów na czujnik” oraz gdzie agregacja zmienia długoterminowy wykres.

Wzrost pamięci zaczyna się od próbek na jednostkę czasu

Pierwszą zmienną jest, jak często każda jednostka tworzy nowy rekord. Czujnik temperatury raportujący co pięć minut generuje 288 odczytów dziennie, podczas gdy licznik energii raportujący co pięć sekund – 17 280.

Długoterminowe wdrożenia ESPHome często oddzielają dane czujników o wysokiej częstotliwości od danych historycznych o niższej rozdzielczości. Surowa częstotliwość określa początkowe obciążenie zapisem i ilość szczegółów dostępnych do późniejszej analizy.

Pomnóż częstotliwość raportowania przez liczbę jednostek i okres retencji. Jeden kanał energii o wysokiej częstotliwości może wygenerować więcej wierszy niż dziesiątki powoli zmieniających się czujników kontaktronowych.

Wartość jednego czujnika zajmuje więcej niż tylko swój numeryczny ładunek

Wartość zmiennoprzecinkowa może zajmować tylko kilka bajtów, ale wiersz bazy danych potrzebuje także znacznika czasu, odniesienia do jednostki, pól schematu, miejsca na stronie, metadanych transakcji i czasem powtarzających się atrybutów lub ciągów stanu.

Systemy szeregów czasowych są zoptymalizowane pod kątem rekordów ze znacznikami czasu, ale pamięć nadal obejmuje metadane fragmentów, indeksy, dzienniki zapisu w przód i narzut kompaktacji. Różnica między rozmiarem ładunku a rozmiarem na dysku jest największa, gdy rekordy są rzadkie, tekstowe lub często indeksowane.

Dlatego szacowanie retencji na podstawie „ośmiu bajtów na odczyt” jest niewiarygodne. Prawidłowym pomiarem jest wzrost bazy danych na dzień według rzeczywistego schematu, ustawień rejestratora i mieszanki czujników.

Jednostki z dużą liczbą atrybutów mogą być szczególnie kosztowne, gdy opisowy JSON często się zmienia lub jest duplikowany w wierszach historii.

Indeksy i szybkość zapytań dodają własne koszty pamięci

Historyczne pulpity potrzebują zlokalizować jedną jednostkę w zakresie czasu, porównać kilka czujników i obliczyć dzienne lub miesięczne agregaty. Indeksy przyspieszają te zapytania, przechowując dodatkowe struktury wyszukiwania.

Badanie porównawcze baz danych szeregów czasowych pokazuje, że wydajność zapisu, kompresja, zachowanie zapytań i efektywność pamięci różnią się w zależności od projektu bazy. Układ zoptymalizowany pod szybkie zapytania niedawne może używać więcej zasobów indeksów lub pamięci niż prosty archiwum tylko do dopisywania.

Usunięcie wszystkich indeksów oszczędza miejsce, ale może uczynić wieloletnie wykresy i rozwiązywanie problemów niepraktycznym. Planowanie retencji zatem równoważy surową pojemność z zapytaniami, które dom oczekuje wykonywać.

-15% OFF

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

Single board computer zimaboard2

Surowa retencja i retencja historyczna wymagają różnych rozdzielczości

Ostatnie rozwiązywanie problemów może wymagać odczytu energii co pięć sekund, podczas gdy pięcioletnie porównanie energii może potrzebować tylko sum godzinnych lub dziennych. Przechowywanie obu pytań w surowej rozdzielczości marnuje pojemność bez dodawania użytecznych szczegółów długoterminowych.

Nowoczesne TSDB używają polityk retencji, kompresji i agregacji do starzenia danych przez różne poziomy. Surowe rekordy mogą wygasać po tygodniach lub miesiącach, podczas gdy sumy godzinne, dzienne lub miesięczne pozostają przez lata.

Funkcja agregacji musi odpowiadać czujnikowi. Temperatura może wymagać minimum, maksimum i średniej; liczniki energii mogą wymagać różnic; czujniki kontaktronowe mogą potrzebować czasu trwania lub liczby przejść zamiast średnich arytmetycznych.

Po usunięciu surowych wierszy agregat nie może odtworzyć każdego krótkiego skoku lub zdarzenia. Wybierz agregację dopiero po zdecydowaniu, które przyszłe pytania muszą pozostać możliwe do odpowiedzi.

Kopie zapasowe mnożą zachowany rozmiar bazy danych

Aktywna baza danych to tylko jedna kopia. Zaplanowane migawki, kopie zapasowe aplikacji, migawki systemu plików, repliki, eksportowane archiwa i kopie poza miejscem mogą wielokrotnie zwiększyć efektywne zużycie pamięci przez tę samą historię.

Przechowywanie szeregów czasowych używa częstych zapisów, więc partycje pamięci i wzorce kompaktacji wpływają na to, jak efektywnie migawki zachowują zmiany. System kopii zapasowych, który wielokrotnie kopiuje całą bazę, może rosnąć szybciej niż ten, który przechwytuje bloki przyrostowe lub natywne eksporty.

Retencja powinna być więc zdefiniowana zarówno dla systemu na żywo, jak i jego kopii zapasowych. Usuwanie starych wierszy z aktywnej bazy nie zwalnia miejsca z niezmiennej migawki, dopóki ta nie wygaśnie.

Zmierz dzienny wzrost przed wyborem okna retencji

Uruchom zamierzone czujniki przez co najmniej reprezentatywny tydzień i zanotuj rozmiar bazy danych, dzienną liczbę wierszy, wolumen zapisu, delta kopii zapasowej oraz największe jednostki. Uwzględnij normalne dni robocze, cykle HVAC, urządzenia o dużym zużyciu energii oraz urządzenia, które się ponownie łączą lub wysyłają powtarzające się stany.

Dedykowany magazyn danych długoterminowych może oddzielić szczegółową historię automatyzacji od wieloletniej analityki. Plan przechowywania inteligentnego domu ZimaSpace powinien zarezerwować pojemność dla rejestratora na żywo, agregatów długoterminowych, utrzymania bazy danych i retencji kopii zapasowych jako osobne pozycje.

Przeskaluj zmierzony dzienny wzrost na okres surowej retencji, a następnie dodaj narzut indeksów, wolne miejsce na kompaktację i każdą zachowaną generację kopii zapasowej. To daje próg pojemności oparty na rzeczywistym gospodarstwie domowym, a nie na ogólnej liczbie czujników.

FAQ

Czy czujniki tylko zdarzeniowe zajmują prawie żadnej pamięci?

Zwykle tworzą mniej wierszy niż pomiary o wysokiej częstotliwości, ale powtarzające się atrybuty, niedostępne stany, ponowne połączenia i jednostki generowane przez automatyzację mogą nadal zwiększać rozmiar historii.

Czy kompresja eliminuje potrzebę limitów retencji?

Nie. Kompresja zmniejsza pamięć na rekord, ale nieograniczony strumień nadal rośnie, podobnie jak jego kopie zapasowe, indeksy i okna konserwacji.

Czy cała historia czujników powinna mieć ten sam okres retencji?

Nie. Krótkotrwałe dane diagnostyczne, zdarzenia bezpieczeństwa, statystyki energii i trendy środowiskowe często wymagają różnych rozdzielczości i okien retencji.