[bi-tek]

Mam sobie baze danych zawierającą odczyty z czujników co 1 min i czujników jest 1200 i działają 24/7

Teraz trzeba to zoptymalizować do wyświetlania i jak najlepiej to ogarnąć

Dzienny przyrost danych to 1728000 ( prawie 2 mln rekordów) jak w najbardziej optymalny sposób do tego podejść i jak to przechowywać na bazie, dodam że czujniki są w grupach po max 26 i tych grup jest prawie 100 (każda grupa może mieć od 1-26 czujników)

Ps. Baza aktualnie ma ponad 2mld rekordów

#programowanie #skalowalnosc #bazydanych #bigdata #mysql #postgresql

[Bruno_]

@bi-tek: nie napisales pytania

[JanekGreen]

@Bruno_: Napisał.

jak w najbardziej optymalny sposób do tego podejść i jak to przechowywać na bazie

[zwei]

@bi-tek: fajnie, że w ogóle coś powiedziałeś o formacie tych danych, które przechowujesz

[blackyabbol]

@bi-tek: może dynamodb? Jest bardzo szybkie, jak właściwie używane, no i skalowalne.

[m504]

Trzymać w skompresowanych pliakch logów a nie bazie danych.

Mam podobny problem (rozwiązany), tyle że więpszą prędkością przyrostu danych.

Używałem do tego postgresql z partycjami dziennymi ale problem z wydajnością był gdy partycji było 200 (trzeba się namęczyć z optymalizacją i SQL wtedy nie jest czytelny, nie można używać prepared statemat i robić SELECT na konkretnej partycji w miarę możliwości). Dodatko baza zaczęła zajmować sporo miejsca. Najgorsze były migracja bazy na nowsze

[marrbacca]

@bi-tek: A może influxdb? Specjalnie przygotowana baza pod tego typu dane

[bi-tek]

@zwei: W zasadzie tabela zawiera 4 kolumny (id , id grupy, pomiar decimal, timestamp ) reszta to kilka tabel po max kilkaset rekordów

@m504: Aktualnie baza ma ok 18,2 GB, Problem jest przy generowaniu raportów z określonych grup czujników, dane nie są rzeczywiste a "po zaokrągleniu" i są straszne problemy - ja system odziedziczam i mam zadanie go zreformować bo nie był projektowany pod takie obciążenie.

Możesz powiedzieć coś o

[ShortyLookMean]

@bi-tek: a musisz zapisywać co minutę? Dużo lepszym rozwiązaniem jest zapis dopiero jak wartość się zmieni.

[m504]

@bi-tek: To są zwykłe pliki których Ty określasz format. Jak to jest tylko 18GB to najlepiej użyć zykłych plików testkowych, gdzie rekord to jest jedna linijka.

\n

Nie używaj IDków z bazy danych a nazwy czujników/grup.

Pliki skompresuj GZIPem. Możesz napisać problem który to będzie robić append do plików zaraz pod odebraniu danych.

W bazie danych zrób tabelki z przetworzonymi danymi dla zakresów godzinnych. Dane te możesz czytać z plików i

[Koliat]

@bi-tek: ew wyrzuć to do nosql bo w sumie to nie masz sztywnych relacji w tym?

[leoha]

najbardziej optymalny

@bi-tek: nie ma czegos takiego jak najbardziej optymalny. Optymalny to juz znaczy najlepszy, wiec "najbardziej optymalny" to maslo maslane i jest tak samo bledne jak "bardziej w ciazy".
#grammarnazi

[plushy]

@bi-tek zwykle to się starsze dane obrabia by były mniej szczegółowe, np. tylko średnie wartości z godziny a resztę wywala. Ewentualnie jeśli nie czytasz z tego ciągle to ogarniam S3 + Athena. Jeśli chcesz zostać przy MySQL to wybierz właściwy silnik