🚀 go-pugleaf

On 09.02.2018 00:48, baItiz wrote:
> W dniu 08.02.2018 o 20:15, Adam M pisze:
>> Zagadzam sie w 100% - w systemach rejestracji danych czasu
>> rzeczywistego pewny zapis pomiaru jest najwazniesza rzecza - dlatego
>> tabela powinna byc jak najprostasza. Reszte mozna dobudowac jak sie
>> chce - w zaleznoci jak dane beda uzywane. Dodatkowo autor powinien
>> oszacowac rozdzielczosc czasu w systemie i rozmiar strumienia danych
>> (tzn jak szybko dane beda naplywaly i ile ich bedzie w danym momecie)
>> - moze sie okazac ze sam SQL jest za wolny i trzeba dolozyc jakies
>> posrednie buforowanie przed zapisem do bazy danych. W zasadzie w
>> systemach rejestracji danych czasu rzeczywistego projektowanie bazy
>> danych jest zadaniem drugorzednym - baza danych ma poprostu zapewnic
>> pewna i trwala rejestracje pomiaru - jak dane sa pozniej
>> uzywane/opisane nie jest to problemem systemu rejestracji.
>
> To chyba jest najlepszy pomysł. Najpierw prosto zbierać dane a później
> zastanowić się co i jak z nimi zrobić.
>
> Strumień danych nie będzie duży. Docelowo co minutę do 50 wartości
> pomiarów z 3 lokalizacji. W każdej lokalizacji czujniki będą
> komunikowały się z bramką a ta dopiero wysyłała dane dalej. W razie
> potrzeby można na poziomie bramki wprowadzić agregację i wysyłać
> uśrednione dane co 5 min.

chyba powinieneś przemyśleć co chcesz zrobić. bo jak chcesz rejestrować 
strumień w sposób pewny to nie potrzebujesz do tego bazy. po prostu 
rejestrujesz to jako nieprzetworzony strumień danych z czujników. do 
tego potrzebujesz odpornego na błędy toru transmisji i metody 
składowania. do składowania z grubsza potrzebujesz macierzy 
odpowiedniego typu. to chyba wszystko. z 5 czujników rejestrujesz 5 
strumieni. będziesz miał rejestrację pewną, odporną na błędy i awarie. a 
później taki strumień sobie po prostu odpowiednio obrabiasz. żadna baza 
nie pomoże jak się coś po drodze "zesra" a może nawet przeszkadzać.

śmiem jednak wątpić czy to chcesz właśnie robić skoro piszesz na tę 
grupę. padły sugestie o użycie typów złożonych do danych. to nie to samo 
co "strumienie". odpowiedź sobie na pytanie, czy potrzebujesz nadać 
swoim danym strukturę złożoną albo czy czegoś brakuje typom prostym w 
tym konkretnym zastosowaniu. wtedy będziesz wiedział, czy potrzebujesz 
typów złożonych typu json, xml itp. powątpiewam, chociaż nie wykluczam, 
że mógłbyś tak chcieć w konkretnym celu, np. w celu późniejszej wymiany 
danych z innymi systemami jednym z popularnych standardów wymiany danych.

z tego co piszesz wnioskuję jednak, że wystarczą podstawowe typy proste. 
prawdopodobnie potrzebujesz również stosunkowo prostej relacyjnej bazy 
danych. sqllite by pewnie wystarczył z nawiązką. małe i sporo potrafi.

skoro wspominasz o "pewności zapisu" to przydałoby się coś z obsługą 
transakcji. ale pewnie świat się nie zawali gdy będzie nietransakcyjna 
bo prawdopodobnie w swoich rozważaniach uwzględniasz, że awarie się 
zdarzają i czujnik może się po prostu popsuć (i prawdopodobnie czujników 
nie duplikujesz aby zapobiec utracie danych, co nie?) co będzie miało 
finalny efekt taki sam jak transakcja, która się nie powiedzie - brak 
danych.

summa summarum temat "co minutę do 50 wartości z 3 lokalizacji" IMHO nie 
jest wart rozważań o partycjonowaniu, strumieniach, bazach nosql, typach 
złożonych i na dodatek nowej ortografii :) zrób to najprościej bez 
generowania zbędnych problemów: zbierz dane z czujnika, opakuj w 
inserta, wrzuć do tabeli, zakomituj.

pozdrawiam
geos