🚀 go-pugleaf

W dniu sobota, 10 lutego 2018 17:23:21 UTC+1 użytkownik wloochacz napisał:
> W dniu 2018-02-09 o 19:55, irq pisze:
> > W dniu piątek, 9 lutego 2018 14:43:52 UTC+1 użytkownik wloochacz napisał:
> >> W dniu 2018-02-08 o 18:36, irq pisze:
> >> /ciach/
> >>
> >>> A model relacyjny i tak będzie potrzebny do raportowań i kojarzenia czujników z ich lokalizacjami.
> >> A niby dlaczego jest potrzebny, czyli niezbędny?
> > 
> > Wynika to z tego fragmentu mojej wypowiedzi, który ciachnąłeś. 
> No cóż, nie zgadzam się z tym w ogóle.
> 
> > Uniezależnienie lokalizacji pomiaru od niekoniecznie stałej lokalizacji czujników. Z późniejszych wypowiedzi kolegi pytającego wynika, że raczej o to nie dba, bo buduje mały system, w którym może to nie mieć miejsca, ani znaczenia. Ja założyłem, że może to być dowolnie duży i nadający się do elastycznej rozbudowy system, w którego ekspolatacji trzeba spróbować przewidzieć takie rzeczy jak zarządzanie ruchem i migracjami elementów jego wyposażenia. A zatem pomiar z identyfikatorem konkretnego czujnika z dzisiaj i pomiar z tym samym identyfikatorem za rok, to niekoniecznie muszą być pomiary dotyczące tego samego miejsca.
> 
> I właśnie dlatego rozwiązania NoSQL w tym przypadku mogą pokazać swoją 
> przydatność i przewagę w stosunku do baz relacyjnych.
> Mówić krótko - jeśli mamy ustandaryzowany model danych o zerowej lub 
> niewielkiej dynamice zmian schematu danych, bazy relacyjne pewnie będą 
> lepsze.

w tym przypadku mamy model, po którym nie powinniśmy się spodziewać wysokiej dynamiki zmian. No chyba, że rzeczywiście pojawi się wymóg rejestrowania stężenia SO2 :)

> 
> Tu wskazujesz dokładnie coś odwrotnego.
> Proponowany model EAV (zwany antywzorcem Entity Attribute Value) dla baz 
> relacyjnych to zabójstwo dla ich wydajności, zwłaszcza przy 
> niebagatelnej ilości danych.

zabójstwo, ale nie dla wydajności bazy danych, a wydajności "modelu dostępu" do tablicy skonstruowanej z zastosowaniem EAV. Jeżeli ktoś się uprze raportować dane w oparciu o odczyt z jedynej samotnej tabeli z zapisem surowych próbek to żaden model nie będzie wydajny. 

> 
> A w omawianym przypadku sam podniosłeś dokładnie takie wymagania ;-)
> 

tak, ale w odniesieniu do samej tabeli przechowującej pierwotne dane, w odniesieniu do których nie jeszcze ma pełnej wiedzy co do ich kształtu i zakresu spodziewanych zmian. Pełny model relacyjny może zaś znaleźć zastosowanie w zakresie organizacji danych do wydajnego ich raportowania. 

I tu właśnie, nawiązując do sąsiedniej Twojej odpowiedzi, PostgreSQL z typem, podkreślam: typem danych json, może być doskonałym środowiskiem do realizacji takiego hybrydowego rozwiązania. Chciałem wypowiadać się zwięźle - dlatego użyłem skrótu EAV jako hasłowego określenia, ale nie było to najszczęśliwsze posunięcie. Dlatego chętnie przeszedłem na używanie skrótu JSON, zwłaszcza w kontekście typu danych json (jsonb) w postgresie.

Definicja tabeli próbek danych mogłaby być taka jak:

CREATE TABLE data_sample (
    id          bigserial PRIMARY KEY,
    dt          timestamp,
    sensor_id   integer, -- albo text? - prawdopodobnie powtórzenie któregoś elementu z sample - celowy nadmiar dla usprawnienia agregacji i dostępu
    sample      json     -- albo jsonb - i tutaj dowolna struktura
);
-- i być może:
CREATE INDEX ON data_sample (date_trunc('day', dt), sensor_id);
-- zamiast 'day' - może 'hour'?, 'week'? - zależnie od potrzeb.

"dt" oraz "sensor_id" są uchwytami do modelu relacyjnego i przetwarzania danych w kierunku ich przygotowania do raportowania. "sample" zawiera całą pozostałą, nie w pełni zdefiniowaną jeszcze, zawartość danych.

Tak jak pisałem wcześniej, warto rozważyć partycjonowanie tej tabeli (wg, tygodni? miesięcy? lat?).