Jaki storage dla danych z czujników?

0

cześć
mam pytanko
chcę zbierać dane z czujników, może być ich dużo - bo próbkowanie jest częste
(przyrost to powyżej rekordów miliona dziennie)

patrzę się na to co można by wykorzystać i do głowy mi przychodzą
1 - timescale db, oparty na postgresie
2 - mongo (lub inny nosql-owy wór na dane)

timescale db z tego co doczytałem może mieć "zbiór danych świeżych" np 2-3 dni (jak się ustawi) a reszta się archwizuje
ma to taki minus, że jakby się chciało starsze dane to odczyt trwa dłużej
jakby się chciało coś porównować, poanalizować to też wydajność może siadać

z bazami nosql mam małe doświadczenie - ale tez wydają się być opcją

Macie jakieś doświadczenia z czymś takim, dużo danych, trzeba je zapisać i odczytać w wydajny sposób
na pewno największe zainteresowanie jest dla najświeższych danych, ale może się zdarzyć jakieś "porównanie" danych starych i świeżych

co byście polecali, jeśli te 2 w/w opcje wydałyby się dla Was nie takie jak trzeba?

3

Jak dlugo chcesz trzymac te dane? Co chcesz z nimi robić. Postgres i partycje na tabelce mogą wystarczyć. Albo jakiś influx.

3

zabbix zbiera takie dane do normalnego postgresa albo mysqla. Aktualnie moja tabela z danymi ma 18M rekordów i waży razem z indeksami 2,5GB.
Stoi to wszystko na jakimś leciwym PC (ok 10 letnim) z 8GB RAM i i7-2600k i zwykłym HDD talerzowym.
Wykresy generują się praktycznie od razu. Obciążenie PCta jest w okolicach 3-4% z czego większość zabiera VPN

2

Ja jestem prosty programista. Kiedys przeczytałem że pojedyncza instancja postgresa daje radę do 1T i tego bym się trzymał. Tylko to nie zmieści się w jednej tabeli i pewnie będzie trzeba robić partycje miesięczne tak jak pisze @S4t

2

Ja bym użył jakiegoś TSDB. Najprościej pewnie timescaledb na postgresie.
Nie wiem czy przy takiej skali to robi jakieś duże znaczenie, ale od jakiegoś czasu mnie nosi żeby się pobawić TSDB :]

0

Pytanie jest jak bardzo częste są te odczyty i co będziesz z nimi robił.
Ogólnie to to, czego szukasz to TimeSeries DB (np. AWSowe Timestream, InfluxDB), ewentualnie możesz użyć Prometheusa jeśli tylko odczyt może mieć jakieś większe latency. Idąc dalej to masz specjalistyczne narzędzia typu KDB+ (wykorzystywane w m.in. NASA czy Formula 1) - wtedy można na bieżąco przetwarzać dane - ale nie wydaje mi się, żebyś czegoś takiego potrzebował.

Swoją drogą to milion rekordów dziennie (czyli ok. 42 tys. na godzinę) to nie jest jakoś specjalnie dużo - IMO większość taki przypływ danych udźwignie.
Kwestia jest taka, że jednak trzeba będzie to partycjonować i gdzieś trzymać - bo już po roku będziesz miał 356 milionów rekordów. Zakładając, że jeden rekord to jeden kilobajt daje to 356 giga na rok - i już w tym momencie pytanie, czy chcesz czegoś, co ogarnie ci to w jakiś prosty sposób, czy np. możesz napisać to sam.

0

W zależności też ile jesteś w stanie poświęcić kasy na to, możesz wykupić jakąś VMke/dedyka na HDD, ceny są śmiesznie niskie a system możesz dopasować, obojętnie czy to jakis zabbix czy customowe rozwiązanie.

1 użytkowników online, w tym zalogowanych: 0, gości: 1