[ Bojan Komazec @ 14.08.2008. 12:19 ] @
Projekat na kome trenutno radim podrazumeva rad sa bazom podataka (PostgreSQL...ali pitanja koja cu postaviti su vrlo generalna i mogu se primeniti na bilo koju relacionu DB). Naime, ona ima "logging" funkciju - svake sekunde se u nju upisuje po nekoliko poruka o dogadjajima (event-ima) koje stizu sa servera. Poruke se samo upisuju, nema izmena ili brisanja redova u tabeli. Nisam DB Admin, imam samo osnovna znanja o bazama i zato imam nekoliko pitanja. Prvo bih zeleo da opisem o cemu je rec ovde.

Trenutno sve poruke smestam u jednu tabelu ali planiram da nju "razbijem" na nekoliko manjih, kako bih ustedeo memoriju i iskoristio punu snagu relacionog modela (svrhu RDBMS-a). Svaka poruka ima polja. Jednom polju odgovara jedna kolona u tabeli. Uocio sam da se polja mogu grupisati u nekoliko entiteta: Dogadjaj (event), Korisnik (user), Uredjaj (user device) i Server. To cu i iskoristiti u razbijanju velike tabele: svakoj od ovih grupa planiram da namenim po jednu tabelu. Glavna tabela ce biti tabela dogadjaja i ona ce imati brz rast jer ce se u nju svake sekunde upisivati po nekoliko redova. Podaci o korisniku, uredjaju i serveru ce iz ove tebele biti referencirani ID-jevima definisanim u ostalim tabelama (klasican relacioni model). Ostale tabele (User, Device, Server) ce se update-ovati po potrebi (i retko).

Gotovo svi primeri dizajniranja baza podataka koje sam nasao na internetu odnose se na "staticke" baze - gde se podaci u tabele upisu samo jednom i vrlo retko se posle menjaju (npr. tipican primer je relaciona baza sa tri tabele: Items, Customers i Orders).

Ono sto cu takodje morati da implementiram jeste sigurnost: moram garantovano imati zabelezene sve event-e. Moguce je da ce se ovi podaci koristiti za billing - naplatu usluga. Npr. za nekog korisnika ce se racunati vreme izmedju dogadjaja CONNECTED/AUTHENTICATED i DISCONNECTED i zavisno od duzine trajanja veze uspostavice se racun za korisceni servis. Verujem da svi telekom/internet provideri koriste ovakve baze i ovakve algoritme za odrzavanje i za naplatu usluga. Postoje Primary i Backup Server i imam dve solucije: ili da paralelno upisujem podatke u Primary i Backup tabele ili da upise merge-ujem pre upisa u jedinstvene tabele. Prvi pristup je laksi ali ce potrosnja memorije biti dvostruko veca a drugi nacin je tezi (treba sinhronizovati razlicita vremena kasnjenja poruka sa oba servera) ali ce se ustedeti na memoriji.

Pored rada na bazi, trenutno razvijam i GUI DB client aplikaciju koja sluzi za prikazivanje filtriranih podataka po raznim kriterijumima. Podaci se dobijaju izvrsavanjem Report-a (predefinisanih SQL upita, realizovanih preko storovanih procedura) ili izvrsavanjem custom SELECT SQL upita.

Posto su ovo vrlo kompleksne stvari, a ja sam amater u ovoj oblasti, moja pitanja su:

(1) kako se zapravo zove ovaj tip baze podataka (da li su to tzv. REAL TIME baze, koje se koriste u telekomu i na berzama - gde se novi podaci konstantno
INSERT-uju i tabele brzo rastu)?
(2) da li neko moze da mi preporuci neku dobru literaturu specificno o ovim bazama podataka?
(3) da li neko moze da mi preporuci neku dobru literaturu specificno o ovakvim real-time sistemima (sprega servera i baze podataka)
(ovo su veoma prisutni modeli i verujem da ima knjiga o ovome; moja internet pretraga za njima nije bas dala neke sjajne rezultate - nisam pronasao knjigu
bas o ovom tipu baza...)
(4) tabela dogadjaja ce brzo rasti u vremenu...Kako se postupa sa ovakvim tabelama kada one predju neku predefinisanu velicinu? Da li postoji neki nacin da se automatski kreira slicna tabela i da se automatski upis prebaci na nju a da ova postojeca postane "history" tabela?
(5) ako Report treba da vrati tabelu koja sadrzi npr. ukupan broj korisnika koji se logovao na neki server u nekom vremenskom (datumskom) intervalu, da li je vise preporucljivo kreirati posebnu tabelu u bazi koja ce sadrzati samo ove podatke i biti update-ovana svaki put kada se desi novi event CONNECTED/AUTHENTICATED i onda nju ispitivati ili je bolje drzati se glavne tabele (dogadjaja) i nju ispitivati? u prvom slucaju bih imao
dosta trigerovanja pri svakom INSERT-u i ne znam da li bi baza mogla da obradi toliko mnogo podataka izmedju dva dogadjaja...Da li je to uobicajena
praksa - prepustiti trigerima da update-uju pomocne tabele u zavisnosti od podataka koji pristizu u glavnu tabelu?
(6) da li moje inicijalne ideje o dizajnu koje sam ovde predstavio imaju iole smisla?




Hvala svima unapred na pomoci!

[Ovu poruku je menjao Bojan Komazec dana 14.08.2008. u 18:23 GMT+1]
[ zmau @ 14.08.2008. 17:23 ] @
5. Nisam ukapirao šta ti je user device. Inače mi tvoj relacioni model izgleda sasvim smisleno.
1,2,3. Pravo da ti kažem, nisam do sada mislio da je tvoj problem logovanja po bilo čemu specifičan, a naročito što se tiče količine prometa. Ja sam svojevremeno održavao deo bankarskog infosistema i imao sam u (dosta širokoj) prometnoj tabeli svakodnevno po nekoliko hiljada ili par desetina hiljada novih zapisa. I to je bila jedna od manjih prometnih tabela. Tako da verujem da ti je standradna literatura o bazama dovoljno dobra.
4. Ne znam za baze, ali možda bi mogao da porazmisliš o ovome i na nivou programiranja aplikacije koja piše u bazu, obzirom da postoje gotove biblioteke koje se bave logovanjem. Recimo, ako programiraš u javi, možeš da pogledaš log4j i njegovu mogućnost da piše u bazu. Ne znam koliko je fleksibilan da podrži tvoj relacioni model jer ga nisam koristio da pišem u bazu nego samo u fajlove. A kad radi sa fajlovima log4j definivno bez problema podržava baš to što si ti pomenuo - puni fajl do neke veličine, pa ga rename-uje i otvori drugi.
[ Bojan Komazec @ 14.08.2008. 17:56 ] @
Citat:
zmau: 5. Nisam ukapirao šta ti je user device. Inače mi tvoj relacioni model izgleda sasvim smisleno.


User device je zapravo masina (pc, laptop, palmtop, mobile,...) sa koje neki korisnik pristupa sistemu (loguje se, salje poruke, log out-uje se...). To je zaseban entitet jer je moguce da vise razlicitih korisnika (u razlicito vreme) koristi istu masinu.

Citat:
1,2,3. Pravo da ti kažem, nisam do sada mislio da je tvoj problem logovanja po bilo čemu specifičan, a naročito što se tiče količine prometa. Ja sam svojevremeno održavao deo bankarskog infosistema i imao sam u (dosta širokoj) prometnoj tabeli svakodnevno po nekoliko hiljada ili par desetina hiljada novih zapisa. I to je bila jedna od manjih prometnih tabela. Tako da verujem da ti je standradna literatura o bazama dovoljno dobra.


Koliko sam uspeo da saznam, ocekuje se oko 10 miliona recorda svakog dana. Trenutno u test-bazi (i u ovoj jednoj jedinoj tabeli) imam oko 200'000 record-a po danu. Dakle, savremene baze su sposobne da rukuju sa recimo 10 upisa svake sekunde? (Trenutno imam dva do tri). Znam da je pitanje laicko, i verujem da je odgovor potvrdan, ali mi treba misljenje nekog ko je "osetio" rad baze pod velikim "opterecenjem".

Citat:
4. Ne znam za baze, ali možda bi mogao da porazmisliš o ovome i na nivou programiranja aplikacije koja piše u bazu, obzirom da postoje gotove biblioteke koje se bave logovanjem. Recimo, ako programiraš u javi, možeš da pogledaš log4j i njegovu mogućnost da piše u bazu. Ne znam koliko je fleksibilan da podrži tvoj relacioni model jer ga nisam koristio da pišem u bazu nego samo u fajlove. A kad radi sa fajlovima log4j definivno bez problema podržava baš to što si ti pomenuo - puni fajl do neke veličine, pa ga rename-uje i otvori drugi.


Koristim C#.NET. U njemu sam i napisao aplikaciju koja se kaci na server (TCP sockets), prihvata TCP chunk-ove, spaja ih, slaze u poruku, parsira poruku i kreira i izvrsava SQL INSERT upit (ovo sam sve realizovao kroz kaskadu nekoliko dll-ova od kojih svaki uzima output od prethodnog, obradjuje ga, stavlja rezultat na queue i salje event njegovom klijentu - sledecem dll-u, da je najnoviji rezultat spreman...).

Kreiranje i upis u novi fajl (kada je stari dostigne neku MAX velicinu) ne bi bilo tesko napraviti u .NET-u, ali meni je potrebna informacija da li nesto slicno (i automatizovano) postoji u bazama podataka.

U svakom slucaju, hvala na odgovorima