Zbieranie danych do systemu SCADA

Postanowiłem sobie w celach nauki wyważyć otwarte drzwi i napisać mały system SCADA pod stronę WWW.
Obecnie miałem przyjemność pracować z jakimiś gotowymi wewnętrznymi rozwiązaniami firm, w których pracowałem niestety czasem ich wydajność i łatwość rozbudowy (naogół osoba, która stworzyła oprogramowanie już dawno tam nie pracuje) pozostawiała wiele do życzenia. Nigdy nie zajmowałem się projektowaniem rozbudowanych baz danych i nie wiem w jakim kierunku pójść. Poniżej mój obecny problem:

Baza musi umożliwiać dodawanie nieograniczonej liczby zmiennych - chciał bym na wstępie zapobiec sytuacji, że mam np. możliwość dodania 1000 zmiennych i nie więcej. Każda zmienna może być różnego typu: int, uint, float, double, string itd... Jak zatem magazynować różnego typu dane? W jednej tabeli czy każdą zmienną w oddzielnej? a może po jakimś okresie czasu przepisywać dane do innej tabeli? Możecie podzielić się swoim doświadczeniem?

Spotkałem się raz z systemem, który wpisuje wszystkie dane do 1 tabeli. Niby wszystko fajnie na początku działa ale jak klient zażyczył sobie próbkować dane co 1s i każdą zapisywać do bazy to w krótkim okresie czasu dostęp do danych robił się baaaaaardzo powolny. Wydaje mi się zatem, że najwygodniej będzie aby każda zmienna była w oddzielnej tabeli. Co o tym sądzicie?

Ogólny zarys działania systemu i technologii jakie sobie wymyśliłem:

1. pobieranie danych z urządzeń - c, c++, java albo python
2. Wykonanie obliczeń definiowanych przez użytkownika - jscript albo php
3. wpisanie danych do bazy - c, c++, java albo python
4. wizualizacja na stronie www - ajax, jscript, php
5. interakcja z użytkownikiem i urządzeniami poprzez stronę www (ustawienie wartości, wymuszenie stanu)

Protokół komunikacyjny z urządzeniami to chyb modbus RTU/TCP. Dość wygodny i na początku w zupełności wystarczy.

Z góry dziękuję za pomoc

To jest temat rzeeekaaaa...
Jeśli nie znasz, to poczytaj:
http://platforma.astor.com.pl/files/getfile/id/3781

Nie chcę Cię straszyć, ale jak nie znasz się za dobrze na bazach danych - polegniesz.
Zwłaszcza, jeśli przyrost tych zmiennych będzie szedł w dziesiątki tysięcy na dobę.
I owszem, ten system może działać - do czasu; wtedy wszystko zależy od bazy danych, sprzętu i jakości zapytań, które będziesz zadawał. Ale to i tak ślepa uliczka...
Można radzić sobie ze sporą ilością danych za pomocą partycjonowania danych w bazie - ale nie każda baz danych potrafi coś takiego i racej to odwlekanie faktycznych problemów.
http://technet.microsoft.com/pl-pl/library/akademia-sql---czesc-16-partycjonowanie-tabel---informacje-podstawowe.aspx

Być może rozwiązaniem byłby jakieś bazy danych NoSQL, np. MongoDB. Ale nie wiem, nie znam się, zarobiony jestem...

Co do technologii - w sumie to bez znaczenia. Tu ciężar (powinien być) jest przesunięty na sprytne algorytmy kompresji danych, ale nie chodzi mi o kompresję w ujęciu potocznym, a o kompresję w zakresie jakości danych. Innymi słowy - nie każda zmiana wartości zmiennej musi być zapisywana jako osobny wiersz w tabeli.
Ale znów - tu wiele zależy co ten system ma de-facto robić.

PS.
Za dużo w Twoi pytaniu "chyba, może" - w automatyce przemysłowej nie ma miejsca na "chyba" i "może", bo potem kończy się to ogromnymi problemami ;-)
Dlatego też naprawdę dobrze przemyśl sprawę i testuj, testuj, testuj!

Dzięki za materiały. Na pewno się przydadzą.

"Nie chcę Cię straszyć, ale jak nie znasz się za dobrze na bazach danych - polegniesz." - Grunt to dobra motywacja do nauki. Dzięki :)

Wychodzę z założenia, że jeśli czegoś nie umiem (SQL) to trzeba przynajmniej spróbować aby wiedzieć czego się nie zna. Tak jak napisałem wcześniej: "Postanowiłem sobie w celach nauki wyważyć otwarte drzwi i napisać mały system SCADA pod stronę WWW." jest to nauka więc doświadczenie zebrane będzie dla mnie najcenniejsze.

Zakładając najgorszy przypadek: 1000 zmiennych aktualizuje dane co 1s daje to nam 86400000 (10006060*24) rekordów w ciągu jednej doby. Jaka baza to wytrzyma? Celowo pomijam tutaj jakąkolwiek optymalizację zapisywania i zakładam, że chciałbym zapisać wszystkie dane. Przy takim podejściu wydaje mi się, że lepiej by było tworzyć do każdej zmiennej oddzielną tabelę.
Dużo roboty przede mną. To dobrze.

1. A może jednak noSQL zamiast relacyjnej bazy? Bo wygląda to trochę na dane typu klucz->wartość i są rozwiązania noSQL dedykowane dla takich zastosowań. I raczej będą szybsze od sqlowej bazy.
2. Nie rozumiem czemu chcesz to wszystko robić w różnych technologiach. Niepotrzebnie dodajesz sobie pracy zwiazanej z integracją. Czemu nie machniesz wszystkiego w Pythonie na przykład?

1. NoSQL odpada przynajmniej w tym projekcie. Ale może kiedyś...
2. Dlaczego wszystkiego nie napisze w pythonie? Chciałbym aby użytkownik pod koniec otrzymał proste narzędzie do rozbudowy. Często mam takie sytuacje:
   mam kilka różnych urządzeń - każde działa na różnym protokole danych (modbus RTU, modbus TCP, json, xml, oraz inne indywidualne protokoły latające po TCP/UDP/RS485). Użytkownik życzy sobie teraz aby jakieś zmienne pododawać do siebie i stworzyć z wyniku inną zmienna zapisywaną do bazy. Można to zrobić oczywiście w pythonie ale niestety nie chciał bym aby osoba obsługująca oprogramowanie za każdym razem gdy zechce coś obliczać musiała by go znać. Wygodniej było by wykorzystać jscript albo php jeśli chciał by jeszcze obsługiwać jakieś zapytania do bazy i robić jakieś dziwolągi. Może jest to faktycznie przerost formy ale wydaje mi się, że elastyczność przede wszystkim.

Obecnie postanowiłem zrobić następującą strukturę bazy:
Tabela z wszystkimi danymi aktualnymi w celu szybkiej obsługi wizualizacji. Główne zapytanie to update odświeżające tylko aktualną wartość.
Tabele dla każdej zmiennej osobno. (ale tutaj jeszcze się mocno zastanawiam, muszę douczyć się odnośnie wydajności z materiałów od użytkownika wloochacz)
Cyklicznie np. co 1miesąc dane musiały by być przekopiowywane do tabel zawierających historię rekordów z poprzednich miesięcy.
Dlaczego boję się wsadzić wszystkiego do jednego worka? Oto moje obliczenia:
próbkuję dane co 1s - niestety takie są założenia i musi być tak często :(
każda zmiana wartości leci do bazy - muszę zapisać każdą zmianę, nawet niewielką dlatego zakładam najgorszy scenariusz
2000 zmiennych - spora ilość danych do analizy w późniejszym czasie.
z powyższych założeń wynika mi, że dziennie jedna zmienna wygeneruje (606024) 86400 rekordów do bazy. Niby niewiele ale 2000 zmiennych dane 172 800 000 rekordów dziennie. Jak można to szybko przeglądać? nie mam pojęcia. Gdy chcemy zapisać teraz dane z co najmniej 1 roku daje to nam ładną liczbę 63 072 000 000 rekordów natomiast w pojedynczych tabelach to tylko 31 536 000 :).

Można to zrobić oczywiście w pythonie ale niestety nie chciał bym aby osoba obsługująca oprogramowanie za każdym razem gdy zechce coś obliczać musiała by go znać. Wygodniej było by wykorzystać jscript albo php jeśli chciał by jeszcze obsługiwać jakieś zapytania do bazy i robić jakieś dziwolągi. Może jest to faktycznie przerost formy ale wydaje mi się, że elastyczność przede wszystkim

? Nie rozumiem. Przecież user i tak musi coś znać. Albo będzie to python albo js albo php. Jaka jest różnica niby? Tak czy siak wymagasz pewnej znajomości języka programowania. Nie widzę chyba tej twojej elastyczności, poza zbędna komplikacją projektu.

BTW ty widzisz te liczby które podajesz?
63 072 000 000 rekordów, nawet gdyby zawierały tylko jednego inta na 4 bajty (a domyślam sie ze jednak będą zawierać więcej) to jest 235 GB danych.
172 800 000 rekordów dziennie zawierających jednego inta na 4 bajty to jest 660 MB danych dziennie. Załóżmy realnie ze masz int na ID plus double na dane, to jest prawie 2GB danych dziennie. Do jakiej bazy ty to to niby chcesz pchać?

Case study wdrożenia w firmie energetycznej z USA zrobione na MSSQL 2005:
http://www.google.pl/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDQQFjAA&url=http%3A%2F%2Fwww.microsoft.com%2Fcasestudies%2FServeFileResource.aspx%3F4000005418&ei=dSuxU6zcJ8mP7AbtoYDgDw&usg=AFQjCNGtEL2lAmckn73SAr0TcL0dCdmshA&bvm=bv.69837884,d.bGE&cad=rja

Roczny przyrost danych to 20TB :P

Shalom:
Jak przyszedłem do swojej obecnej pracy to ludzie nie wiedzieli, że istnieje coś takiego jak python. Dla większości XML jest językiem programowania a c# czytali jak c kratka :).
Jak ktoś usłyszał php to już było cieplej a java i jscript to już nie ma problemu. PHP będzie tutaj najwygodniejsze a jscript również będzie proste do ogarnięcia.

Liczby wyglądają strasznie. Ale niestety są prawdziwe. Spotykam się czasami z systemami dla, których każda informacja jest cenna (niestety). Otrzymałem kiedyś pytanie czy mógł bym zapisywać dane do bazy próbkowane 1000 razy na sekundę. Czas przetrzymywania danych był niewielki ale problem bardzo podobny.

Jaka baza?
Nie będę czarował. Po prostu nie wiem. Rozważałem microsoft sql lub postgress

@Wilczur no ale pytanie brzmi czy musisz to trzymać w bazie danych po prostu? Bo miałem okazję zobaczyć jak w pewnych miejscach trzyma sie duże ilości danych i generalnie nie pcha się tego do bazy :) CERN w bazie danych trzyma tylko konfiguracje akceleratora a dane jako takie są zapisywane w binarnej zoptymalizowanej postaci na dyskach/taśmach.
Teraz mam okazję zajmować się systemem dostępu do danych telemetrycznych ze statku kosmicznego i tutaj też te dane nie są pchane do bazy (bo danych byłoby wielokrotnie więcej niż te liczby które podałeś ;) ) tylko w wersji zoptymalizowanych paczek binarnych leżą na dysku i są dekodowane w miarę potrzeby.
Ma to o tyle sens że sensorów są tysiące, misja trwa pół roku, a w praktyce faktycznie potrzebny jest dostęp tylko do pewnego podzbioru parametrów, często z bardzo wąskich okresów czasu. Ale w razie czego wszystkie dane są dostępne :) To oczywiście nie pozwala na dostęp do danych real-time, bo jednak dekodowanie i kalibracja chwilę trwa, ale z drugiej strony ile parametrów faktycznie chcesz monitorować real-time?
A z punktu widzenia użytkownika to jest tylko taka różnica że użytkownicy wiedzą że po wybraniu danych które ich interesują muszą sobie poczekać chwilę zanim będą mogli ściągnąć wyniki, ale jeśli nie próbują wyciągnąć dużej liczby parametrów dla całej misji to zwykle taka ekstrakcja to jest kwestia kilku sekund (a jak ktoś wyciąga sobie CSV na kilkaset megabajtów to może poczekać te kilka minut bo i tak analiza zajmie mu dużo więcej czasu ;] )

Wilczur napisał(a):

Liczby wyglądają strasznie. Ale niestety są prawdziwe. Spotykam się czasami z systemami dla, których każda informacja jest cenna (niestety). Otrzymałem kiedyś pytanie czy mógł bym zapisywać dane do bazy próbkowane 1000 razy na sekundę.

Tak, mógłbyś - to żaden wyczyn. Ale to nieistotne...
Istotne by było pytanie - po co?
Zapytałeś tego człowieka, dlaczego chce próbkowanie 1kHz i dostęp do każdej odczytanej próbki?
Wiesz w ogóle skąd się wziął ów 1Khz?
To mnie interesuje - po co zapisywać każdą zmienną i mieć do niej dostęp.
I dla Ciebie powinno być to pytanie absolutnie podstawowe.
Nie baza czy technologia - skupiasz się na nieistotnych szczegółach, moim zdaniem.

Czas przetrzymywania danych był niewielki ale problem bardzo podobny.
Jaka baza?
Nie będę czarował. Po prostu nie wiem. Rozważałem microsoft sql lub postgress

I tak będziesz potrzebował warstwy pośredniej, chociażby w celach bezpieczeństwa - ale nie tylko.
Zapisywanie takiego strumienia do bazy danych w trybie ciągłym, może skończyć się... różnie.
Co np. zrobisz jeśli wywali się klient bazy danych, bo coś tam?
Klient przeżyje utratę kilkuset tysięcy zmiennych?

A jeśli tak, tego po co zapisywać każdą z nich?
Bo klient powiedział, że tak trzeba.
A ja Ci powiem, ze klient mało kiedy wie co tak naprawdę trzeba i jeszcze mniej wie, jak to zrobić.

@Shalom
Faktycznie. Zapisywanie wszystkiego do plików jest bardzo dobrym pomysłem. W celu przetrzymywania takich ilości danych w bazie trzeba pamiętać, że za chwilkę dostęp będzie wydłużony. Kurcze, przy małych systemach i trzymaniu danych z krótkiego okresu czasu problemów praktycznie nie ma. Optymalizacja w trzymaniu danych powinna być wykonana na samym początku. kompresja danych i zapisywanie tylko istotnych próbek będzie to mój kolejny krok.
pobieranie danych z tysięcy obiektów (czujników) to taki fajny rozproszony system automatyki. Mam czasem przyjemność pracowania z niewielkimi systemami rozproszonymi i baza zawsze jest tutaj problemem. Do tej pory obsługiwałem kilkaset urządzeń nadających po gprs różne dane. Wpychaliśmy je do jednego worka a inny system pobierał je sobie na bieżąco i analizował. Teraz przychodzi czas na analizę.

@wloochacz
Dlaczego próbkować dane 1kHz? To po prostu taki kaprys z punktu widzenia programisty. Niestety nie był to kaprys z punktu widzenia klienta. Dokładna analiza niektórych zjawisk fizycznych wymaga częstych próbek. Wykonane to zostało ale za pomocą specjalistycznego sprzętu i nie trzeba było zapisywać danych do bazy. Wszystko w formie plików zrzucane na dysk.
Klient rzadko e ma racji. Ale czasem jego wymagania nawet jak nie ma racji muszą zostać spełnione.