Jeśli korzystasz z bazy danych szeregów czasowych (timeseries db, ) jako główny magazyn strony ze statystykami, to zamiast rozwiązać problem, można dostać sporego bólu głowy. Pracuję nad projektem wykorzystującym taką bazę danych i czasami InfluxDB, o którym będę mowa, prezentował zupełnie nieoczekiwane niespodzianki.
Odpowiedzialność: Wymienione problemy dotyczą InfluxDB w wersji 1.7.4.
Dlaczego szeregi czasowe?
Projekt polega na śledzeniu transakcji na różnych blockchainach i wyświetlaniu statystyk. W szczególności przyglądamy się emisji i spalaniu stabilnych monet (). Na podstawie tych transakcji należy zbudować wykresy i wyświetlić tabele podsumowujące.
Analizując transakcje pojawił się pomysł: jako główny magazyn wykorzystać bazę danych szeregów czasowych InfluxDB. Transakcje są punktami w czasie i dobrze pasują do modelu szeregów czasowych.
Funkcje agregujące również wyglądały na bardzo wygodne – idealne do przetwarzania wykresów o długim okresie. Użytkownik potrzebuje wykresu na rok, a baza danych zawiera zestaw danych z przedziałem czasowym wynoszącym pięć minut. Nie ma sensu wysyłać mu wszystkich stu tysięcy kropek – poza długą obróbką i tak nie zmieszczą się na ekranie. Możesz napisać własną implementację zwiększania przedziału czasowego lub skorzystać z funkcji agregujących wbudowanych w Influx. Za ich pomocą możesz pogrupować dane według dnia i przesłać wymagane 365 punktów.
Trochę mylące było to, że takie bazy danych są zwykle wykorzystywane do gromadzenia metryk. Monitoring serwerów, urządzeń iot, wszystkiego z czego „wypływają” miliony punktów w postaci: [<czas> - <wartość metryki>]. Ale jeśli baza danych działa dobrze przy dużym przepływie danych, to dlaczego mały wolumen miałby powodować problemy? Mając to na uwadze, wzięliśmy do pracy InfluxDB.
Co jeszcze jest wygodne w InfluxDB
Oprócz wspomnianych funkcji agregujących jest jeszcze jedna świetna rzecz - ciągłe zapytania (). Jest to harmonogram wbudowany w bazę danych, który może przetwarzać dane zgodnie z harmonogramem. Na przykład co 24 godziny możesz grupować wszystkie rekordy z danego dnia, obliczać średnią i zapisywać jeden nowy punkt w innej tabeli bez wpisywania własnych rowerów.
istnieje również zasady retencji () – ustawienie usunięcia danych po upływie określonego czasu. Przydaje się, gdy np. trzeba przechowywać obciążenie procesora przez tydzień z pomiarami raz na sekundę, ale na dystansie kilku miesięcy taka dokładność nie jest potrzebna. W takiej sytuacji możesz zrobić tak:
- utwórz ciągłe zapytanie w celu agregacji danych w innej tabeli;
- w przypadku pierwszej tabeli zdefiniuj zasady usuwania metryk starszych niż ten sam tydzień.
A Influx samodzielnie zmniejszy rozmiar danych i usunie niepotrzebne rzeczy.
O przechowywanych danych
Przechowywane jest niewiele danych: około 70 tysięcy transakcji i kolejny milion punktów z informacjami rynkowymi. Dodawanie nowych wpisów - nie więcej niż 3000 punktów dziennie. Istnieją również metryki dla witryny, ale danych jest tam niewiele i zgodnie z polityką przechowywania są one przechowywane nie dłużej niż miesiąc.
Problemy
W trakcie rozwoju i późniejszych testów usługi pojawiały się coraz bardziej krytyczne problemy w działaniu InfluxDB.
1. Usuwanie danych
Istnieje szereg danych z transakcjami:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Wynik:
Wysyłam polecenie usunięcia danych:
DELETE FROM transactions WHERE symbol=’USDT’Następnie składam prośbę o otrzymanie już usuniętych danych. I zamiast pustej odpowiedzi Influx zwraca część danych, które powinny zostać usunięte.
Próbuję usunąć całą tabelę:
DROP MEASUREMENT transactionsSprawdzam usunięcie tabeli:
SHOW MEASUREMENTSNie widzę tabeli na liście, ale nowe zapytanie o dane nadal zwraca ten sam zestaw transakcji.
Problem pojawił się u mnie tylko raz, gdyż przypadek usunięcia był odosobnionym przypadkiem. Jednak takie zachowanie bazy danych wyraźnie nie mieści się w ramach „poprawnego” działania. Później znalazłem go otwartego na githubie prawie rok temu na ten temat.
W rezultacie pomogło usunięcie, a następnie przywrócenie całej bazy danych.
2. Liczby zmiennoprzecinkowe
Obliczenia matematyczne wykonywane przy użyciu funkcji wbudowanych w InfluxDB obarczone są błędami dokładności. Nie żeby było to coś niezwykłego, ale jest to nieprzyjemne.
W moim przypadku dane mają element finansowy i chciałbym je przetworzyć z dużą dokładnością. Z tego powodu planujemy zrezygnować z ciągłych zapytań.
3. Zapytania ciągłe nie mogą być dostosowywane do różnych stref czasowych
Serwis posiada tabelę z dziennymi statystykami transakcji. Dla każdego dnia należy zgrupować wszystkie transakcje tego dnia. Jednak dzień każdego użytkownika rozpocznie się o innej godzinie, dlatego zestaw transakcji będzie inny. Według UTC tak zmiany, dla których trzeba agregować dane.
W InfluxDB przy grupowaniu według czasu można dodatkowo określić przesunięcie, np. dla czasu moskiewskiego (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Ale wynik zapytania będzie nieprawidłowy. Z jakiegoś powodu dane pogrupowane według dni zaczną się od roku 1677 (InfluxDB oficjalnie obsługuje przedział czasowy od tego roku):
Aby obejść ten problem, tymczasowo przełączyliśmy usługę na UTC+0.
4. Wydajność
W Internecie istnieje wiele benchmarków porównujących InfluxDB z innymi bazami danych. Na pierwszy rzut oka wyglądały jak materiały marketingowe, ale teraz myślę, że jest w nich trochę prawdy.
Opowiem ci mój przypadek.
Usługa udostępnia metodę API zwracającą statystyki za ostatni dzień. Podczas wykonywania obliczeń metoda trzykrotnie odpytuje bazę danych za pomocą następujących zapytań:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCWyjaśnienie:
- W pierwszym zapytaniu pobieramy ostatnie punkty za każdą monetę z danymi rynkowymi. W moim przypadku osiem punktów za osiem monet.
- Drugie żądanie otrzymuje jeden z najnowszych punktów.
- Trzeci żąda listy transakcji z ostatnich XNUMX godzin, może być ich kilkaset.
Wyjaśnię, że InfluxDB automatycznie buduje indeks na podstawie tagów i czasu, co przyspiesza zapytania. W pierwszej prośbie symbol jest znacznikiem.
Przeprowadziłem test warunków skrajnych tej metody API. Dla 25 RPS serwer wykazał pełne obciążenie sześciu procesorów:
Jednocześnie proces NodeJs w ogóle nie zapewniał żadnego obciążenia.
Szybkość wykonywania spadła już o 7-10 RPS: jeśli jeden klient mógł otrzymać odpowiedź w ciągu 200 ms, to 10 klientów musiało czekać sekundę. 25 RPS to limit, przy którym ucierpiała stabilność; 500 błędów zostało zwróconych klientom.
Przy takiej wydajności nie da się zastosować Influxa w naszym projekcie. Co więcej: w projekcie, w którym trzeba zademonstrować monitorowanie wielu klientom, mogą pojawić się podobne problemy i serwer metryk zostanie przeciążony.
Wniosek
Najważniejszym wnioskiem z nabytych doświadczeń jest to, że bez odpowiedniej analizy nie da się zastosować w projekcie nieznanej technologii. Proste sprawdzenie otwartych problemów na githubie może dostarczyć informacji pozwalających uniknąć wyboru InfluxDB jako głównego magazynu danych.
InfluxDB powinien był dobrze pasować do zadań mojego projektu, ale jak pokazała praktyka, ta baza danych nie spełnia potrzeb i zawiera wiele błędów.
W repozytorium projektu można już znaleźć wersję 2.0.0-beta, możemy mieć tylko nadzieję, że druga wersja będzie miała znaczące ulepszenia. W międzyczasie pójdę przestudiować dokumentację TimescaleDB.
Źródło: www.habr.com