optimalizace triggeru (Postgres, ...)
Ing. Pavel PaJaSoft Janousek
janousek na fonet.cz
Pátek Prosinec 15 16:23:12 CET 2000
> Do C to prepisu, v tom bych problem nevidel. Takze vas uz nic jineho
> (po skouknuti triggeru) nenapada co s tim. Abych pravdu rekl, mne nenapada
> vubec nic. Samozrejme indexy na ty tabulky jsou vytvorene a indexuje se
> podle - line, counterstamp, line & counterstamp. Problem je, ze to co
> pet minut bude generovat zhruba tech 1000 grafu z tech vsech udaju
> (peti min, hodinove, denni, mesicni), takze ta databaze bude vcelku zatizena.
> Koukal sem, ze jste neco do Postgresu delal, nejaka finticka jak to urychlit
> primo v Postgresu asi neni, co?
Zdravim,
trosku z uplne jineho soudku... - co nemychat aktualni udaje s tim, co
uz je staticke, tedy namerene hodnoty starsi nez rekneme 1 minuta?
Chapu, ze jedna tabulka rychle poroste, ale:
1. Kdyz se provedou sumarizace za <od> <do>, muze se tento usek z teto
tabulky smazat
2. U PostgreSQL vacuum uz jde pokud vim delat i za behu => i na disku
bude misto
Ostatni tabulky porostou, ale jen sumarizacne a v principu nemusi byt
na stejne masine (v pripade, ze zatez je enormni a potrebujete skalovat)
jako tabulka, ktera roste kazdou chvilinku o udaje... Myslim, ze jazyk C
a ECPG (pochopil jsem, ze pouzivate PgSQL) je v tomto pripade vase dobra
zbran (stejne jako C a libpq, kazdemu co ma rad:)).
Jeste k tem indexum - osobne si myslim, ze v tomto postaveni (ktery
navrhuji) je pro vas podstatnejsi rychlost zapisu do rychle narustajici
tabulky => zadne indexy, protoze ty insert zdrzuji, naopak Vas netrapi,
ze sumarizace <od> <do> nejakeho udaje bude trvat X-krat pomaleji,
protoze se provede jen jednou a vysledek se ulozi do sumarizacni tabulky
(udaj je staticky, nema se jak zmenit). Alespon tak si to predstavuju,
pokud jsem dobre pochopil jde Vam o optimalizaci mereni pretecenych dat
Vasima linkama zakaznikum (BTW jako Vasi zakaznici musim konstatovat, ze
mereni neni uplne presne'-))
Sam jsem se podobnymi problemy zabyval a myslenek jak navrhovat
skalovatelna reseni je vice... - vcetne napr. takova, aby vstupni data
byla davana ciste do TXT souboru, ktery se napr. pres sit zpristupni a
databaze se z nej teprve tvori off-line (byt s minimalnim zpozdenim) -
toto je velmi robustni reseni (vice pocitacu, vice procesoru, kazdy se
stara o svou cast a v podstate se neperou).
-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft) FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet Anenska 11, 602 00 Brno
E-mail: mailto:Janousek na FoNet.Cz Tel.: +420 5 4324 4749
SMS: mailto:P.Janousek na SMS.Paegas.Cz Fax.: +420 5 4324 4751
WWW: http://WWW.FoNet.Cz/ E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------
Další informace o konferenci Databases