🚀 go-pugleaf

W dniu 11.02.2018 o 02:12, geos pisze:
> 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ę. 

Dokładnie. Pisząc o strumieniu miałem na myśli ilość danych a nie 
strumień danych jako taki.

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.

To nie będzie system krytyczny. Dobrze aby działało jak najlepiej, ale 
jak nie zadziała to świat się nie zawali.


> 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.

Na partycjonowanie tabel to rzeczywiście wydaje się za mało i efekt może 
być odwrotny od zamierzonego.

Jednak obecnie skłaniam się ku składowaniu surowych danych w MongoDB 
ewentualnie pójście w ekosystem Amazona: IoT Core / DynamoDB / Lambda. 
Następnie przetwarzaniu ich pod względem tego co będę chciał prezentować 
i zapisaniu tego w osobnej bazie.

Zastanawiam się czy to nie będzie czasem przekombinowane. Chociaż 1,5 
mln pomiarów a w nich 20 mln zmierzonych wartości rocznie to też nie 
jest mało i może warto.
Ewentualnie zamiast mierzyć co minute mogę zwiększyć odstęp pomiędzy 
pomiarami albo uśredniać wyniki w jakimś okresie i wysyłać średnie co 
zmniejszy wymagania co do systemu.