TSDB – Time Series DataBase jako optymalne rozwiązanie dla przetwarzania wpisów logów i IoT

Bazy danych szeregów czasowych (TSDB) są przeznaczone do efektywnego przetwarzania punktów danych oznaczonych konkretnym puntem w czasie. Model danych jest najważniejszą częścią każdego systemu zarządzania danymi, ale różne TSDB przyjmują różne modele danych. Aby pomóc Ci we wdrożeniu odpowiedniego TSDB dla swojej aplikacji, ten artykuł porównuje modele danych kilku popularnych TSDB: InfluxDB, TDengine, Timescale, Prometheus, OpenTSDB i QuestDB. Na rynku jest dostępnych dużo rozwiązań. TSDB to jedno z lepszych i popularniejszych podejść do przechowywania dużej liczby danych i przetwarzania ich w niezwykle wydajny sposób, zbieranych w ramach monitoringu, czy sensorów składowych systemów smart city. Zbiór danych szeregów czasowych musi zawierać sekwencję metryk oznaczonych czasem. Metryki są zawsze generowane przez pojedyncze urządzenie, czujnik lub agenta zbierającego dane – określanego jako punkt zbierania danych (DCP). Każdy DCP ma statyczne atrybuty - te atrybuty traktowane są jako etykiety lub tagi. Tagi to dane wymiarowe i mogą być używane do filtrowania, grupowania i dopasowywania szeregów czasowych do analizy danych i podlegają indeksowaniu. Jako przykład zilustrowania podejścia typu Time Series zaproponuje wykorzystanie samochodów z modułami przekazującymi swoją pozycję. Każdy pojazd periodycznie zgłasza swoją pozycję GPS (współrzędne x, y, z oznaczające współrzędne geograficzne wraz z wysokością) do serwera. Każdy pojazd ma swój unikalny numer identyfikacyjny pojazdu (VIN), markę i model – to będą atrybuty statyczne. Poszczególne rozwiązania charakteryzują się różnym podejściem do modelu danych. Podczas gdy Timescale, TDengine i QuestDB przyjmują model danych relacyjnych, OpenTSDB, Prometheus i InfluxDB przyjmują model danych zestawu tagów. Model danych zestawu tagów W modelu danych zestawu tagów każda seria czasowa jest jednoznacznie identyfikowana przez nazwę metryki (pomiar w nomenklaturze InfluxDB) i zestaw tagów. W naszym przykładzie z samochodami każda seria czasowa jest identyfikowana przez współrzędne GPS + VIN + Marka + Model. Dla Prometheus lub OpenTSDB seria czasowa dla połączonych pojazdów może być zapisana tak: gps_x { vin”Numer_VIN_1”, marka”Opel”, model”Corsa”} gps_y { vin” Numer_VIN_1”, marka” Opel”, model”Corsa”} gps_z { vin” Numer_VIN_1”, marka” Opel”, model”Corsa”} W przypadku InfluxDB, ta sama seria czasowa może być zapisana jako następująca: gps, vin Numer_VIN_1, markaOpel, modelCorsa Model zestawu tagów przypomina NoSQL, gdzie nie jest wymagane definiowanie schematu ani indeksów. Indeksy na tagach są tworzone automatycznie, a indeksy na metrykach w ogóle nie są tworzone. W rzeczywistości główną wadą modelu zestawu tagów jest to, że nie pozwala na tworzenie indeksów na metrykach. Z drugiej strony, zapis do bazy danych jest bardzo prosty i dość łatwo można prototypować proste aplikacje. Takie podejścia pomaga w szybkich tworzeniu rozwiązań i z tego powodu jest tak często pierwszym wyborem programistów. Aby agregować wiele serii czasowych, należy zastosować odpowiedni filtr dla zestawu tagów. Jeśli dodamy kolejny tag lub zmienimy wartość tagu, jest traktowany jako inna seria czasowa. Chociaż zwykle tagi nie są zmieniane, w miarę rozwoju IoT i zwiększania się złożoności urządzeń zdolnych do zbierania większej ilości danych, można przewidywać, że tagi będą faktycznie dodawane dość często. W naszym prostym scenariuszu pojazdów, jeśli dodamy kolor jako kolejny wymiar analizy, model zestawu tagów traktuje go jako nową serię czasową, mimo że tak naprawdę nią nie jest. Ponadto, w modelu zestawu tagów, tagi są zawsze traktowane jako ciągi znaków, i nie są obsługiwane żadne inne typy danych. Uniemożliwia to filtrowanie z wykorzystaniem zakresów liczbowych czy innych operacji np. na zbiorach danych. Inną wadą modelu danych zestawu tagów jest to, że język zapytań jest zawsze inny dla każdego z rozwiązań i utrzymywany przez producenta rozwiązania. Np. w poprzedniej wersji języka zapytań InfluxDB była podobna do SQL (wiele osób traktowało to jako duży plus). Najnowsza wersja ma już inny, własny językiem zapytań – Flux. Szkoda, że twórcy tego typu rozwiązań TSDB nie zdecydowali się na jakąś formę unifikacji. Model Danych Relacyjnych W aplikacjach używających modelu danych relacyjnych, schemat jest zawsze definiowany na początku. W przypadku danych szeregów czasowych zawsze istnieje kolumna z czasem. Dodatkowo, każda metryka ma dedykowaną kolumnę i typ danych. Istnieją zalety tego podejścia: na przykład, projektowanie schematu jest przydatne w walidacji danych wejściowych użytkownika. Wymaganie zaprojektowania schematu na początku projektu zmusza programistów do przemyślenia modelu danych, co zmniejsza czas wymagany na późniejszą analizę, zarządzanie zmianami, a także zmniejsza ryzyko nieporozumień i błędów wynikających z interpretacji. Jest to także podejście bardziej „naturalne” dla większości osób z większym stażem w segmencie IT. Jedną z największych zalet modelu danych relacyjnych jest język zapytań – SQL. SQL jest również standardem dla większości z nas. Timescale, TDengine i QuestDB wszystkie obsługują SQL z pewnymi rozszerzeniami. Ponieważ SQL jest obsługiwany, wiele narzędzi analitycznych, narzędzi BI i narzędzi do tworzenia wykresów może być używanych bez wysiłku, a zapytania mogą być ponownie wykorzystywane z małymi lub żadnymi zmianami. Definiowanie schematu jest postrzegane jako przeszkoda przez młodszych programistów przyzwyczajonych do modeli NoSQL – tu jednak warto pamiętać, że możliwe jest zastosowanie automatycznego generowania schematów co może ułatwić i przyspieszyć cały proces. Model danych relacyjnych oczywiście definiuje schemat dla zebranych metryk. Ale TDengine, Timescale i QuestDB radzą sobie z tagami powiązanymi z każdym punktem zbierania danych na różne sposoby. Timescale Dla Timescale musimy stworzyć tabelę do przechowywania zbieranych metryk, a następnie przekształcić tę tabelę w hypertabelę. Ponadto musimy również utworzyć inną tabelę do przechowywania tagów. Jeśli chcemy wykonać podstawowe zapytanie, takie jak agregacja zbioru szeregów czasowych, musimy wykonać operację JOIN między hypertabelą a tabelą tagów. W naszym scenariuszu związanym z pojazdami, wykonane zostaną następujące instrukcje SQL: CREATE TABLE vehicles(vin SERIAL PRIMARY KEY, brand VARCHAR(20), model VARCHAR(20)); CREATE TABLE vehicle_data(time TIMESTAMPTZ NOT NULL, vin SERIAL, x DOUBLE PRECISION, y DOUBLE PRECISION, z DOUBLE PRECISION, FOREIGN KEY (vin) REFERENCES vehicles (vin)); Aby pobrać dane dla konkretnego pojazdu, instrukcja SQL będzie brzmiała: SELECT * FROM vehicle_data WHERE vin”vin1”; SELECT * FROM vehicle_data JOIN vehicles ON vehicle_data.vin vehicles.vin WHERE brand“Opel” AND model”Corsa”; TDengine Zespół TDengine zaprojektował silnik przechowywania szeregowych czasowych, zoptymalizowany pod kątem danych. Aby poprawić ogólną wydajność przechowywania i zapytań, TDengine wymaga tabeli dla każdego punktu zbierania danych. Ponadto TDengine wprowadza nowy koncept zwany supertabelą. Supertabela jest używana do opisania kategorii urządzeń, które generują te same metryki. Jej schemat zawiera dwie części – jedną dla metryk i drugą dla tagów. W naszym scenariuszu związanym z pojazdami, supertabela jest tworzona w następujący sposób: CREATE STABLE vehicle (ts TIMESTAMP, x DOUBLE, y DOUBLE, z DOUBLE) TAGS (brand BINARY(16), model BINARY(16)); Aby utworzyć tabelę dla każdego konkretnego punktu zbierania danych, używamy supertabeli jako szablonu i przypisujemy wartości tagów. CREATE TABLE vin123 USING vehicle TAGS (“Opel”, “Corsa”); W przeciwieństwie do zwykłej tabeli, tabela dla każdego punktu zbierania danych zawiera zestaw tagów. Nazwa tabeli jest unikalna w bazie danych. Ponadto możemy użyć VIN jako nazwy tabeli, ponieważ jedna tabela jest tworzona dla każdego punktu zbierania danych. Aby zapytać o dane konkretnego pojazdu, instrukcja SQL będzie brzmiała: SELECT * FROM vin123; Aby wykonać zapytanie na zbiorze pojazdów, zapytujemy supertabelę zamiast konkretnej tabeli. Instrukcja SQL brzmi: SELECT * FROM vehicle WHERE brand “tesla” AND model “s3”; Nie wymagając niepotrzebnych operacji JOIN, model danych TDengine umożliwia znacznie prostsze zapytania w porównaniu z zapytaniami w Timescale. QuestDB QuestDB łączy tagi i metryki razem w definicji tabeli. Dla scenariusza związanego z pojazdami, tabela jest tworzona w następujący sposób: CREATE vehicle(ts TIMESTAMP, vin SYMBOL, brand SYMBOL, model SYMBOL, x DOUBLE, y DOUBLE, z DOUBLE) Jeśli chcesz wykonać zapytanie na zbiorze pojazdów, instrukcja SQL brzmi: SELECT * FROM vehicle WHERE brand “tesla” AND model “s3”; Jest to proste i bezpośrednie, podobne do TDengine. Aby zapytać o dane konkretnego pojazdu, instrukcja SQL brzmi: SELECT * FROM vehicle WHERE vin "vin1"; Umieszczenie metryk i tagów w jednej tabeli jest naturalne dla modelowania danych, ale stanowi wyzwanie dla wydajności przechowywania i wydajności zapytań. Kolumna pojedyncza vs. Wielokolumnowa Prometheus i OpenTSDB przyjmują model pojedynczej kolumny. Każda metryka jest traktowana jako inny szereg czasowy. W naszym scenariuszu związanym z pojazdami, pozycja GPS (współrzędne x, y i z) wymaga trzech szeregów czasowych. Chociaż koncepcja pojedynczej kolumny jest łatwa do zrozumienia i dość elastyczna, to zużywa znacznie więcej zasobów. W naszym przykładzie związanym z pojazdami, współrzędne x, y dotyczące pozycji oraz znacznika czasu - to podwaja wielkość danych zarówno w pamięci RAM, jak i na dysku. Odczytanie pozycji GPS wymaga odczytu z trzech szeregów czasowych, co prowadzi do znacznie dłuższych opóźnień. InfluxDB, TDengine, Timescale i QuestDB obsługują model wielokolumnowy. Zazwyczaj szereg czasowy zawiera wiele metryk, które dzielą ten sam znacznik czasu. Obsługa wielu kolumn oszczędza zasoby, ponieważ znacznik czasu jest przechowywany tylko raz. Ponadto obniża ilość potrzebnych do przetworzenia i przechowywania szeregów czasowych, co redukuje rozmiar metadanych i opóźnienia. QuestDB przechowuje każdą kolumnę jako osobny plik i dlatego obsługuje ogromną liczbę kolumn w tabeli. Timescale obecnie obsługuje tylko 1600 kolumn, podczas gdy TDengine obsługuje „tylko” 4096. W wielu scenariuszach metryki są ze sobą powiązane. Na przykład, w naszym poprzednim scenariuszu związanym z pojazdami, współrzędne x, y i z pozycji GPS są połączone; dla inteligentnego licznika energii, prąd i napięcie są powiązane; oraz w scenariuszach monitorowania środowisk serwerowych/ sieciowych, objętość ruchu przychodzącego i wychodzącego jest mierzona w tym samym czasie, a zużycie CP i pamięci jest próbkowane w tym samym czasie. Nie ma sensu oddzielać tych danych na osobne szeregi czasowe. W niektórych scenariuszach, zebrane metryki mogą często się zmieniać, co utrudnia zdefiniowanie schematu na początku projektu. Chociaż pojedyncza kolumna jest dobrym wyborem ze względu na elastyczność, dla większości scenariuszy, takich jak nasz przykład - pozycja GPS, inteligentne liczniki energii, dane finansowe i wiele innych, metryki są bardzo wyraźnie zdefiniowane. W tych przypadkach model wielokolumnowy jest lepszym wyborem, aby oszczędzić zasoby systemu i zmniejszyć opóźnienia. Dla zwiększenia elastyczności i wydajności oba modele: pojedynczej i wielokolumnowej mogą być używane razem, jak to ma miejsce w TDengine. Typy danych Prometheus i OpenTSDB obsługują tylko typy danych liczbowych, podczas gdy TDengine, Timescale, InfluxDB i QuestDB obsługują typy liczbowe i wiele innych typów danych. W niektórych przypadkach użycia, takich jak monitorowanie infrastruktury IT, typy danych liczbowe są ogólnie wystarczające. Jednak w znacznej większości - takich jak IoT są one niewystarczające. Podsumowanie Dla programistów, którzy są bardziej przyzwyczajeni do modeli NoSQL, model zestawu tagów jest dość łatwy i intuicyjny - nie wymaga definiowania schematu. Jednak ta wczesna prostota może prowadzić do późniejszej złożoności w różnych aspektach, takich jak utrudnienie pracy z tagami. Jak widzieliśmy, język zapytań jest zależny od konkretnego rozwiązania i nie jest ustandaryzowany jak SQL. Prowadzi to do niepotrzebnych godzin nauki i braku możliwości ponownego wykorzystania przy ewentualnej migracji. Jeśli aplikacja wymaga bardziej zaawansowanych funkcji analitycznych lub zewnętrznych wtyczek, lepszym wyborem jest model danych relacyjnych. Widzieliśmy również, że model wielokolumnowy może oszczędzać znaczne zasoby systemu i zmniejszać opóźnienia, podczas gdy model pojedynczej kolumny jest bardziej elastyczny, aby dostosować się do zmian schematu. Najlepszą praktyką dla rozwijającego się świata IoT jest połączenie modelu wielokolumnowego i pojedynczej kolumny w jednej platformie. Jeśli chodzi o typy danych, wymagania zależą od scenariusza; jeśli przypadek użycia ma dane nie-liczbowe, nie jest możliwe użycie rozwiązania TSDB (Time Series Database), które nie obsługuje ciągów znaków lub innych typów. Na sam koniec zaznaczę, że nasze wdrożenia najczęściej opieramy o InfluxDB. Dodatkowym poza już wspomnianymi wcześniej argumentami dla nas było przy wyborze i pierwszych projektach ważna była jakość dokumentacji. Zachęcam do samodzielnego przetestowania wymienionych powyżej rozwiązań TSDB.s

TECHNOLOGIA · CYBERBEZPIECZEŃSTWO · BIZNES

TSDB – Time Series DataBase jako optymalne rozwiązanie dla przetwarzania wpisów logów i IoT

Czytaj więcej

Najnowsze

Nowa funkcja Google Play daje ci 24 godziny na decyzję

Nowość w dokumentach Google

Ta oferta może się spodobać – rozmowa o AMS System

Na tę zmianę w Google Maps wielu czekało od dawna

Płatność Huawei Watch dostępna w Polsce

O nas

TECHNOLOGIA · CYBERBEZPIECZEŃSTWO · BIZNES

TSDB – Time Series DataBase jako optymalne rozwiązanie dla przetwarzania wpisów logów i IoT

Czytaj więcej

ARTYKUŁY POWIĄZANE

Najnowsze

O nas