Jak skutecznie przechowywać dane szeregów czasowych?

Muszę przechowywać i móc wyszukiwać bardzo duże ilości danych szeregów czasowych.

Właściwości danych są następujące:

liczba serii: około 12.000 (dwanaście tysięcy)
liczba punktów danych na świecie: około 500 000 000 miesięcznie (pięćset milionów)
mieszane typy wartości: większość punktów danych to wartości zmiennoprzecinkowe, reszta to łańcuchy
okres próbkowania: zmienny między seriami, a także w obrębie serii
znaczniki czasu: precyzja milisekundowa
okres przechowywania danych: kilka lat, bez rozkładu i próbkowania w dół
archiwa danych muszą być wbudowane prawie w czasie rzeczywistym, ale rozsądne opóźnienie (~ 1 godzina) jest dopuszczalne
dane z przeszłości można w razie potrzeby odbudować, ale kosztem
czasami, ale dość rzadko, niektóre wcześniejsze dane wymagają aktualizacji

Właściwości przewidywanych zapytań:

większość zapytań dotyczących danych będzie zapytaniami opartymi na znacznikach czasu; od jednego dnia do kilku miesięcy / lat. 90% + to zapytania dotyczące najnowszych danych

Inne wymagania:

rozwiązanie musi być darmowe, jak w darmowym piwie i najlepiej open source

Moją początkową myślą było użycie PyTables / Pandas z plikami HDF5 do przechowywania backendu zamiast bazy danych SQL.

Pytania :

Zakładając, że PyTables / Pandas jest „najlepszą” trasą, czy lepiej byłoby podzielić dane na kilka plików HDF, z których każdy obejmuje dany okres, czy umieścić wszystko w jednym pliku, który stałby się ogromny?
Czy powinienem wybrać format stały lub tabelowy? Dla mnie ustalony format wygląda OK, jeśli trzymam jeden plik HDF na miesiąc, ponieważ w ten sposób cała seria prawdopodobnie mieści się w pamięci RAM i mogę kroić w pamięci bez potrzeby indeksowania formatu tabeli. Mam rację ?

A jeśli to nie jest najlepsze podejście, jak powinienem ustrukturyzować ten magazyn danych lub jakie technologie powinienem rozważyć? Nie jestem pierwszym, który zajmuje się przechowywaniem dużych zbiorów danych szeregów czasowych, jakie jest ogólne podejście do rozwiązania tego problemu?

Inne podejścia, które rozważałem:

bazy danych tablic: doskonale nadają się do szeregów czasowych ze stałym okresem próbkowania, ponieważ wystarczy przechowywać czasy rozpoczęcia i zakończenia oraz okres próbkowania tablicy, a następnie tylko wartości w samej tablicy i indeksowanie jest łatwe. Ale ze zmiennymi okresami próbkowania w samych seriach muszę zachować bliższą relację znacznika czasu-> wartość, która moim zdaniem nie jest tak dobrze dopasowana do tablicy DBMS.
standardowa baza danych SQL z datownikiem, paramID, wartością jako kolumnami, ale ze swej natury żądają dużej ilości dyskowych operacji we / wy dla każdego zapytania

database python performance

— flyingmig
źródło

Powinieneś rozważyć tablicowe bazy danych - en.wikipedia.org/wiki/Array_DBMS#List_of_Array_DBMS . Nie twierdzę, że jeden z nich byłby słuszny, a nawet najlepszy, a nawet wystarczająco dobry, wystarczy, że powinien wejść w twoje myśli. Oprócz wpisów na tej liście istnieje system kdb ( kx.com ), choć jest on daleki od darmowego.

— High Performance Mark

Dziękuję za Twój wkład. Rozważyłem bazy danych tablic, ale problem z nimi znajduję polega na tym, że doskonale nadają się one do szeregów czasowych ze stałym okresem próbkowania, ponieważ wystarczy przechowywać czasy rozpoczęcia i zakończenia oraz okres próbkowania tablicy, a następnie tylko wartości w sama tablica i indeksowanie jest łatwe. Ale ze zmiennymi okresami próbkowania w obrębie samych serii muszę zachować bliższą relację znacznika czasu-> wartość, która moim zdaniem nie jest tak dobrze dopasowana do tablicy DBMS. Powiedziawszy to, byłbym szczęśliwy, gdybym udowodnił, że się mylę.

— flyingmig

pytanie edycyjne, aby dodać to, co do tej pory

— rozważałem

Pytanie: czy musisz przechowywać wszystkie dane? Czy dane mogą zanikać w czasie i / lub czy istnieje pewien dopuszczalny poziom dokładności dla serii opartych na pływakach?

— J Trana,

@ moinuddin-quadri Skończyło się na użyciu pand obiektów DataFrame wspieranych miesięcznymi plikami HDF5 w formacie tabeli. System działa od ponad roku i jest bardzo stabilny i szybki, nawet przy użyciu dysków SSD. Spróbuję napisać to wszystko jako odpowiedź, kiedy będę miał czas. W przeciwnym razie nie krępuj się ze mną napisać.

— flyingmig

Odpowiedzi:

Możesz rzucić okiem na węgiel i szept , część projektu grafitowego . Carbon może obsługiwać bardzo duże ilości danych szeregów czasowych. Chociaż teraz, kiedy czytam dokumenty (minęło kilka lat, odkąd ich używałem), to tylko dla danych liczbowych. Powiedziałeś, że masz również ciąg danych, więc może ci się to nie przydać. Chociaż możesz uzyskać wiedzę na temat szybkiego przetwarzania dużych ilości danych.

Aby dać wyobrażenie o tym, jak dobrze się skaluje, kiedy grafit został po raz pierwszy wprowadzony do produkcji w Orbitz, przetwarzał 160 000 wskaźników na minutę .

— Bryan Oakley
źródło

Dziękuję za sugestię, ale z mojego zrozumienia szept nie pasuje, ponieważ jego precyzja jest drugą, gdy potrzebuję precyzji milisekundowej, a jak słusznie zauważyłeś, mam również dane łańcuchowe, których nie można tam zapisać.

— flyingmig

@flyingmig Nie pisz tak szybko. Jego znaczniki czasu są wartościami z epoki uniksowej. A „dane łańcuchowe”, które opisałeś w pytaniu, brzmią bardziej jak wyliczenia i są one zwykle przechowywane jako małe wartości całkowite.

— Ross Patterson

Sears używa Carbon / Graphite / Ceres do przechowywania 4M + unikalnych punktów danych na minutę. Nie jest idealny i wymaga klastrowania grafitu i dysków SSD, ale działa. Wszystkie pozostałe rozwiązania nie są skalowalne do tego poziomu, który znaleźliśmy, ale jeśli masz pomysły, nie wahaj się wejść.

— Kevin J. Rice,

InfluxDB to otwarta baza danych napisana w Go. Został napisany specjalnie do obsługi danych szeregów czasowych i opublikowali testy porównawcze pokazujące znacznie lepszą wydajność w porównaniu do Cassandry :

InfluxDB osiągnęło lepsze wyniki niż Cassandra we wszystkich trzech testach, dzięki 4,5-krotnie większej przepustowości zapisu, a jednocześnie zużywając 10,8x mniej miejsca na dysku i zapewniając do 168x szybszych czasów odpowiedzi dla testowanych zapytań.

— Dan Dascalescu
źródło

możesz sprawdzić bazy danych zorientowane na kolumny. Nie jestem pewien, co masz na myśli mówiąc o macierzowych bazach danych, ale dzięki mojemu sugerowanemu podejściu możesz mieć dynamiczną liczbę wartości na przedział czasu. Możesz także mieć wiele wartości dla tego samego znacznika czasu. Co ciekawe, jeśli masz wartości zmierzone w tym samym czasie, możesz zapisać je jako dodatkowe kolumny (np. Czujnik mierzący temperaturę i wilgotność, w cenie giełdowej i wielkości transakcji, ...). Ze względu na charakter zorientowany na kolumny można mieć tabele zawierające 100 kolumn, ale jeśli zapytanie ma dostęp tylko do pięciu kolumn, baza danych odczytuje tylko dane z pięciu kolumn.

Napisałem serię o tworzeniu własnej bazy danych szeregów czasowych, możesz rzucić na to okiem:

— hellomichibye
źródło