Spis treściKliknij link, aby przejść do wybranego miejsca
Ta treść została automatycznie przetłumaczona z ukraińskiego.
Baza danych szeregów czasowych to typ magazynu, zoptymalizowany do danych związanych z czasem. Każdy rekord w takim systemie ma znacznik czasowy, a czas jest główną cechą, według której te dane są przechowywane, odczytywane i analizowane. Takie bazy danych są stworzone do dużych strumieni zdarzeń, które nieustannie napływają i głównie nie zmieniają się po zapisaniu.
Takie bazy stosuje się w monitorowaniu serwerów, systemach finansowych, analizie ruchu internetowego, urządzeniach IoT lub w jakichkolwiek procesach, gdzie ważne jest obserwowanie dynamiki wskaźników. Na przykład, zmiany obciążenia procesora w ostatnich godzinach, temperatura czujnika co sekundę czy wahania indeksu giełdowego w ciągu dnia.
Bazy danych szeregów czasowych zapewniają szybkie odczyty dużych zakresów czasowych, efektywne agregacje, kompresję oraz możliwość szybkiego usuwania starych danych bez uszczerbku dla wydajności.
Wśród popularnych realizacji znajdują się InfluxDB, TimescaleDB, Prometheus, VictoriaMetrics, a nawet Elasticsearch, który często jest używany do analizy szeregów czasowych dzięki swojej zdolności do szybkiego indeksowania zdarzeń i wykonywania zapytań agregacyjnych. To sprawia, że takie bazy są niezastąpione dla systemów monitorowania, analizy i pracy z danymi o wysokiej częstotliwości, gdzie czas jest kluczowym czynnikiem.
MySQL i PostgreSQL można używać do szeregów czasowych, ale źle skalują się pod takie obciążenia. Powód nie leży w tym, że są "złe", ale w tym, że ich architektura nie jest przystosowana do bardzo częstych wstawek i ogromnych ilości danych, zorganizowanych właśnie według czasu.
Dlaczego MySQL i PostgreSQL nie nadają się do szeregów czasowych
W klasycznych relacyjnych bazach danych rekordy są przechowywane w tabelach, a indeksy - w drzewach B (B-tree). Kiedy dane są nieustannie dodawane w czasie (co sekundę lub nawet co milisekundę), indeks zaczyna szybko "puchnąć", segmenty pamięci fragmentują się, a częste INSERT-y tworzą obciążenie na blokowanie stron i dziennik transakcji. W rezultacie baza zaczyna zwalniać, szczególnie gdy dane są mierzone nie w milionach, ale w setkach milionów lub miliardach wierszy.
Drugim niedociągnięciem są agregacje na dużych zakresach czasowych. Na przykład, uzyskanie "średniej temperatury za trzy miesiące" w MySQL czy PostgreSQL to powolne skanowanie ogromnej tabeli. W bazach danych szeregów czasowych te operacje są wykonywane natychmiast, ponieważ są od razu zoptymalizowane pod kątem zapytań zakresowych i przechowują dane w formacie, który łatwo się agreguje.
Kolejnym problemem jest usuwanie starych danych. W PostgreSQL powoduje to masywny bloat i wymaga VACUUM, które nieustannie obciąża system. W MySQL sytuacja nie jest lepsza: gdy usuwana jest duża liczba starych rekordów, tabele i indeksy stają się fragmentowane, a wydajność spada. W bazach danych szeregów czasowych to jest rozwiązane architektonicznie: stare dane są przechowywane w oddzielnych "kawałkach" i po prostu odrzucane całymi blokami bez obciążenia.
Również w zwykłych bazach SQL nie ma efektywnego kompresowania danych, zoptymalizowanego właśnie dla sekwencji wartości w czasie. W magazynach szeregów czasowych (InfluxDB, VictoriaMetrics, Prometheus) kompresja pozwala przechowywać te same dane 5–20 razy bardziej kompaktowo.
Podsumowując: MySQL/PostgreSQL doskonale radzą sobie z klasycznymi danymi transakcyjnymi, ale przy dużych strumieniach telemetrii, logów lub wskaźników czujników ich wydajność szybko spada. Bazy danych szeregów czasowych zostały stworzone specjalnie dla takiego obciążenia: optymalizują zapis, przechowywanie, odczyt i usuwanie danych, związanych z czasem.
Ten post nie ma jeszcze żadnych dodatków od autora.
