Database
 sql >> Baza danych >  >> RDS >> Database

Wprowadzenie do baz danych szeregów czasowych

Dawno minęły czasy, w których „baza danych” była pojedynczym systemem zarządzania relacyjną bazą danych, instalowanym zazwyczaj na najpotężniejszym serwerze w centrum danych. Taka baza obsługiwała wszelkiego rodzaju zapytania - OLTP, OLAP, wszystko, czego wymaga biznes. Obecnie bazy danych działają na zwykłym sprzęcie, są też bardziej wyrafinowane pod względem wysokiej dostępności i wyspecjalizowane do obsługi określonego rodzaju ruchu. Specjalizacja pozwala im osiągnąć znacznie lepszą wydajność - wszystko jest zoptymalizowane do obsługi określonego rodzaju danych:optymalizator, silnik pamięci masowej, a nawet język nie musi być SQL, jak to było w przeszłości. Może być oparty na SQL z niektórymi rozszerzeniami pozwalającymi na bardziej wydajną manipulację danymi lub może być również czymś zupełnie nowym, stworzonym od podstaw.

Dziś mamy analityczne, kolumnowe bazy danych, takie jak ClickHouse czy MariaDB AX, mamy platformy big data, takie jak Hadoop, rozwiązania NoSQL, takie jak MongoDB czy Cassandra, magazyny danych typu klucz-wartość, takie jak Redis. Posiadamy również bazy danych Time-Series, takie jak Prometheus czy TimeScaleDB. Na tym skupimy się w tym poście na blogu. Bazy danych serii czasowych — czym one są i dlaczego chciałbyś użyć kolejnego magazynu danych w swoim środowisku.

Do czego służą bazy danych szeregów czasowych?

Jak sama nazwa wskazuje, bazy danych szeregów czasowych są przeznaczone do przechowywania danych, które zmieniają się w czasie. Mogą to być dowolne dane, które zostały zebrane w czasie. Mogą to być metryki zebrane z niektórych systemów - wszystkie systemy trendów są przykładami danych szeregów czasowych.

Za każdym razem, gdy patrzysz na pulpity nawigacyjne w ClusterControl, w rzeczywistości patrzysz na wizualną reprezentację danych szeregów czasowych przechowywanych w Prometheus, bazie danych szeregów czasowych.

Dane szeregów czasowych nie ograniczają się do metryk bazy danych. Wszystko może być metryką. Jak zmienia się przepływ osób wchodzących do centrum handlowego? Jak zmienia się ruch w mieście? Jak zmienia się korzystanie z komunikacji miejskiej w ciągu dnia? Przepływ wody w strumieniu lub rzece. Ilość energii wytworzonej przez elektrownię wodną. Wszystko to i wszystko inne, co można zmierzyć w czasie, jest przykładem danych szeregów czasowych. Takie dane można wyszukiwać, wykreślać, analizować, aby znaleźć korelacje między różnymi metrykami.

Jak uporządkowane są dane w bazie danych szeregów czasowych?

Jak możesz sobie wyobrazić, najważniejszą częścią danych w bazie danych szeregów czasowych jest czas. Istnieją dwa główne sposoby przechowywania danych. Po pierwsze, coś, co przypomina pamięć klucz-wartość, może wyglądać tak:

sygnatura czasowa Metryka 1
28.03.2019 00:00:01 2356
2019-03-28 00:00:02 6874
2019-03-28 00:00:03 3245
2019-03-28 00:00:04 2340

Krótko mówiąc, dla każdego znacznika czasu mamy pewną wartość dla naszych danych.

Inny przykład będzie dotyczył większej liczby metryk. Zamiast przechowywać każdą metrykę w osobnej tabeli lub kolekcji, możliwe jest przechowywanie wielu metryk obok.

sygnatura czasowa Metryka 1 Metryka 2 Metryka 3 Metryka 4 Metryka 5
28.03.2019 00:00:01 765 873 124 98 0
2019-03-28 00:00:02 5876 765 872 7864 634
2019-03-28 00:00:03 234 7679 98 65 34
2019-03-28 00:00:04 345 3 598 0 7345

Ta struktura danych pomaga w wydajniejszym zapytaniu o dane, gdy metryki są ze sobą powiązane. Zamiast czytać wiele tabel i łączyć je w celu zebrania wszystkich metryk, wystarczy odczytać jedną tabelę, a wszystkie dane są gotowe do przetworzenia i zaprezentowania.

Możesz się zastanawiać - co tak naprawdę nowego tutaj? Czym różni się to od zwykłej tabeli w MySQL lub innej relacyjnej bazie danych? Cóż, projekt tabeli jest dość podobny, ale istnieją znaczne różnice w obciążeniu, które, gdy magazyn danych jest zaprojektowany do ich wykorzystywania, może znacznie poprawić wydajność.

Dane szeregów czasowych są zazwyczaj tylko dołączane — jest mało prawdopodobne, że będziesz aktualizować stare dane. Zazwyczaj nie usuwasz poszczególnych wierszy, z drugiej strony możesz chcieć pewnego rodzaju agregacji danych w czasie. To, jeśli uwzględnimy to przy projektowaniu wewnętrznych baz danych, będzie miało znaczącą różnicę w stosunku do „standardowych” relacyjnych (a nie relacyjnych również) baz danych przeznaczonych do obsługi ruchu typu Online Transaction Processing:najważniejsza jest możliwość spójnego przechowywania (jngest) duże ilości danych, które napływają z czasem.

Możliwe jest użycie RDBMS do przechowywania danych szeregów czasowych, ale RDBMS nie jest do tego zoptymalizowany. Dane i indeksy wygenerowane z tyłu mogą być bardzo duże i wolno wykonywać zapytania. Aparaty pamięci masowej używane w RDBMS są przeznaczone do przechowywania różnych typów danych. Są one zazwyczaj zoptymalizowane pod kątem obciążenia przetwarzania transakcji online, które obejmuje częste modyfikowanie i usuwanie danych. W relacyjnych bazach danych brakuje również wyspecjalizowanych funkcji i cech związanych z przetwarzaniem danych szeregów czasowych. Wspomnieliśmy, że prawdopodobnie chcesz agregować dane starsze niż określony okres czasu. Możesz również chcieć mieć możliwość łatwego uruchamiania niektórych funkcji statystycznych na danych szeregów czasowych, aby je wygładzić, określić i porównać trendy, interpolować dane i wiele więcej. Na przykład tutaj można znaleźć niektóre funkcje, które Prometheus udostępnia użytkownikom.

Przykłady baz danych szeregów czasowych

Na rynku istnieje wiele baz danych szeregów czasowych, więc nie jest możliwe objęcie ich wszystkich. Nadal chcielibyśmy podać kilka przykładów baz danych szeregów czasowych, które możesz znać, a może nawet używać (świadomie lub nie).

InfluxDB

InfluxDB został stworzony przez InfluxData. Jest to baza danych szeregów czasowych typu open source napisana w Go. Magazyn danych zapewnia podobny do SQL język do wykonywania zapytań o dane, co ułatwia programistom integrację z ich aplikacjami. InfluxDB działa również jako część oferty komercyjnej, która obejmuje cały stos zaprojektowany w celu zapewnienia w pełni funkcjonalnego, wysoce dostępnego środowiska do przetwarzania danych szeregów czasowych.

Prometeusz

Prometheus to kolejny projekt open source, który jest również napisany w Go. Jest powszechnie używany jako backend dla różnych narzędzi i projektów open source, na przykład Percona Monitoring and Management. Prometheus jest również wybraną bazą danych szeregów czasowych dla ClusterControl.

Prometheus może zostać wdrożony z ClusterControl do przechowywania danych szeregów czasowych zebranych na serwerach baz danych monitorowanych i zarządzanych przez ClusterControl:

Szeroko stosowany w świecie open source, Prometheus jest dość łatwy do zintegrowania z istniejącym środowiskiem przy użyciu wielu eksporterów.

Narzędzie RRD

Może to być przykład bazy danych szeregów czasowych, z której wiele osób korzysta, nie wiedząc, że to robi. RRDtool to bardzo popularny projekt open source do przechowywania i wizualizacji danych szeregów czasowych. Jeśli kiedykolwiek używałeś Cacti, było to oparte na RRDtool. Jeśli zaprojektowałeś własne rozwiązanie, jest całkiem prawdopodobne, że używałeś również RRDtool jako backendu do przechowywania danych. Obecnie nie jest tak popularny jak kiedyś, ale w latach 2000 - 2010 był to najczęstszy sposób przechowywania danych szeregów czasowych. Ciekawostka — korzystały z niej wczesne wersje ClusterControl.

Skala czasu

TimeScale to baza danych szeregów czasowych opracowana na bazie PostgreSQL. Jest to rozszerzenie PostgreSQL, które polega na bazowym magazynie danych w celu zapewnienia dostępu do danych, co oznacza, że ​​akceptuje cały kod SQL, którego możesz chcieć użyć. Będąc rozszerzeniem, wykorzystuje wszystkie inne funkcje i rozszerzenia PostgreSQL. Możesz mieszać szeregi czasowe i inne rodzaje danych, na przykład łączyć szeregi czasowe i metadane, wzbogacając dane wyjściowe. Możesz także wykonać bardziej zaawansowane filtrowanie, korzystając z sprzężeń i tabel innych niż szeregi czasowe. Wykorzystanie wsparcia GIS w PostgreSQL TimeScale może być łatwo wykorzystane do śledzenia lokalizacji geograficznych w czasie. Może również wykorzystać wszystkie możliwości skalowania oferowane przez PostgreSQL, w tym replikację.

Strumień czasu

Amazon Web Services ma również ofertę dla baz danych szeregów czasowych. Timestream został ogłoszony całkiem niedawno, bo w listopadzie 2018 roku. Dodaje kolejny datastore do portfolio AWS, tym razem pomagając użytkownikom w obsłudze danych szeregów czasowych pochodzących z takich źródeł jak urządzenia Internetu rzeczy czy monitorowane usługi. Może być również używany do przechowywania metryk pochodzących z dzienników utworzonych przez wiele usług, umożliwiając użytkownikom uruchamianie na nich zapytań analitycznych, pomagając zrozumieć wzorce i warunki, w jakich działają usługi.

Timestream, jak większość usług AWS, zapewnia łatwy sposób skalowania, jeśli potrzeba przechowywania i analizowania danych rośnie z czasem.

Jak widać, na rynku dostępnych jest wiele opcji i nie jest to zaskakujące. Analiza danych szeregów czasowych zyskuje ostatnio coraz większą popularność, staje się coraz bardziej krytyczna dla operacji biznesowych. Na szczęście, biorąc pod uwagę dużą liczbę ofert, zarówno open source, jak i komercyjnych, jest całkiem prawdopodobne, że znajdziesz narzędzie, które będzie odpowiadać Twoim potrzebom.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Tworzenie kopii zapasowych i przywracanie bazy danych z obsługą FILESTREAM

  2. Denormalizacja:kiedy, dlaczego i jak

  3. RMAN nie działa z RMAN-06900 RMAN-06901 ORA-04031

  4. Bramki rzędowe, część 3:przeciw łączeniom

  5. Model danych agencji opinii publicznej