Tworzę system, który sonduje urządzenia w poszukiwaniu danych o różnych parametrach, takich jak wykorzystanie procesora, wykorzystanie dysku, temperatura itp. W (prawdopodobnie) 5-minutowych odstępach przy użyciu SNMP. Ostatecznym celem jest zapewnienie wizualizacji użytkownikowi systemu w postaci wykresów szeregów czasowych.
W przeszłości patrzyłem na używanie RRDTool, ale odrzuciłem go, ponieważ przechowywanie przechwyconych danych w nieskończoność jest ważne dla mojego projektu i chcę wyższego poziomu i bardziej elastycznego dostępu do przechwyconych danych. Tak więc moje pytanie brzmi:
Co więcej, relacyjna baza danych (taka jak MySQL lub PostgreSQL) lub nierelacyjna lub NoSQL (taka jak MongoDB lub Redis) w odniesieniu do wydajności podczas wysyłania zapytań o dane do wykresów.
Relacyjny
Biorąc pod uwagę relacyjną bazę danych, użyłbym data_instances
tabeli, w której zapisano by każde wystąpienie danych przechwyconych dla każdej metryki mierzonej dla wszystkich urządzeń, z następującymi polami:
Pola: id
fk_to_device
fk_to_metric
metric_value
timestamp
Kiedy chcę narysować wykres dla konkretnej metryki na określonym urządzeniu, muszę wykonać zapytanie do tej pojedynczej tabeli, odfiltrowując inne urządzenia i inne metryki analizowane dla tego urządzenia:
SELECT metric_value, timestamp FROM data_instances
WHERE fk_to_device=1 AND fk_to_metric=2
Liczba wierszy w tej tabeli wynosiłaby:
d * m_d * f * t
gdzie d
jest liczbą urządzeń , m_d
oznacza łączną liczbę metryk rejestrowanych dla wszystkich urządzeń, f
jest to częstotliwość, z jaką dane są odpytywane i t
jest to całkowity czas, przez który system zbiera dane.
Dla użytkownika rejestrującego 10 wskaźników dla 3 urządzeń co 5 minut przez rok, mielibyśmy nieco mniej niż 5 milionów rekordów.
Indeksy
Bez indeksowania fk_to_device
i fk_to_metric
skanowania ta ciągle rozwijana tabela zajęłaby zbyt wiele czasu. Zatem indeksowanie wyżej wymienionych pól, a także timestamp
(do tworzenia wykresów ze zlokalizowanymi okresami) jest wymagane.
Nierelacyjny (NoSQL)
MongoDB ma koncepcję kolekcji , w przeciwieństwie do tabel, które można tworzyć programowo bez instalacji. Dzięki nim mogłem podzielić pamięć na dane dla każdego urządzenia, a nawet każdą metrykę zarejestrowaną dla każdego urządzenia.
Nie mam doświadczenia z NoSQL i nie wiem, czy zapewniają one funkcje zwiększające wydajność zapytań, takie jak indeksowanie, jednak w poprzednim akapicie zaproponowano wykonanie większości tradycyjnych relacyjnych zapytań w strukturze, w której dane są przechowywane w NoSQL.
Niezdecydowany
Czy rozwiązanie relacyjne z poprawnym indeksowaniem zredukuje się do indeksowania w ciągu roku? Czy też oparta na zbiorze struktura metod NoSQL (która pasuje do mojego modelu mentalnego przechowywanych danych) zapewnia zauważalną korzyść?
źródło
Odpowiedzi:
Zdecydowanie relacyjny. Nieograniczona elastyczność i ekspansja.
Dwie poprawki, zarówno w koncepcji, jak i zastosowaniu, a następnie rzędna.
Korekta
Nie „odfiltrowuje niepotrzebnych danych”; jest wybranie tylko potrzebne dane. Tak, oczywiście, jeśli masz indeks do obsługi kolumn określonych w klauzuli WHERE, jest on bardzo szybki, a zapytanie nie zależy od wielkości tabeli (pobieranie 1000 wierszy z tabeli o wartości 16 miliardów jest natychmiastowe) .
Twój stół ma jedną poważną przeszkodę. Biorąc pod uwagę twój opis, rzeczywisty PK to (Urządzenie, Metryka, Data i godzina). (Proszę nie nazywać go TimeStamp, co oznacza coś innego, ale jest to drobny problem.) Wyjątkowość wiersza jest identyfikowana przez:
Id
Kolumna nic nie robi, to jest całkowicie i zupełnie zbędne.Id
Kolumna nie jest klucz (zduplikowane wiersze, które są zakazane w relacyjnej bazie danych, należy zapobiegać za pomocą innych środków).Id
Kolumna wymaga dodatkowego Index, co oczywiście utrudnia szybkośćINSERT/DELETE
i dodaje do przestrzeni dyskowej używany.Możesz się go pozbyć. Proszę.
Podniesienie
Teraz, gdy usunąłeś przeszkodę, być może jej nie rozpoznałeś, ale twój stół jest w szóstej normalnej formie. Bardzo duża prędkość, z jednym indeksem na PK. Aby zrozumieć, przeczytaj tę odpowiedź z Co to jest szósta normalna forma? zmierzamy dalej.
(Mam tylko jeden indeks, a nie trzy; w Non-SQLs możesz potrzebować trzech indeksów).
Mam dokładnie ten sam stół (
Id
oczywiście bez „klucza”). Mam dodatkową kolumnęServer
. Zdalnie wspieram wielu klientów.(Server, Device, Metric, DateTime)
Tabeli można użyć do przestawienia danych (tj. U
Devices
góry i naMetrics
dole strony lub przestawnego ) przy użyciu dokładnie tego samego kodu SQL (tak, przełącz komórki). Używam tej tabeli do tworzenia nieograniczonej różnorodności grafów i wykresów dla klientów dotyczących wydajności ich serwerów.Monitoruj model danych statystycznych .
(Zbyt duży, by wstawić; niektóre przeglądarki nie mogą załadować się w treści; kliknij link. Jest to również przestarzała wersja demo, z oczywistych powodów, nie mogę pokazać ci komercyjnego produktu DM)
Pozwala mi to tworzyć takie wykresy , sześć naciśnięć klawiszy po otrzymaniu nieprzetworzonego pliku statystyk monitorowania od klienta za pomocą jednego polecenia SELECT . Zwróć uwagę na mix-and-match; System operacyjny i serwer na tym samym wykresie; różnorodne elementy przestawne. Oczywiście nie ma ograniczenia liczby macierzy statystyk, a tym samym wykresów. (Używane za uprzejmą zgodą klienta.)
Czytelnicy niezaznajomieni ze standardem modelowania relacyjnych baz danych mogą uznać notację IDEF1X za przydatną.
Jeszcze jedna rzecz
Wreszcie, SQL jest standardem IEC / ISO / ANSI. Freeware w rzeczywistości nie jest SQL; użycie wyrażenia SQL jest niezgodne z prawem, jeśli nie zapewniają standardu. Mogą zapewniać „dodatki”, ale nie mają podstaw.
źródło
Id
używane są kolumny, jako „klucze”. Zgodnie z zaleceniami „teoretyków”.Znalazłem bardzo interesujące powyższe odpowiedzi. Próbuję dodać tutaj kilka dodatkowych uwag.
1) Starzenie się danych
Zarządzanie szeregami czasowymi zwykle musi tworzyć polityki dotyczące starzenia się. Typowy scenariusz (np. Procesor serwera monitorującego) wymaga przechowywania:
1-sekundowe surowe próbki przez krótki okres (np. Przez 24 godziny)
5-minutowe szczegółowe próbki zbiorcze przez średni okres (np. 1 tydzień)
1-godzinny szczegół (np. Do 1 roku)
Chociaż modele relacyjne umożliwiają to na pewno (moja firma wdrożyła masowe scentralizowane bazy danych dla niektórych dużych klientów z dziesiątkami tysięcy serii danych) w celu odpowiedniego zarządzania nimi, nowa rasa magazynów danych dodaje ciekawe funkcje, które można zbadać, takie jak:
automatyczne czyszczenie danych (patrz polecenie Redis EXPIRE)
agregacje wielowymiarowe (np. zadania zmniejszania mapy a-la-Splunk)
2) Kolekcja w czasie rzeczywistym
Co ważniejsze, niektóre nierelacyjne magazyny danych są z natury rozproszone i pozwalają na znacznie bardziej wydajne zbieranie danych w czasie rzeczywistym (lub prawie w czasie rzeczywistym), co może stanowić problem z RDBMS z powodu tworzenia hotspotów (zarządzanie indeksowaniem podczas wstawiania w pojedynczy stół). Ten problem w przestrzeni RDBMS zazwyczaj rozwiązuje się, powracając do procedur importowania wsadowego (w przeszłości zarządzaliśmy w ten sposób), podczas gdy technologiom no-sql udało się masowo gromadzić i agregować w czasie rzeczywistym (patrz na przykład Splunk, wspomniany w poprzednich odpowiedziach) .
źródło
Twoja tabela zawiera dane w jednej tabeli. Tak więc relacja kontra relacja nie jest pytaniem. Zasadniczo musisz odczytać wiele danych sekwencyjnych. Teraz, jeśli masz wystarczającą ilość pamięci RAM do przechowywania danych wartych lat, nic nie przypomina korzystania z Redis / MongoDB itp.
Przeważnie bazy danych NoSQL przechowują dane w tej samej lokalizacji na dysku oraz w formie skompresowanej, aby uniknąć dostępu do wielu dysków.
NoSQL robi to samo, co tworzenie indeksu na identyfikator urządzenia i identyfikator metryki, ale na swój własny sposób. Z bazą danych, nawet jeśli to zrobisz, indeks i dane mogą znajdować się w różnych miejscach i byłoby dużo dyskowych operacji we / wy.
Narzędzia takie jak Splunk używają backendów NoSQL do przechowywania danych szeregów czasowych, a następnie używają map redukuj do tworzenia agregatów (co może być tym, czego później chcesz). Moim zdaniem użycie NoSQL jest opcją, ponieważ ludzie już go wypróbowali dla podobnych przypadków użycia. Ale milion wierszy sprowadzi bazę danych do indeksowania (może nie, z przyzwoitym sprzętem i odpowiednimi konfiguracjami).
źródło
Utwórz plik, nadaj mu nazwę 1_2.data. pomysł na zużyty? co dostałeś:
=> Zapytania według znacznika czasu działają niezwykle szybko, ponieważ można użyć wyszukiwania binarnego, aby znaleźć odpowiednie miejsce w pliku do odczytu.
jeśli ci się podoba, jeszcze bardziej zoptymalizowany, zacznij myśleć o takim dzieleniu plików;
lub użyj kdb + ze strony http://kx.com, ponieważ robią to wszystko za Ciebie :) orientacja na kolumnie może ci pomóc.
Pojawia się oparte na chmurze rozwiązanie zorientowane na kolumny, więc możesz rzucić okiem na: http://timeseries.guru
źródło
Jeśli patrzysz na pakiety GPL, RRDTool jest dobrym rozwiązaniem. Jest to dobre narzędzie do przechowywania, wyodrębniania i tworzenia wykresów danych szeregów czasowych. Twój przypadek użycia wygląda dokładnie jak dane szeregów czasowych.
źródło
Jest to problem, który musieliśmy rozwiązać w ApiAxle. Mamy pisał się na blogu o tym, jak zrobiliśmy to za pomocą Redis. Nie było tam bardzo długo, ale okazało się skuteczne.
Użyłem również RRDTool do innego projektu, który był doskonały.
źródło
Myślę, że odpowiedź na tego rodzaju pytania powinna dotyczyć głównie sposobu wykorzystania pamięci przez bazę danych. Niektóre serwery baz danych używają pamięci RAM i dysku, niektóre używają tylko pamięci RAM (opcjonalnie dysku w celu zachowania trwałości) itp. Najpopularniejsze rozwiązania bazy danych SQL wykorzystują pamięć + pamięć dyskową i zapisują dane w układzie wierszowym (każdy wstawiony plik raw jest zapisywany w tym samym lokalizacja fizyczna). W sklepach z timeseries w większości przypadków obciążenie jest podobne: Relatywnie niski przedział ogromnej ilości wstawek, podczas gdy odczyty są oparte na kolumnach (w większości przypadków chcesz odczytać zakres danych z określonej kolumny, reprezentujący metrykę)
Znalazłem Kolumnowe bazy danych (google, znajdziesz MonetDB, InfoBright, parAccel itp.) Wykonują wspaniałą pracę dla szeregów czasowych.
Jeśli chodzi o twoje pytanie, które osobiście uważam za nieco nieważne (ponieważ wszystkie dyskusje z użyciem błędu NoSQL - IMO): możesz użyć serwera bazy danych, który potrafi mówić SQL z jednej strony, dzięki czemu twoje życie jest bardzo łatwe, ponieważ wszyscy znają SQL dla wielu lata, a ten język był ciągle doskonalony pod kątem zapytań o dane; ale nadal wykorzystujesz pamięć RAM, pamięć podręczną procesora i dysk w sposób zorientowany na kolumny, dzięki czemu Twoje rozwiązanie najlepiej pasuje do szeregów czasowych
źródło
5 milionów wierszy to nic dla dzisiejszych ulewnych danych. Spodziewaj się, że dane znajdą się w TB lub PB za kilka miesięcy. W tym momencie RDBMS nie skaluje się do zadania i potrzebujemy liniowej skalowalności baz danych NoSql. Wydajność zostanie osiągnięta dla partycji kolumnowej używanej do przechowywania danych, dodając więcej kolumn i mniej koncepcji wierszy w celu zwiększenia wydajności. Wykorzystaj pracę Open TSDB wykonaną na HBASE lub MapR_DB itp.
źródło
Regularnie spotykam się z podobnymi wymaganiami i ostatnio zacząłem używać Zabbix do gromadzenia i przechowywania tego rodzaju danych. Zabbix ma własną funkcję graficzną, ale łatwo jest wydobyć dane z bazy danych Zabbix i przetworzyć je w dowolny sposób. Jeśli jeszcze nie sprawdziłeś Zabbix, być może warto poświęcić temu czas.
źródło
Powinieneś zajrzeć do bazy danych szeregów czasowych . Został stworzony w tym celu.
Popularny przykład bazy danych szeregów czasowych InfluxDB
źródło