RE: uložení a agregace údajů v PostgreSQL

Havel Zdeněk Zdenek.Havel na mius.cz
Pondělí Březen 18 16:35:42 CET 2002


Sledovat a vyhodnocovat údaje je relevantní po určitou dobu. Je možné že
bude zajímavé vědět, kolik proteklo skrz zařízení za celou dobu jeho
funkčnosti a případně kdy byl výpadek, ale to už spíše spadá do oblasti
event managementu.

Data která přesáhnou dobu 60dnů nebudou smazána (jen jsem to nějak chtěl
ukončit o krok dříve), ale zpracována na průměrné hodnoty za hodinu nebo i
více s životností max 2 let. Co se stane s daty za tu dobu je otázka, možná
přijdou do archivu, možná budou odstraněna.

Vkládání dat lze ošetřit, vzdálené poolery budou data ukládat třeba pomocí
DB2 lokálně. Z poolerů si pak server data vyzvedne a vše najednou vloží v
určených časových intervalech.

Data je nutné agregovat až v databázi, protože u údajů za posledních 48h je
nutná co nevyšší přesnost, když se řeší ztrátovost paketů, problémy s
přenosy a pod. Většinou se skokové změny zjistí rychle a mohou trvat krátkou
dobu. U dat starších 48h to není už tak nutné, stačí vědět že trendově to k
něčemu směřuje, případně že se v průběhu 2 až 3 dnů trend opakuje.
Každopádně jsou všechna tato rozlišení nutná a je nutné je prohledávat.

Napadlo mě použít třeba rrdtool. Problém je, že bych musel v případě práv
pro přístup nebo eventlogu, mít ještě další databázi, kde budu mít evidované
uživatele, projekty (pohledy) a skupiny.

Výstup dat bude prováděn buď přes www, nebo se bude dotazovat vyhodnocovací
server (u obojího je vrácení údajů do jednotek sekund naprosto
bezproblémové). 

Agregaci by mělo stačit provádět jednou denně. Na druhou stranu, čím delší
období budu agregovat, tím více dat to bude. Optimální mi připadají 2
hodiny, tj. něco kolem 21600 údajů z každé tabulky, možná by se dalo u údajů
s menším rozlišením než 5 minut použít i delší dobu pro agregaci, to ukáže
provoz. Každopádně se musí napsat vyhodnocovací software tak, aby počítal se
zpožděnou agregací.


                        S pranim krasneho dne
                                 Zdenek Havel

> > Optimální by bylo, jestliže by se data dala vkládat v intervalu 1 
> > minuty. Z dat se vykreslovat grafy, sledovat jejich trendy, 
> případně 
> > další statistická vyhodnocení.
> 
>  Pak si nejsem jist chcete-li ty data opravdu mazat. Todle 
> zacina byt  vice datovy sklad nez klasicka relacni DB. U 
> datovych skladu a  multidimezinalnich DB (nebo jak se tomu 
> nadava) vam moc nepomohu  (nevi nekdo nejake pekne URL pro 
> studium DW? :-). Kazdopadne bude asi 
>  dobre se rozhodnout co chcete sledovat.
> 
>  Moc jste neokomentoval to, ze by klient mel byt inteligentni 
> a  vkladat data v davkach (pomoci COPY, insert je vyrazne 
> pomalejsi) a 
>  nebo je vkladat uz agregovane.
> 
> > Device je identifikace zařízení, v tomto případě jeho 
> doménové jméno, 
> > type, je druh údaje, oboje lze uložit do číselníků.
> 
>  V pripade, ze zustanete u klasicke relacni DB tak bych ty 
> cisleniky  urcite udelal. Pozor, ale pak na pripadne zmeny 
> ciselniku a historicke 
>  udaje (pokud je budete udrzovat ukladat).
> 
> > Indexaci jsem chtěl použít pro zrychlení hledání extrémů, nebo 
> > souhrnů. Dotazy typu "select device,timestamp from 5min_table where 
> > value > 20". Za předpokladu že bude mít zrušení indexu vliv na 
> > zrychlení insert operací, je není nutné indexaci provádět (četnost 
> > dotazů bude několik jednotek denně).
> 
>  Slo o to, ze ta data budete hlavne vkladat a predpokladam, 
> ze vetsi  odezva u tech selectu by vam nevadila zatimco u 
> toho vkladani ano.  Ale mozna je to prehnane a vlozeni do 
> toho indexu zase tam moc  narocne neni (nevim).
> 
>  Ja bych ty agregace delal mene casto. Je blbost delat to 
> kazdych pet  minut kdyz vysledek nikoho nezajima.
> 
> > Dotazy které budou převládat budou typu "select value form 
> 1min_table 
> > where device=xxx AND type=xxx AND time BETWEEN xxx AND xxx".
> > 
> > Tabulka může být jedna, je otázkou, jestli se při dalším růstu 
> > množství údajů nezačne vzhledem k jejich množství výrazně 
> zpomalovat 
> > oproti rozdělení do více tabulek. Většinou stejně budu hledat data 
> > pouze jednoho druhu, tj. 1min, 5min ... Těch 60 zařízení je 
> začátek, 
> > časem to může být 100 nebo 200 zařízení s průměrem 4 údajů na 
> > zařízení.
> 
>  Promyslete si co presne budete z tech dat dolovat, bude-li 
> mozne je  mazat (nebo je muzete presouvat do nejake tabulky s 
> historickymi  udaji).
>  
>         Karel
> 
> -- 
>  Karel Zak  <zakkr na zf.jcu.cz>
>  http://home.zf.jcu.cz/~zakkr/
>  
>  C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
> 


Další informace o konferenci Test