[OT] SQL databaze jak se tohle resi?

RV vicek.radek@cpost.cz
Pondělí Červenec 10 10:53:00 CEST 2006


V textu... 

> -----Original Message-----
> From: hw-list-bounces@list.hw.cz 
> [mailto:hw-list-bounces@list.hw.cz] On Behalf Of k.novo
> Sent: Monday, July 10, 2006 9:41 AM
> To: hw-list@list.hw.cz
> Subject: [OT] SQL databaze jak se tohle resi?
> 
> Mam zarizeni, ktera sbiraji data v case a ukladaji je do SQL 
> (PostgreSQL)

No urcite se najde nekdo kdo bude tvrdit ze tento SQL je v pohode, ale moje
postrehy jsou takove, ze specielne free verze tohodle SQL serveru jsou dost
pruser. Zmenil bych SQL server. :-)

> 
> tabulka vypada asi takto
> Nazev , cas (format linux epoch ), hodnota A, hodnota B
> 
> zaznamu je cca 200 kazdych 300s pricemz mi to jede  nekolik 
> let ==> dat je staaasne moc a 1GHz CPU uz to nejak nestiha 

Provozuji podobnou tabulku s hodnotami z meteostanice na MySQL a zatim bez
problemu na 700MHz CPU vcetne webu a pomerne hodne dalsi sluzeb pro domaci
sit. Pokud je problem uz pri zapisu dat (ne dalsim zpracovani) tak je
problem nekde jinde.

> tzn rad bych mel 3 tabulky v prvni budou data s presnosti 
> 300s za rekneme posledni mesic, starsi data by se mela 
> agregovat na hodinovou presnost a v posledni tabulce by mela 
> byt data s presnsti 1den starsi rekneme 180dni.

Nepisete zda chcete ta data jen jednorazove preklopit a nebo kontinualne
drzet v toto formatu. Predpokladam ze asi oboji - tedy preklopit a pak takto
udrzovat.

Rozhodne budete muset napsat jednorazovou proceduru, ktera zajisti rozdeleni
stavajicich dat a pak budete muset napsat kod do SQL serveru, ktery bude
data preukladat z tabulky 1 do 2 a 3. To by se asi dalo resit treba pomoci
triggeru pokud je treba data drzet neustale konzistentni.

> 
> Napsal jsem si na to funkci, ale je videt, ze je psana 
> pristupek klasickeho programatora pomoci ciklu atd.
> Urcite to lze resit primo na urovni SQL nejakym spravne 
> slozitym selectem

Uz me take napadlo otazka jak resit tuhle agregaci dat (prave ve spojeni s
moji meteostanici), ale zatim to vyresil paralelni RRDtool pro ucely
zobrazovani a pracne ziskana dat sypu s maximalni presnosti do DB - na MySQL
zatim neni problem. Navic tento zpusob zaznamu dat by mel byt pro DB
naprosto idealni - nevim jak ma zaznamy organizovane Vase SQL - nebot neni
nutne rozpojovat stranky v DB coz je velmi "draha" zalezitost co se tyka
strojoveho casu CPU a diskovych I/O.

Jinak pro vetsinu SQl je naprosto zasadni (krome disku - nekdy se to, ale
dost precenuje) pamet pouzitelna serverem a specialne konfigurace cache.
Nebot spravne nakonfigurovanej SQL server jede >99% operaci prave z cache a
veskere operace nad disky se provadeji na pozadi specialnim procesem.

Abych se priznal tak me nenapada jak nejak elegantne vyresit vami
pozadovanou agregaci, ale zkusim napsat na support Sybase jestli mi neco
poradi.

RadekCX
www: http://www.cncnet.info
e-mail: rvicek(at)quick.cz
ICQ: 210139531 nebo 296212824





Další informace o konferenci Hw-list