Database dizajn - nedoumica

[farmaceut]

Dakle treba da napravim jednu online bazu podataka, pa bih voljeo da se "posavjetujem" sa vama.
Baza ce biti ili MySQL 5 ili MSSQL server (jos se nisam odlucijo za hosting), vjerovatno na dedicated ili VPS serveru, kod kvalitetnog provajdera.
Radi se o pracenju podataka u proizvodnji pomocu sondi, na razlicitim lokacijama.

Nad tim podacima ce se vrsiti neka prosta obrada, tipa racunanje prosjeka, minimuma i maksimuma.

Sonda predaje informaciju u obliku:

'IDSonde', 'Date', 'Time', 'parametar1', 'parametar2', 'parametar3', 'parametar4', 'parametar5'

Problem je u ocekivanoj kolicini podataka.

Podaci se salju sa svake sonde, svaki sat.

Neki plan je da se podaci primaju sa 100-tinajk lokacija, sa oko 250 sondi svaka, tokom 2-3 godine, dakle oko 600.000 recorda dnevno ili 220.000.000 godisnje.
Posto jedan proizvodni ciklus na svakoj lokaciji traje mjesec dana, najbitnije je da su podaci za vrijeme trajanja ciklusa lako (citaj brzo) dostupni, radi analize.
Kasnije brzina nije bitna.

Pitanje bi bilo kako organizovati tabele?

-Prva opcija bi bila da se za svaku lokaciju pravi posebna tabela, sto bi dalo 100-tinjak tabela.

-Druga, da se napravi manji broj tabela za za arhiviranje, na primjer 10 tabela pa pa da u svaku tabelu lokaciju idu podaci sa 10 lokacija, i par 'temporalnih' tabela u koje bi cuvale podatke o aktuelnim proizvodnim procesima.
Kada svaki proces zavrsi, podaci se prebace iz temporalne tabele prebace u arhivu.

-Treca opcija bi bila kombinacija prve dve. 100 tabela za aktuelne procese, i 100 tabela za arhivu, tako da svaka lokacija ima svoju tabelu za tekuci proces i i svoju arhivu.

Ja se dvoumim izmedju druge i trece opcije, pa me zanima vase misljenje.
Ako neko ima neki bolji prijedlog, naravno, neka ga iznese.
Pozdrav!

 

[deka]

Za toliki obim podataka, mislim da MySQL nije ni opcija. Sa MSSQL-om nemam neka iskustva, ali mislim da je neki Oracle malo bolja opcija. To da li imas 100 ili 1 tabelu, moze da ima osetnu razliku u performansama samo ukoliko se tabele podele po table space-ovima. Za arhivu ti ne treba 100 tabela sigurno.
U svakom slucaju, bez detaljnije analize nacina citanja podataka (tj. izgleda izvestaja), ne bih ti mogao vise pomoci. Jedno sto znam sigurno je da toliki broj podataka u jednoj bazi (serveru) je vrlo lose resenje.

 

[farmaceut]

Da malo pojasnim.
Radi se o projektu pracenja podataka u poljoprivrednoj proizvodnji.
Sonde su u stvari "stapovi" koji se zabadaju u zemlju i mjere temperaturu, po dubini, na pet mjesta.
Podaci su dakle decimalni brojevi koji oznacavaju temperaturu, na dvije decimale.
Na svakom polji, tj. oranici, postavlja se odredjeni broj sondi. Maksimalno bi bilo 250 po polju (na toj sam bazirao racunicu), ali u stvarnosti je manje (25-100).
Postoji mali uredjaj koji svaki sat ocitava podatke sa sondi i salje ih kao text fajl na web, gdje bi bio ubacen u tu bazu podataka.
U planu je da se za par godina zasadi do 100-tinjak takvih polja.

Sto se tice obrade podataka, to bi bilo pracenje temperature (min/max) i alarm ako na nekom djelu polja bude pretoplo ili prehladno.
Ti podaci se prate dok traje jedan "zasad", tipicno oko mjesec dana, i nakon zetve vise nisu bitni (ali ih je ipak potrebno sacuvati u nekoj arhivi, za svaki slucaj).

Dakle tipicana analiza bi bila da li je neki dio oranice u datom vremenu presao minimalnu ili maksimalnu temperaturu, da bi se mogle primjeniti odredjene agrotehnicke mjere.
Takodje ce postojati izvjestaj o prosjecnoj temperaturi na oranici za period od jedan dan, 7 dana, i za vrijeme trajanja jednog zasada.
Kad se zetva obavi, ti podaci se vise nece obradjivati.


Radim na CF web aplikaciji koja ce graficki prikazati izvjestaje.

Ovo pitanje sam postavio jer nemam iskustva za velikim bazama podataka. Radio sam neke baze u MySQL, koje dobro funkcionisu, ali ni jedna od njih nema vise od 50.000 recorda po tabeli.

Vec par dana "kopam" po netu i trazim iskustva sa MySQL i velikim bazama. Takodje razmisljam i o MS-SQL, koji se u svim poredjenjima navodi kao bolji izbor. Sa nekim drugim bazama nisam imao kontakta.

Posto se radi o nekomercijalnom projektu, sa ogranicenim budzetom, potrebno je da troskovi ne budu preveliki, tako da kupovina skupih servera i placanje licenci za Oracle i sl. nije opcija. (zao sam i mislio na MySQL)

Eventualno je moguce da se, u slucaju potrebe, zakupi par dedicated servera na netu, sa bazama podataka, na kojim bi se podaci rasporedili.

 

[Pharos]

MySql 100% može da podnese toliku količinu podataka.
Ja sam se igrao jedno vreme sa MySQL i punio je nekim bezveznim podacima i zapisao sam nešto malo jače od 60.000.000 rekorda.
Nisam mogao više jer sam podatke unosio iz PHP-a, a on je previše spor za punjenje baze nekim random vrednostima.
Za 220.000.000 recorda i 100 tabela će biti malo ako očekuješ neke bolje preformanse.
Kako da dizajniraš bazu... Pa za to ćeš ipak morati da angažuješ nekog profesionalca koji je radio sa tolkim obimom posla, a takvih ne verujem da ima na forumu.

 

[farmaceut]

Evo i ja eksperimentisem, imam par tabela sa po otprilike 1 milion recorda (sto bi prosjecno polje napravilo za godinu dana) i pretraga ide relativno brzo, pogotova ako uzmem u obzir moj stari comp.(duron 1300 512MB SDRAM).

Probavao sam razne SLECT queryi-je, pretrage temperatura po datumu za 5 - 10 sondi.

Mysql administrator uglavnom pokaze da se query "izvrsi" za priblizno 1s, te je obrada grafikona u ColdFusionMX serveru postala limitirajuci faktor (nekoliko sekundi za par hiljada vracenih recorda).
Kad sam tip grafikona predstavio kao bitmap (.png) umjesto flash-a, sve je radilo dosta brze.
Jos cu probavati ovih dana.

Ovakve performanse su prihvatljive, jer ce se izvjestaji gledati relativno rijetko, jednom dnevno ili rjedje (kad agronom uhvati vremena).
Naravno, videjt cu sta ce se desiti kad povecam broj tabela... Takodje cu prebaciti datatype u SmalInt (trenutno je decimal), pa izvrsiti konverziju pri prikazu "u letu".
Pozdrav!

 

[farmaceut]

Ovih dana cu gledati da instaliram i MSSQL, pa cu uporedjivati.

 

[silverglider]

Velicina tabele/baze sama po sebi nije toliko problem, ako se analiza/izvestaj ne rade frekventno i paralelno iz mnogo izvora. Ako to radi jedan jedini skript na kraju dana (tj. u ponoc, da izvestaj bude svez za ujutru) i generise bmp/png grafik i neku statistiku za npr. html prezentaciju, onda nema mesta panici. Frka bi bila jedino kada bi iz N filijala ljudi mogli 24/7 stalno da klikcu na "update".

Posto je statistika odnosno analiza vremenski bazirana, ja bih to radio po mesecima. To jest, uposlis malo stored procedure i koristis ih da ti na pocetku meseca kreiraju novu tabelu sa godinom i mesecom kao imenom. Napravis neku tabelu 'config' u kojoj, izmedju ostalog, imas polje "aktuelna tabela" i tu se pohrani ime tabele koja se trenutno puni. Tabele sa podacima cuvas (recimo) tri meseca, a posle toga ih dampujes (ili bekapujes/exportujes) - cuvas za stalno samo generisanu statistiku.

 

[farmaceut]

Hvala na odgovorima, vjerovatno semo se odluciti na "hibridni" dizajn, dakle baza podataka ce imati tabelu ili vise njih, sa "tekucim" podacima.
Nakon sto se jedan proizvodni ciklus zavrsi (150000 rekorda max, vjerovatno oko 70000), podaci arhiviraju tako sto se snimaju u CSV ili sl. text fajl, uz pomoc skripte. Po potrebi podaci s emogu ponovo ucitati u neku temp. tabelu radi analize (mada ce se ovo rijetko desavati).
Na ovaj nacin bi ustedili relativno skup prostor za bazu podataka, jer za tekst fajlove ima prakticno neograniceno prostora na serveru.